idnits 2.17.1 draft-nordmark-shim6-esd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1001. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2008) is 5905 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 841, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 847, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 850, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 853, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 857, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 864, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 878, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 882, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 892, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 906, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 909, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 912, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 925, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 935, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 940, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 948, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-10 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-11 -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '14') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '15') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3697 (ref. '19') (Obsoleted by RFC 6437) == Outdated reference: A later version (-08) exists of draft-ietf-shim6-applicability-03 Summary: 6 errors (**), 0 flaws (~~), 25 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SHIM6 WG E. Nordmark 3 Internet-Draft Sun Microsystems 4 Expires: August 26, 2008 February 23, 2008 6 Extended Shim6 Design for ID/loc split and Traffic Engineering 7 draft-nordmark-shim6-esd-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 26, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 The Shim6 protocol provides for locator agility while satisfying the 41 'first, do no harm' security requirements. This document outlines 42 three rather orthogonal sets of extensions to Shim6. The first one 43 is how to procide complete separation between identifiers and 44 locators. The second one is how to allow routers to rewrite the 45 locators in the shim6 packets as a way to provide traffic engineering 46 information to the hosts. The third one is the outline of a simple 47 extension to allow shim6, with a CGA upper-layer ID, to operate using 48 IPv4 addresses as locators. 50 The purpose of this outline is to stimulate discussions. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Identifier/Locator split . . . . . . . . . . . . . . . . . 3 56 1.2. Traffic Engineering . . . . . . . . . . . . . . . . . . . 4 57 1.3. Shim6 using IPv4 addresses as locators . . . . . . . . . . 5 58 2. Identifier/Locator Split . . . . . . . . . . . . . . . . . . . 6 59 2.1. Syntax, Semantics, and Allocation of non-routable 60 identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Domain name lookup to find the Identifier . . . . . . . . 7 62 2.3. Identifier Lookup to find the Locators using the DNS . . . 7 63 2.4. Handling Application Referrals . . . . . . . . . . . . . . 7 64 2.5. Walkthrough of an example . . . . . . . . . . . . . . . . 8 65 2.6. Design Alternatives . . . . . . . . . . . . . . . . . . . 9 66 3. Traffic Engineering Support . . . . . . . . . . . . . . . . . 11 67 3.1. Recommending use of DNS SRV . . . . . . . . . . . . . . . 11 68 3.2. DHCPv6 option for Locator Preferences . . . . . . . . . . 12 69 3.3. Identifier to Locator lookup Preferences . . . . . . . . . 12 70 3.4. Locator Rewriting by Routers . . . . . . . . . . . . . . . 12 71 3.5. Walkthrough using locator rewriting . . . . . . . . . . . 13 72 3.6. Need for Coordination? . . . . . . . . . . . . . . . . . . 15 73 4. New Option Formats . . . . . . . . . . . . . . . . . . . . . . 17 74 4.1. New DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 17 75 4.2. New Shim6 Options . . . . . . . . . . . . . . . . . . . . 18 76 4.2.1. Sent Locator Pair Option Format . . . . . . . . . . . 18 77 4.2.2. Received Locator Pair Option Format . . . . . . . . . 19 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 Intellectual Property and Copyright Statements . . . . . . . . . . 27 86 1. Introduction 88 This document describes extensions to Shim6 [7] to handle complete 89 separation between identifiers and locators and also to provide 90 better feedback to the host for the purposes of traffic engineering. 92 The Shim6 protocol provides for locator agility while satisfying the 93 'first, do no harm' security requirements [22]. We believe that the 94 only existing two approaches which satisfy these requirements are 95 shim6 and HIP [30]. Satisfying those requirements seem to imply some 96 additional state on the endnodes, at least when the locator agility 97 mechanism is implemented in layer 3 as opposed to being folded into 98 every transport protocol; if it was folded into the transport 99 protocols one could probably include this information in the 100 transport protocol state and exchanges. As such, these approaches 101 require some additional state management which results in packet 102 exchanges. 104 This document outlines some extensions to Shim6 that in addition 105 provides complete separation between identifiers and locators, and 106 allows routers to rewrite the locators in the shim6 packets as a way 107 to provide traffic engineering information to the hosts. 109 1.1. Identifier/Locator split 111 Shim6 as currently specified states that the upper-layer identifier 112 (ULID) is one of the IPv6 locators of the host. However, the 113 protocol exchanges in shim6 do not require this, and there is already 114 a ULID-pair option that can be conveyed in the shim6 establishment 115 exchange. Thus in the protocol exchanges we can just carry that 116 ULID-pair option in all the shim6 control messages (I1, R1, I2, R2, 117 R1bis, I2bis, Update Request, Update Acknowledgement, Keepalive, and 118 Probe). But that in itself doesn't solve the problem; a large piece 119 of the problem lies in: 121 o What is the syntax and semantics of an identifier. 123 o How are identifiers allocated to hosts. 125 o How do the hosts find a Identifier from a domain name. 127 o How do application referrals [27] work. 129 XXX Add TBD for referals using non-routable ULID - need to know peer 130 application is running on a system capable of looking them up. 132 This document makes some, not completely arbitrary, assumptions for 133 the above issues, and presents an outline of how things could work 134 given those assumptions. The document shows that there is some 135 additional setup cost associated with identifier/locator separation 136 compared to shim6 just switching between a set of locators. We argue 137 that some additional overhead is inevitable; the benefits of 138 identifier/locator separation is to provide a layer of indirection 139 between the two, and this indirection necessitates some form of 140 lookup as part of initiating communication to an identifier. 142 1.2. Traffic Engineering 144 With the current style of IPv4 multihoming, which uses a single IP 145 address prefix and BGP, there is a range of BGP techniques that can 146 be used to affect the routing for that single prefix, and as a result 147 effect which path incoming traffic use to reach the site. Also, the 148 site itself can use some internal routing control to select which 149 egress path to use should a route be available via multiple egresses. 151 In any scheme that uses multiple address/locator prefixes per site 152 the mechanisms to control which packets flow over which ingress and 153 egress are likely to be completely different, since BGP would not be 154 able to correlate the different prefixes that are assigned to a 155 single site. This might imply that the traffic engineering 156 capabilities might be quite different. 158 As specified in shim6, the hosts select the ULID-pair, which by 159 convention is the initial locator pair, using RFC 3484bis [16]. With 160 the extensions specified in these documents there are two cases to 161 consider, depending on whether the ULID is a locator or the ULID is a 162 non-routable identifier: 164 o For ULIDs that are locators, RFC 3484bis still applies. In 165 addition, DNS SRV records [10] can be used as a way to give the 166 destination site some influence over which ULID = initial locator 167 is used, but that requires that the applications use SRV records. 169 o With ULIDs that are non-routable identifiers, there will most 170 likely be only one identifier for the destination as well as the 171 source. Thus the role of RFC 3484 is largely removed. But there 172 is an additional step of looking up the identifier to find the 173 locator, and at that point in time it makes sense to consider 174 traffic engineering for selecting the initial locator pair. 176 In both cases, shim6 already provides the mechanism of a Locator 177 Preference option which can be used by the peers to change the 178 preferences. But this mechanism assumes that there is a mechanism by 179 which a host in a site could be informed of its site's preferences. 180 We outline a DHCPv6 option in this document that could be used to 181 convey this information. 183 1.3. Shim6 using IPv4 addresses as locators 185 When CGA is used to prevent redirection attacks in shim6, there is no 186 constraint on the locators that are used apart from host B must know 187 its own locators so it can pass it them to host A. In particular, we 188 can use IPv4 addresses as locators; this doesn't require anything 189 more than defining how an IPv4 address is carried in the 128-bit 190 fields in the Locator List option. 192 As is the norm when suggesting to run an protocol over IPv4, after 5 193 milliseconds the question is raised how the protocol can operate over 194 IPv4 NAT boxes. For all protocols that adds one or two orders of 195 magnitude or more complexity, and shim6 is no exception. The 196 complexities lie in: 198 o Handling initial contact from the public side of the NAT box to a 199 host on the private side of the NAT box. All protocols end up 200 with some form of 3rd party device on the public side in order to 201 handle this. 203 o Maintaining the NAT state in the NAT box, and detecting when this 204 state has been lost and must be recreated. For shim6 the failure 205 detection mechanism [9] can detect this. 207 o Being able to recreate that state in the NAT after it has been 208 lost. 210 Thus while supporting IPv4 addresses as locators is easy, running 211 across NATs is complex. It is far from clear that this is worth- 212 while pursuing. 214 2. Identifier/Locator Split 216 This section outlines how non-routable identifiers can work in the 217 whole system, including their lookup and how they are used in shim6. 218 There are likely to be alternative designs, so this is by no means 219 believed to be the optimal approach, but working out some number of 220 details is still a useful exercise and helps have more concrete 221 discussions. 223 2.1. Syntax, Semantics, and Allocation of non-routable identifiers 225 In order for applications, which have been ported to use the IPv6 226 APIs that carry 128-bit IPv6 addresses, to not have to be ported 227 again, it makes sense to try to make do with an syntax that fits in 228 128 bits. Note that one could wish that we could apply this to the 229 IPv4 32-bit APIs, but with a future Internet with more than 4 billion 230 hosts, trying to support the IPv4 APIs to identify each host would be 231 impossible. 233 Since we are likely to have applications communicate to both hosts 234 which have an IP identifier and those which only have the IP 235 locators, it is highly desirable to be able to have a syntactic means 236 to tell an IP identifier apart from an IP locator. A reasonable 237 approach is to allocate a small subset of the IPv6 address space [23] 238 to be non-routable IP identifiers, in a similar means to the KHI 239 approach [24]. 241 The desired semantics of an IP identifier is to be a name that refers 242 to an instance of the IP protocol. Hence it should not be bound to a 243 particular network interface. Also, it is desirable for the 244 identifier to be long term stable, for instance ensuring that the 245 identifier survives renumbering. 247 As we will discuss below, for application referrals to work using 248 128-bit IP "addresses" as handles for another host, there has to be 249 an efficient and scalable way to look up an identifier and find the 250 locators. An obvious way to get scalability is to do hierarchical 251 allocation of the identifiers, since this allows for a scalable, 252 hierarchical organization of a lookup system and also ensures that 253 the identifiers are unique. 255 While it certainly isn't the only possibility, in order to work out a 256 complete picture, this document suggests such a hierarchical 257 allocation, in such a way that at least 64 bits of the identifier is 258 left to each site to allocate. (With 64 bits we can use CGA to 259 "prove" identifier ownership as a way to prevent redirection attacks 260 from off-path attackers.) 262 2.2. Domain name lookup to find the Identifier 264 Many applications start their communication by knowing the fully- 265 qualified domain name of the peer, and they look this up in the DNS 266 to find AAAA and A records for that peer. As we introduce a separate 267 IP Identifier we want the same capability, but we also need to avoid 268 disturbing existing IPv6 hosts which would not be able to deal with 269 an IP identifier, since they assume all AAAA records contain routable 270 locators. 272 A conceptually clean way to handle this is to introduce a separate ID 273 resource record type in the DNS, which has the same right-hand side 274 as the AAAA records. Then hosts which implement support for the IP 275 identifier would first look for an ID record, and if none found, look 276 for AAAA and A records. This would work, but adds inefficiencies 277 until (or unless) most hosts have ID records. 279 An alternative would be to overload AAAA records to contain both 280 identifiers and locators and rely on RFC 3484 to avoid accidentally 281 picking an identifier on a host which doesn't understand what an IP 282 identifier is. Then the hosts which do understand IP identifiers can 283 ignore the routable locators in the AAAA RRset. The choice between 284 those two, or other alternatives, doesn't materially affect how the 285 rest of identifier/locator separation would work. 287 2.3. Identifier Lookup to find the Locators using the DNS 289 One can do different forms of lookup systems for the identifier to 290 locator lookup. The least "novel" one would be to reuse the DNS. 291 Since the identifier is drawn from the IPv6 address space, a possible 292 way to do this in the DNS is to use the ip6.arpa tree for this, with 293 its ability to delegate on nibble boundaries. 295 A simple way to do this would be to just have normal PTR records in 296 the reverse tree that "point" to a fully-qualified domain name, and 297 then do lookups for AAAA records matching that domain name. But this 298 doesn't allow the destination domain to influence the locator 299 selection as part of the lookup. Thus it might make sense to instead 300 deploy DNS SRV records in the reverse zone since this would allow 301 specifying a priority and a weight for primary/backup and load 302 spreading, respectively. 304 2.4. Handling Application Referrals 306 A referral is the case when three or more instances of an application 307 interacts and the first instance communicates with the second 308 instance, and then communicates with the third instances and wishes 309 to tell the third instance how to contact the second instance. There 310 are application patters, called callbacks and long-lived application 311 associations in [27] that have similar issues. The application can 312 handle these by using and passing the fully-qualified domain name, or 313 it can do it by storing and passing the IP address. In the latter 314 case, this application ends up depending on the IP address being 315 universally useful as a way to contact another host. 317 Assuming we want to keep such applications functioning with the 318 introduction of the identifier/locator split, it is necessary that 319 the 128 bit identifier can be useful on a host which didn't do the 320 DNS lookup and does not know the fully-qualified domain name of that 321 peer. 323 The approach outlined in this section handles this case, since the 324 identifier will be looked up in ip6.arpa to find the locators. 326 2.5. Walkthrough of an example 328 The following example shows how the above use of DNS interacts with 329 shim6. This assumes that the destination host, www.example.com, has 330 been allocated an IP identifier and that IP identifier has been 331 entered as an ID RR in the DNS. 333 1. The application calls getaddrinfo() for www.example.com, and that 334 performs a DNS lookup for an ID record for www.example.com. 335 Since a record was found, it returns this as a 128-bit IPv6 336 address. (If no records was found, then getaddrinfo() would have 337 looked for AAAA and A records.) 339 2. The application, without making any distinction between an IP 340 identifier and a locator, passes this address to the connect() or 341 sendto() calls, depending on which transport protocol it uses. 343 3. The transport protocol proceeds as normal, which includes picking 344 a source address which "matches" the destination address. The 345 RFC 3484 rules might very well be sufficient for this; 346 alternatively the transport protocols would be modified to 347 explicitly know that when the destination is an identifier (it 348 has a well-known, KHI-like prefix) it must pick a source address 349 which is also an identifier, and vice versa for a destination 350 which is a locator. 352 4. A packet (for instance, a TCP SYN) from the transport protocol 353 arrives at the shim6 shim layer on the host. The shim looks for 354 a context which matches the ULID pair. Since we assume this is 355 the first attempt to communicate with this ULID, there is no 356 existing context. 358 5. The shim checks if the destination ULID is a locator or an 359 identifier. If it is a locator it proceeds as specified in Shim6 360 [7] and none of the items below apply. If it is an identifier, 361 then the shim needs to find the set of locators for the 362 identifier. 364 6. The shim performs the identifier to locator lookup very similarly 365 to normal IPv6 reverse lookups (form a query name based on the 366 nibbles in reverse order and append ip6.arpa), but it queries for 367 SRV records. 369 7. Assuming one or more SRV records are returned, the shim takes the 370 priority and and weight into account as specified in [10] to 371 order the locators. 373 8. The shim then forms a I1 packet as specified in [7] and includes 374 a ULID pair option (to carry the ULIDs which are different than 375 the locators). 377 9. The rest of the context establishment follows as in [7] with the 378 ULID option. The presence of the ULID option implies that the 379 peer will verify the locators using the CGA ULID properties when 380 receiving the I2 message, and the host itself will verify its 381 peer's locators the same way when receiving the R2 message. 383 The rest of shim6 remain unmodified, except that the Locator Update, 384 Keepalive, and Probe messages should probably carry the ULID option 385 as well. Alternatively, one could rely on the 47-bit context tag to 386 identify the context. 388 Note that the above assumes that the site controls the DNS reverse 389 tree for their identifier prefix. But there is no dependency on the 390 reverse tree for the locator prefixes that the site is using. 392 In order to provide an IP identifier that is not a routable IP 393 address, we would presumably need to provide host autoconfiguration 394 capabilities for the identifier. This could be done as some minor 395 extensions to DHCPv6 and Stateless Address Autoconfiguration, as long 396 as the identifiers would be automatically registered in the DNS as 397 part of such assignment. 399 2.6. Design Alternatives 401 If the identifiers are placed in the DNS using AAAA records, then the 402 lookup for the AAAA record set (to find the identifier) might also 403 return a list of locators. Such a list can potentially be useful to 404 avoid the ip6.arpa lookup to find the locators. But relying on this 405 means that the reverse lookup from the identifier will only be used 406 in uncommon cases such as: 408 o The shim6 context state having been garbage collected too early, 409 and the upper-layer protocol sends down a packet with a 410 destination ULID which is a non-routable identifier. 412 o Application callbacks, referrals, and long-lived application 413 handles [27] that are IP addresses. 415 For this reason it makes sense to be more consistent and always rely 416 on the reverse lookup when the context is established. 418 3. Traffic Engineering Support 420 The traffic engineering pieces that might be desirable and that are 421 easy to implement in this model are outlined in this section. If the 422 ULID is a routable locator, then it makes sense to recommend that 423 applications use DNS SRV records for the initial (non-shimmed) 424 contact, and also provide at least a DHCPv6 option by which a site 425 administrator can control what each host in the site uses in the 426 shim6 Locator Preference option. 428 In the case when the ULID is a non-routable identifier, a different 429 set of mechanisms are desirable. Instead of using DNS SRV records 430 for the lookup of the domain name of the peer, we want similar 431 control when looking up an identifier to find the set of locators. 433 For both cases it has been argued that allowing the routers, in 434 particular routers located close to the egress from a site, to 435 rewrite the source locators, as a mechanism to indicate to the hosts 436 a dynamic change in the preferred locators. We outline the mechanism 437 for this below and we also discuss the policy issues which are 438 introduced with this additional information from the routers. 440 Note that we do not currently have a set of agreed upon requirements 441 for traffic engineering. The closest we have to requirements are 442 Jason Schiller's slides at 443 http://www.iab.org/documents/open-mtgs/2005-10-23-schiller.pdf 445 3.1. Recommending use of DNS SRV 447 In shim6 as specified, the host rely on existing DNS mechanisms, such 448 as AAAA records or any other mechanism, to find a list of locators to 449 try. When AAAA records are used, there is no mechanism for the 450 destination site to express any ranking for primary/fallback, or any 451 mechanism to spread load across the paths that are represented by the 452 locators, since the AAAA resource record set is treated as a set with 453 no implied order. 455 If we could use DNS SRV records instead, then we would have the 456 combination of the SRV priority (for primary/backup) and SRV weight 457 (for specifying a weighted, random load spreading) as tools for the 458 site administrator to use. 460 Unfortunately it is the application software developer which needs to 461 explicitly decide to use SRV records, thus we can not require that 462 shim6 implementations also have the applications use SRV, since the 463 application developer is in most cases different than the implementor 464 of the TCP/IP protocol stack. But it would be helpful to the IETF to 465 make a strong recommendation that applications should use SRV 466 records. 468 Note that in some cases it quite complex to specify how an 469 application uses SRV records. SIP is an example of this [13], which 470 needs to deal with SIP running over multiple transport protocols, SRV 471 vs. AAAA and A record ordering, and various other issues. But in 472 common cases like http that run over a single transport, the needed 473 change is just to precede the lookups for AAAA and A records at 474 www.example.com with a lookup for SRV at _http._tcp.www.example.com. 476 3.2. DHCPv6 option for Locator Preferences 478 Shim6 [7] specifies a Locator Preference option which can carry some 479 number of octets, with the protocol currently specifying the 480 semantics of the first three octets of each preference element. One 481 way to allow the site administrator to control this is to introduce a 482 new DHCPv6 [14] option which carries the list of IPv6 locator 483 prefixes that the site uses and the octets of shim6 preference 484 element; this can be done without the host having to understand the 485 semantics of the octets it is sending - it can just copy them from 486 the DHCPv6 option, even though the host will interpret the locator 487 preference octet string it receives from the peer. 489 To be concrete, we show an example of what such a DHCPv6 option can 490 look like in Section 4.1. 492 3.3. Identifier to Locator lookup Preferences 494 As specified in Section 2.3 it makes sense to use SRV records for the 495 reverse lookup used to go from an identifier to a set of locators, 496 since this allows the site manager to provide priority and weight to 497 the peer before the initial contact takes place, thus most likely the 498 initial locator chosen by the host will be a reasonable one from the 499 perspective of traffic engineering for the peer site. 501 3.4. Locator Rewriting by Routers 503 Shim6 as specified [7] allows routers to rewrite the locators on 504 shim6 packets that are payload extension headers, but it does not 505 allow such rewrites on the shim6 control messages. In this section 506 we outline what it would take to allow such rewriting on all the 507 shim6 messages, and also provide the host with an indication of how 508 their locators are rewritten so that they can take this into account. 510 With these extensions the routers are free to rewrite the locators 511 with alternate values in any IPv6 packet that has a shim6 header 512 (i.e., where some next header value is IPPROTO_SHIM6). 514 The support for this rewriting consists of: 516 o Introducing a new Sent Locator Pair option, which the receiver or 517 a packet can use to see how the routers rewrote the locators in a 518 packet sent towards it. The receiver also "echos" this 519 information to its peer using the next option. 521 o Introducing a new Received Locator Pair option, which is a echo of 522 the content of a received Sent Locator Pair option. 524 o The hosts SHOULD include a shim6 extension header for ULP payloads 525 where the sending shim does not rewrite the locators, in order to 526 allow the routers to rewrite the locators. 528 o To maximize the utility of the locator rewriting, we should avoid 529 the use of deferred context establishment. If the first packet 530 sent is an I1 packet, and the above SHOULD is honored, then the 531 routers are free to rewrite the locators in all the packets that 532 are exchanged between a pair of shim6 hosts. (If we are also 533 doing complete identifier/locator split, then there is no deferred 534 context establishment, thus this doesn't add any additional 535 costs.) 537 o As in the current shim6 specification, any source and destination 538 locator can be used on a shim6 payload message as long as the 539 context tag matches. But in addition, when the receiver of a 540 payload message observes a change in the locator pair on which it 541 receives the payload extension headers, it SHOULD notify the peer 542 of this by sending an Update Request message with a Received 543 Locator Pair option. Such update messages MUST be rate limited 544 since the locators can flap when routing is flapping. 546 3.5. Walkthrough using locator rewriting 548 The following example shows how the Sent Locator Pair and Received 549 Locator Pair options are used as part of the Shim6 context 550 establishment exchange, and indicates some of the policy choices that 551 exist in terms of what locator is chosen. The same exchange applies 552 whether the ULID is a reachable locator or not; when the ULID is an 553 unreachable identifier then there would be an ULID option in most of 554 the shim6 control messages, but we omit that aspect here as we focus 555 on the locator exchanges. 557 We assume that host A, which locators A1, A2, and A3, is 558 communicating with host B, with locators B1 and B2. 560 The walkthrough starts when A is sending an I1 message to B: 562 1. The shim then forms a I1 packet as specified in [7] and includes 563 a Sent Locator Pair option. The shim has chosen A1 to be the 564 source locator and B1 to be the destination locator, thus it 565 places in both IPv6 header (as source and destination), 566 and in the Sent Locator Pair option. 568 2. The routers, for instance, the egress router from A's site, might 569 rewrite the IPv6 source address field with a different prefix so 570 that when the packet is receive by B it has in the IPv6 571 header (and the Sent Locator Pair option is unmodified with ). 574 3. B processes the I1 message as specified in [7] to generate a R1 575 message. In addition, it copies the content of the Sent Locator 576 Pair option into a Received Locator Pair option. Host B must 577 decide whether it should send the R1 message to the IP source 578 address of the R1 message, or send it to the potentially 579 different Sender Locator in the Sent Locator Pair option in the 580 I1 message. The safe thing would be to send it to the source 581 address of the R1, because the alternative can be used for 582 reflection attacks. Once B has made this decision, it puts the 583 addresses, in this example in the IPv6 header as well as 584 into a Sent Locator Pair option. 586 4. Host A receives the R1 message and finds the context state. At 587 this point in time A can see how the router rewrote the I1 588 message by comparing the Lp(local), Lp(peer) with the Received 589 Locator Pair option. It can also see how the locators were 590 rewritten for the return path by comparing the IPv6 header in the 591 R1 message with the Sent Locator Pair option. It might be that 592 the Received Locator Pair option has a Sender Locator which is 593 not one of the locators that host A knows as its own. In this 594 case it it might reasonable for A to treat this locator as its 595 own, at least in terms of accepting packets destined to it. Host 596 A forms a normal I2 message, but also includes a Received Locator 597 Pair option in it. The host chooses the locator pair to use when 598 sending the I2 message, and if the source address of the R1 599 message is one of B's locators, then this might be the best 600 choice. Just as for the I1 message, the host adds a Sent Locator 601 Pair option to the I2 message which contains a copy of the source 602 and destination fields in the IPv6 header. 604 5. Host B receives the I2 message and finds the context state. At 605 this point in time B can see how the routers on the return path 606 rewrote the I2 message by comparing the IPv6 header in the I2 607 message with the Sent Locator Pair option. It might be that the 608 Received Locator Pair option has a Sender Locator which is not 609 one of the locators that host B knows as its own. In this case 610 it it might reasonable for B to treat this locator as its own, at 611 least in terms of accepting packets destined to it. Host B forms 612 a normal R2 message, but also includes a Received Locator Pair 613 option in it. The host chooses the locator pair to use when 614 sending the R2 message, and if the source address of the I2 615 message is one of A's locators (that it in the Locator List 616 option), then this might be the best choice. Just as for the R1 617 message, the host adds a Sent Locator Pair option to the R2 618 message which contains a copy of the source and destination 619 fields in the IPv6 header. 621 The host maintains Lp(local) and Lp(peer) to use as the preferred 622 source and destination address when sending packets to the peer. But 623 in addition the hosts main a Lr(local) ["r" for "received"] and 624 Lr(peer) that is the locator pair in the most recently received 625 packet for the context. 627 When a packet with a Payload Extension Header is received for the 628 context and the source or destination address does not match 629 Lr(peer)/Lr(local), then, subject to rate limiting, the host forms an 630 Update Request message with a Received Locator Pair option. This 631 Update Request message is transmitted and retransmitted as specified 632 in [7]. This allows the peer to be notified should the routers 633 change the way the rewrite the locators, which the host can use to 634 make sure the packets have the correct locators as they are 635 originated. 637 3.6. Need for Coordination? 639 It might be the case that the routers are not aware of the the actual 640 prefixes assigned to each host. For instance, just because a site 641 has 7 different prefixes, there might be some host that due to 642 resource considerations or DHCP sever policy only configure addresses 643 in a subset of these prefixes. Thus the routers might rewrite the 644 source locator to be a locator which is not assigned to the source 645 host. If host B were to respond to an I1 message that had been 646 rewritten this way, then the R1 message would not be accepted by host 647 A. For this reason it is recommended that the I1 and R1 messages 648 include the Locator List option, and that the receiver of these 649 messages reply using the Sender Locator in the the Sent Locator Pair 650 option, in the case when the IPv6 source address is not part of the 651 Locator List option. 653 Also, it is recommended that hosts "learn" new locators from the 654 Received Locator Pair option, so that they will in the future accept 655 packets destined to the locators that they routers use when 656 rewriting, even if the hosts aren't otherwise configured with those 657 addresses. Note that for shim6 to be able to prove to the peer that 658 the host in fact "owns" such a locator, the host must have a CGA ULID 659 and sign an Update Request message with the new locator set. Whether 660 it is a good idea to always "adopt" locators from the Received 661 Locator Pair option is TBD. 663 4. New Option Formats 665 4.1. New DHCPv6 Option 667 This option follows the DHCPv6 [14] format for options and allows the 668 DHCP server to specify what the host will put in the Shim6 Locator 669 Preference option. The DHCPv6 option carries IPv6 address prefixes, 670 and the host will apply the logest matching such prefix to each of 671 its IPv6 locators. 673 0 1 2 3 674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | option-code | option-len | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Prefix Length1| | 679 +-+-+-+-+-+-+-+-+ Prefix 1 | 680 | | 681 | +-+-+-+-+-+-+-+-+ 682 | | Elem len 1 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Element 1 (len octets) | Prefix Length2| | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 686 | Prefix 2 | 687 | | 688 | +-+-+-+-+-+-+-+-+ 689 | | Elem len 2 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Element 2 (len octets) | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 693 | ... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Fields: 698 option-code: 16-bit unsigned integer. To be allocated by the IANA. 700 option-len: 16-bit unsigned integer. The length in octets of all 701 the fields in the option which follow the option-len 702 field. 704 Prefix Length[n]: 8-bit unsigned integer. The number of relevant 705 bits in Prefix[n]. 707 Prefix[n]: An IPv6 address prefix. The length of this field is 708 the number of octets necessary to carry Prefix 709 Length[2] bits. For instance, a 47-bit Prefix Length 710 would mean that the Prefix field is 6 octets. 712 Element Len[n]: 8-bit unsigned integer. The number of octets of 713 Element[n] that follows the Element Len field. 715 Element[n]: One or more octets that can be directly copied to the 716 Shim6 Locator Prefix option's Element field. 718 4.2. New Shim6 Options 720 This document defines two new Shim6 options. 722 +------+-----------------------+ 723 | Type | Option Name | 724 +------+-----------------------+ 725 | 13 | Sent Locator Pair | 726 | | | 727 | 14 | Received Locator Pair | 728 +------+-----------------------+ 730 Table 1 732 4.2.1. Sent Locator Pair Option Format 734 This option carries the set source and destination locators as sent 735 by the sender, that is, the sender sets them to the same values as 736 the IPv6 source and destination fields. When router rewriting is in 737 use, then the routers might change the IPv6 source and destination 738 fields, this field allows the receiver to observe how the locators 739 were rewritten, and also "echo" that back to the peer. This option 740 SHOULD be included in all the Shim6 control messages. 742 0 1 2 3 743 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type = 13 |0| Length = 36 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Reserved2 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | | 750 + Sender Locator + 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 + Receiver Locator + 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Fields: 760 Reserved2: 32-bit field. Reserved for future use. Zero on 761 transmit. MUST be ignored on receipt. (Needed to 762 make the ULIDs start on a multiple of 8 octet 763 boundary.) 765 Sender Locator: A 128-bit IPv6 address. 767 Receiver Locator: A 128-bit IPv6 address. 769 4.2.2. Received Locator Pair Option Format 771 When a host receives a shim6 control message, such as an I1 or Update 772 Request message, from its peer and will send a response message, then 773 if the "request" contained a Sent Locator Pair option, the host will 774 "echo" that option in unchanged but with the option type changed to 775 be a Received Locator Pair option. This allows the sending host to 776 see how the router rewrote its locators, which is useful information 777 for its locator selection. 779 The control messages that carry a Received Locator Pair option should 780 also carry a Sent Locator Pair option, to allow the discovery of the 781 rewriting that happens in the reverse direction. 783 0 1 2 3 784 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type = 14 |0| Length = 36 | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Reserved2 | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 + Sender Locator + 792 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 + Receiver Locator + 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Fields: 801 Reserved2: 32-bit field. Reserved for future use. Zero on 802 transmit. MUST be ignored on receipt. (Needed to 803 make the ULIDs start on a multiple of 8 octet 804 boundary.) 806 Sender Locator: A 128-bit IPv6 address. 808 Receiver Locator: A 128-bit IPv6 address. 810 5. Security Considerations 812 This document isn't known to introduce any new security 813 considerations other than those listed for Shim6 [7]. Since Shim6 814 satisfies the concerns specified in [22] that is likely to be 815 sufficient. 817 The suggest looking of identifiers to find the set of locators in 818 this document uses DNS. If DNSsec is not applied to the part of the 819 ip6.arpa tree where the IP identifiers are placed, then an attacker 820 could spoof the set of locators. This would result in a form of DoS 821 attack and not a redirection attack, since a host would verify the 822 CGA property when it receives the R2 message, and only the host which 823 "owns" the CGA-based ULID would be able to correctly sign the R2 824 message. 826 Of course, the DNS lookups of www.example.com to find the identifier 827 is still subject to DNS spoofing attacks, including redirection 828 attacks to a different ULID. 830 6. Acknowledgements 832 Over the years many people active in the multi6 and shim6 WGs have 833 contributed ideas a suggestions that are reflected in this 834 specification. The original ideas that has stimulated this work was 835 Mike O'Dell's GSE proposal. 837 7. References 839 7.1. Normative References 841 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 842 Levels", BCP 14, RFC 2119, March 1997. 844 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 845 Specification", RFC 2460, December 1998. 847 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 848 for IP Version 6 (IPv6)", RFC 2461, December 1998. 850 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 851 Autoconfiguration", RFC 2462, December 1998. 853 [5] Conta, A. and S. Deering, "Internet Control Message Protocol 854 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 855 Specification", RFC 2463, December 1998. 857 [6] Aura, T., "Cryptographically Generated Addresses (CGA)", 858 RFC 3972, March 2005. 860 [7] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 861 Protocol for IPv6", draft-ietf-shim6-proto-10 (work in 862 progress), February 2008. 864 [8] Bagnulo, M., "Hash Based Addresses (HBA)", 865 draft-ietf-shim6-hba-05 (work in progress), December 2007. 867 [9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 868 Exploration Protocol for IPv6 Multihoming", 869 draft-ietf-shim6-failure-detection-11 (work in progress), 870 February 2008. 872 7.2. Informative References 874 [10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 875 specifying the location of services (DNS SRV)", RFC 2782, 876 February 2000. 878 [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: 879 Defeating Denial of Service Attacks which employ IP Source 880 Address Spoofing", BCP 38, RFC 2827, May 2000. 882 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 883 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 885 [13] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 886 (SIP): Locating SIP Servers", RFC 3263, June 2002. 888 [14] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 889 Carney, "Dynamic Host Configuration Protocol for IPv6 890 (DHCPv6)", RFC 3315, July 2003. 892 [15] Draves, R., "Default Address Selection for Internet Protocol 893 version 6 (IPv6)", RFC 3484, February 2003. 895 [16] Bagnulo, M., "Updating RFC 3484 for multihoming support", 896 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 897 December 2005. 899 [17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 900 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 901 RFC 3550, July 2003. 903 [18] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 904 Multihoming Architectures", RFC 3582, August 2003. 906 [19] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 907 Flow Label Specification", RFC 3697, March 2004. 909 [20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 910 Requirements for Security", BCP 106, RFC 4086, June 2005. 912 [21] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 913 Addresses", RFC 4193, October 2005. 915 [22] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming 916 Solutions", RFC 4218, October 2005. 918 [23] Hinden, R. and S. Deering, "IP Version 6 Addressing 919 Architecture", RFC 4291, February 2006. 921 [24] Nikander, P., "An IPv6 Prefix for Overlay Routable 922 Cryptographic Hash Identifiers (ORCHID)", 923 draft-laganier-ipv6-khi-07 (work in progress), February 2007. 925 [25] Huitema, C., "Ingress filtering compatibility for IPv6 926 multihomed sites", draft-huitema-shim6-ingress-filtering-00 927 (work in progress), September 2005. 929 [26] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", 930 draft-bagnulo-shim6-mip-00 (work in progress), July 2005. 932 [27] Nordmark, E., "Shim6 Application Referral Issues", 933 draft-ietf-shim6-app-refer-00 (work in progress), July 2005. 935 [28] Bagnulo, M. and J. Abley, "Applicability Statement for the 936 Level 3 Multihoming Shim Protocol (Shim6)", 937 draft-ietf-shim6-applicability-03 (work in progress), 938 July 2007. 940 [29] Huston, G., "Architectural Commentary on Site Multi-homing 941 using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in 942 progress), July 2005. 944 [30] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 945 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 946 progress), October 2007. 948 [31] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 949 draft-ietf-mobike-protocol-08 (work in progress), 950 February 2006. 952 Author's Address 954 Erik Nordmark 955 Sun Microsystems 956 17 Network Circle 957 Menlo Park, CA 94025 958 USA 960 Phone: +1 650 786 2921 961 Email: erik.nordmark@sun.com 963 Full Copyright Statement 965 Copyright (C) The IETF Trust (2008). 967 This document is subject to the rights, licenses and restrictions 968 contained in BCP 78, and except as set forth therein, the authors 969 retain all their rights. 971 This document and the information contained herein are provided on an 972 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 973 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 974 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 975 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 976 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 979 Intellectual Property 981 The IETF takes no position regarding the validity or scope of any 982 Intellectual Property Rights or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in 984 this document or the extent to which any license under such rights 985 might or might not be available; nor does it represent that it has 986 made any independent effort to identify any such rights. Information 987 on the procedures with respect to rights in RFC documents can be 988 found in BCP 78 and BCP 79. 990 Copies of IPR disclosures made to the IETF Secretariat and any 991 assurances of licenses to be made available, or the result of an 992 attempt made to obtain a general license or permission for the use of 993 such proprietary rights by implementers or users of this 994 specification can be obtained from the IETF on-line IPR repository at 995 http://www.ietf.org/ipr. 997 The IETF invites any interested party to bring to its attention any 998 copyrights, patents or patent applications, or other proprietary 999 rights that may cover technology that may be required to implement 1000 this standard. Please address the information to the IETF at 1001 ietf-ipr@ietf.org. 1003 Acknowledgment 1005 Funding for the RFC Editor function is provided by the IETF 1006 Administrative Support Activity (IASA).