idnits 2.17.1 draft-nordmark-shim6-esd-00.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 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 26, 2006) is 6632 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 823, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 829, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 832, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 835, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 839, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 846, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 860, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 864, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 874, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 881, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 885, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 888, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 891, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 894, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 907, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 911, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 917, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 921, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 928, 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-03 == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-01 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 -- 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 (-07) exists of draft-laganier-ipv6-khi-00 == Outdated reference: A later version (-08) exists of draft-ietf-shim6-applicability-00 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-07 Summary: 8 errors (**), 0 flaws (~~), 29 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 30, 2006 February 26, 2006 6 Extended Shim6 Design for ID/loc split and Traffic Engineering 7 draft-nordmark-shim6-esd-00.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 30, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The Shim6 protocol provides for locator agility while satisfying the 41 'first, do no harm' security requirements. This document outlines 42 some extensions to Shim6 that in addition provides complete 43 separation between identifiers and locators, and allows routers to 44 rewrite the locators in the shim6 packets as a way to provide traffic 45 engineering information to the hosts. 47 The document also outlines a simple extension to allow shim6, with a 48 CGA upper-layer ID, to operate using 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 . . . . . . . . . . . . . . . . . 10 67 3.1 Recommending use of DNS SRV . . . . . . . . . . . . . . . 10 68 3.2 DHCPv6 option for Locator Preferences . . . . . . . . . . 11 69 3.3 Identifier to Locator lookup Preferences . . . . . . . . . 11 70 3.4 Locator Rewriting by Routers . . . . . . . . . . . . . . . 11 71 3.5 Walkthrough using locator rewriting . . . . . . . . . . . 12 72 3.6 Need for Coordination? . . . . . . . . . . . . . . . . . . 14 73 4. New Option Formats . . . . . . . . . . . . . . . . . . . . . . 16 74 4.1 New DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 16 75 4.2 New Shim6 Options . . . . . . . . . . . . . . . . . . . . 17 76 4.2.1 Sent Locator Pair Option Format . . . . . . . . . . . 17 77 4.2.2 Received Locator Pair Option Format . . . . . . . . . 18 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 82 7.2 Informative References . . . . . . . . . . . . . . . . . . 22 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 84 Intellectual Property and Copyright Statements . . . . . . . . 25 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 This document makes some, not completely arbitrary, assumptions for 130 the above issues, and presents an outline of how things could work 131 given those assumptions. The document shows that there is some 132 additional setup cost associated with identifier/locator separation 133 compared to shim6 just switching between a set of locators. We argue 134 that some additional overhead is inevitable; the benefits of 135 identifier/locator separation is to provide a layer of indirection 136 between the two, and this indirection necessitates some form of 137 lookup as part of initiating communication to an identifier. 139 1.2 Traffic Engineering 141 With the current style of IPv4 multihoming, which uses a single IP 142 address prefix and BGP, there is a range of BGP techniques that can 143 be used to affect the routing for that single prefix, and as a result 144 effect which path incoming traffic use to reach the site. Also, the 145 site itself can use some internal routing control to select which 146 egress path to use should a route be available via multiple egresses. 148 In any scheme that uses multiple address/locator prefixes per site 149 the mechanisms to control which packets flow over which ingress and 150 egress are likely to be completely different, since BGP would not be 151 able to correlate the different prefixes that are assigned to a 152 single site. This might imply that the traffic engineering 153 capabilities might be quite different. 155 As specified in shim6, the hosts select the ULID-pair, which by 156 convention is the initial locator pair, using RFC 3484bis [16]. With 157 the extensions specified in these documents there are two cases to 158 consider, depending on whether the ULID is a locator or the ULID is a 159 non-routable identifier: 161 o For ULIDs that are locators, RFC 3484bis still applies. In 162 addition, DNS SRV records [10] can be used as a way to give the 163 destination site some influence over which ULID = initial locator 164 is used, but that requires that the applications use SRV records. 166 o With ULIDs that are non-routable identifiers, there will most 167 likely be only one identifier for the destination as well as the 168 source. Thus the role of RFC 3484 is largely removed. But there 169 is an additional step of looking up the identifier to find the 170 locator, and at that point in time it makes sense to consider 171 traffic engineering for selecting the initial locator pair. 173 In both cases, shim6 already provides the mechanism of a Locator 174 Preference option which can be used by the peers to change the 175 preferences. But this mechanism assumes that there is a mechanism by 176 which a host in a site could be informed of its site's preferences. 177 We outline a DHCPv6 option in this document that could be used to 178 convey this information. 180 1.3 Shim6 using IPv4 addresses as locators 182 When CGA is used to prevent redirection attacks in shim6, there is no 183 constraint on the locators that are used apart from host B must know 184 its own locators so it can pass it them to host A. In particular, we 185 can use IPv4 addresses as locators; this doesn't require anything 186 more than defining how an IPv4 address is carried in the 128-bit 187 fields in the Locator List option. 189 As is the norm when suggesting to run an protocol over IPv4, after 5 190 milliseconds the question is raised how the protocol can operate over 191 IPv4 NAT boxes. For all protocols that adds one or two orders of 192 magnitude or more complexity, and shim6 is no exception. The 193 complexities lie in: 195 o Handling initial contact from the public side of the NAT box to a 196 host on the private side of the NAT box. All protocols end up 197 with some form of 3rd party device on the public side in order to 198 handle this. 200 o Maintaining the NAT state in the NAT box, and detecting when this 201 state has been lost and must be recreated. For shim6 the failure 202 detection mechanism [9] can detect this. 204 o Being able to recreate that state in the NAT after it has been 205 lost. 207 Thus while supporting IPv4 addresses as locators is easy, running 208 across NATs is complex. It is far from clear that this is worth- 209 while pursuing. 211 2. Identifier/Locator Split 213 This section outlines how non-routable identifiers can work in the 214 whole system, including their lookup and how they are used in shim6. 215 There are likely to be alternative designs, so this is by no means 216 believed to be the optimal approach, but working out some number of 217 details is still a useful exercise and helps have more concrete 218 discussions. 220 2.1 Syntax, Semantics, and Allocation of non-routable identifiers 222 In order for applications, which have been ported to use the IPv6 223 APIs that carry 128-bit IPv6 addresses, to not have to be ported 224 again, it makes sense to try to make do with an syntax that fits in 225 128 bits. Note that one could wish that we could apply this to the 226 IPv4 32-bit APIs, but with a future Internet with more than 4 billion 227 hosts, trying to support the IPv4 APIs to identify each host would be 228 impossible. 230 Since we are likely to have applications communicate to both hosts 231 which have an IP identifier and those which only have the IP 232 locators, it is highly desirable to be able to have a syntactic means 233 to tell an IP identifier apart from an IP locator. A reasonable 234 approach is to allocate a small subset of the IPv6 address space [23] 235 to be non-routable IP identifiers, in a similar means to the KHI 236 approach [24]. 238 The desired semantics of an IP identifier is to be a name that refers 239 to an instance of the IP protocol. Hence it should not be bound to a 240 particular network interface. Also, it is desirable for the 241 identifier to be long term stable, for instance ensuring that the 242 identifier survives renumbering. 244 As we will discuss below, for application referrals to work using 245 128-bit IP "addresses" as handles for another host, there has to be 246 an efficient and scalable way to look up an identifier and find the 247 locators. An obvious way to get scalability is to do hierarchical 248 allocation of the identifiers, since this allows for a scalable, 249 hierarchical organization of a lookup system and also ensures that 250 the identifiers are unique. 252 While it certainly isn't the only possibility, in order to work out a 253 complete picture, this document suggests such a hierarchical 254 allocation, in such a way that at least 64 bits of the identifier is 255 left to each site to allocate. (With 64 bits we can use CGA to 256 "prove" identifier ownership as a way to prevent redirection attacks 257 from off-path attackers.) 259 2.2 Domain name lookup to find the Identifier 261 Many applications start their communication by knowing the fully- 262 qualified domain name of the peer, and they look this up in the DNS 263 to find AAAA and A records for that peer. As we introduce a separate 264 IP Identifier we want the same capability, but we also need to avoid 265 disturbing existing IPv6 hosts which would not be able to deal with 266 an IP identifier, since they assume all AAAA records contain routable 267 locators. 269 A conceptually clean way to handle this is to introduce a separate ID 270 resource record type in the DNS, which has the same right-hand side 271 as the AAAA records. Then hosts which implement support for the IP 272 identifier would first look for an ID record, and if none found, look 273 for AAAA and A records. This would work, but adds inefficiencies 274 until (or unless) most hosts have ID records. 276 An alternative would be to overload AAAA records to contain both 277 identifiers and locators and rely on RFC 3484 to avoid accidentally 278 picking an identifier on a host which doesn't understand what an IP 279 identifier is. Then the hosts which do understand IP identifiers can 280 ignore the routable locators in the AAAA RRset. The choice between 281 those two, or other alternatives, doesn't materially affect how the 282 rest of identifier/locator separation would work. 284 2.3 Identifier Lookup to find the Locators using the DNS 286 One can do different forms of lookup systems for the identifier to 287 locator lookup. The least "novel" one would be to reuse the DNS. 288 Since the identifier is drawn from the IPv6 address space, a possible 289 way to do this in the DNS is to use the ip6.arpa tree for this, with 290 its ability to delegate on nibble boundaries. 292 A simple way to do this would be to just have normal PTR records in 293 the reverse tree that "point" to a fully-qualified domain name, and 294 then do lookups for AAAA records matching that domain name. But this 295 doesn't allow the destination domain to influence the locator 296 selection as part of the lookup. Thus it might make sense to instead 297 deploy DNS SRV records in the reverse zone since this would allow 298 specifying a priority and a weight for primary/backup and load 299 spreading, respectively. 301 2.4 Handling Application Referrals 303 A referral is the case when three or more instances of an application 304 interacts and the first instance communicates with the second 305 instance, and then communicates with the third instances and wishes 306 to tell the third instance how to contact the second instance. There 307 are application patters, called callbacks and long-lived application 308 associations in [27] that have similar issues. The application can 309 handle these by using and passing the fully-qualified domain name, or 310 it can do it by storing and passing the IP address. In the latter 311 case, this application ends up depending on the IP address being 312 universally useful as a way to contact another host. 314 Assuming we want to keep such applications functioning with the 315 introduction of the identifier/locator split, it is necessary that 316 the 128 bit identifier can be useful on a host which didn't do the 317 DNS lookup and does not know the fully-qualified domain name of that 318 peer. 320 The approach outlined in this section handles this case, since the 321 identifier will be looked up in ip6.arpa to find the locators. 323 2.5 Walkthrough of an example 325 The following example shows how the above use of DNS interacts with 326 shim6. This assumes that the destination host, www.example.com, has 327 been allocated an IP identifier and that IP identifier has been 328 entered as an ID RR in the DNS. 330 The application calls getaddrinfo() for www.example.com, and that 331 performs a DNS lookup for an ID record for www.example.com. Since 332 a record was found, it returns this as a 128-bit IPv6 address. 333 (If no records was found, then getaddrinfo() would have looked for 334 AAAA and A records.) 336 The application, without making any distinction between an IP 337 identifier and a locator, passes this address to the connect() or 338 sendto() calls, depending on which transport protocol it uses. 340 The transport protocol proceeds as normal, which includes picking 341 a source address which "matches" the destination address. The RFC 342 3484 rules might very well be sufficient for this; alternatively 343 the transport protocols would be modified to explicitly know that 344 when the destination is an identifier (it has a well-known, KHI- 345 like prefix) it must pick a source address which is also an 346 identifier, and vice versa for a destination which is a locator. 348 A packet (for instance, a TCP SYN) from the transport protocol 349 arrives at the shim6 shim layer on the host. The shim looks for a 350 context which matches the ULID pair. Since we assume this is the 351 first attempt to communicate with this ULID, there is no existing 352 context. 354 The shim checks if the destination ULID is a locator or an 355 identifier. If it is a locator it proceeds as specified in Shim6 356 [7] and none of the items below apply. If it is an identifier, 357 then the shim needs to find the set of locators for the 358 identifier. 360 The shim performs the identifier to locator lookup very similarly 361 to normal IPv6 reverse lookups (form a query name based on the 362 nibbles in reverse order and append ip6.arpa), but it queries for 363 SRV records. 365 Assuming one or more SRV records are returned, the shim takes the 366 priority and and weight into account as specified in [10] to order 367 the locators. 369 The shim then forms a I1 packet as specified in [7] and includes a 370 ULID pair option (to carry the ULIDs which are different than the 371 locators). 373 The rest of the context establishment follows as in [7] with the 374 ULID option. The presence of the ULID option implies that the 375 peer will verify the locators using the CGA ULID properties when 376 receiving the I2 message, and the host itself will verify its 377 peer's locators the same way when receiving the R2 message. 379 The rest of shim6 remain unmodified, except that the Locator Update, 380 Keepalive, and Probe messages should probably carry the ULID option 381 as well. Alternatively, one could rely on the 47-bit context tag to 382 identify the context. 384 2.6 Design Alternatives 386 If the identifiers are placed in the DNS using AAAA records, then the 387 lookup for the AAAA record set (to find the identifier) might also 388 return a list of locators. Such a list can potentially be useful to 389 avoid the ip6.arpa lookup to find the locators. But relying on this 390 means that the reverse lookup from the identifier will only be used 391 in uncommon cases such as: 393 o The shim6 context state having been garbage collected too early, 394 and the upper-layer protocol sends down a packet with a 395 destination ULID which is a non-routable identifier. 397 o Application callbacks, referrals, and long-lived application 398 handles [27] that are IP addresses. 400 For this reason it makes sense to be more consistent and always rely 401 on the reverse lookup when the context is established. 403 3. Traffic Engineering Support 405 The traffic engineering pieces that might be desirable and that are 406 easy to implement in this model are outlined in this section. If the 407 ULID is a routable locator, then it makes sense to recommend that 408 applications use DNS SRV records for the initial (non-shimmed) 409 contact, and also provide at least a DHCPv6 option by which a site 410 administrator can control what each host in the site uses in the 411 shim6 Locator Preference option. 413 In the case when the ULID is a non-routable identifier, a different 414 set of mechanisms are desirable. Instead of using DNS SRV records 415 for the lookup of the domain name of the peer, we want similar 416 control when looking up an identifier to find the set of locators. 418 For both cases it has been argued that allowing the routers, in 419 particular routers located close to the egress from a site, to 420 rewrite the source locators, as a mechanism to indicate to the hosts 421 a dynamic change in the preferred locators. We outline the mechanism 422 for this below and we also discuss the policy issues which are 423 introduced with this additional information from the routers. 425 Note that we do not currently have a set of agreed upon requirements 426 for traffic engineering. The closest we have to requirements are 427 Jason Schiller's slides at 428 http://www.iab.org/documents/open-mtgs/2005-10-23-schiller.pdf 430 3.1 Recommending use of DNS SRV 432 In shim6 as specified, the host rely on existing DNS mechanisms, such 433 as AAAA records or any other mechanism, to find a list of locators to 434 try. When AAAA records are used, there is no mechanism for the 435 destination site to express any ranking for primary/fallback, or any 436 mechanism to spread load across the paths that are represented by the 437 locators, since the AAAA resource record set is treated as a set with 438 no implied order. 440 If we could use DNS SRV records instead, then we would have the 441 combination of the SRV priority (for primary/backup) and SRV weight 442 (for specifying a weighted, random load spreading) as tools for the 443 site administrator to use. 445 Unfortunately it is the application software developer which needs to 446 explicitly decide to use SRV records, thus we can not require that 447 shim6 implementations also have the applications use SRV, since the 448 application developer is in most cases different than the implementor 449 of the TCP/IP protocol stack. But it would be helpful to the IETF to 450 make a strong recommendation that applications should use SRV 451 records. 453 Note that in some cases it quite complex to specify how an 454 application uses SRV records. SIP is an example of this [13], which 455 needs to deal with SIP running over multiple transport protocols, SRV 456 vs. AAAA and A record ordering, and various other issues. But in 457 common cases like http that run over a single transport, the needed 458 change is just to precede the lookups for AAAA and A records at 459 www.example.com with a lookup for SRV at _http._tcp.www.example.com. 461 3.2 DHCPv6 option for Locator Preferences 463 Shim6 [7] specifies a Locator Preference option which can carry some 464 number of octets, with the protocol currently specifying the 465 semantics of the first three octets of each preference element. One 466 way to allow the site administrator to control this is to introduce a 467 new DHCPv6 [14] option which carries the list of IPv6 locator 468 prefixes that the site uses and the octets of shim6 preference 469 element; this can be done without the host having to understand the 470 semantics of the octets it is sending - it can just copy them from 471 the DHCPv6 option, even though the host will interpret the locator 472 preference octet string it receives from the peer. 474 To be concrete, we show an example of what such a DHCPv6 option can 475 look like in Section 4.1. 477 3.3 Identifier to Locator lookup Preferences 479 As specified in Section 2.3 it makes sense to use SRV records for the 480 reverse lookup used to go from an identifier to a set of locators, 481 since this allows the site manager to provide priority and weight to 482 the peer before the initial contact takes place, thus most likely the 483 initial locator chosen by the host will be a reasonable one from the 484 perspective of traffic engineering for the peer site. 486 3.4 Locator Rewriting by Routers 488 Shim6 as specified [7] allows routers to rewrite the locators on 489 shim6 packets that are payload extension headers, but it does not 490 allow such rewrites on the shim6 control messages. In this section 491 we outline what it would take to allow such rewriting on all the 492 shim6 messages, and also provide the host with an indication of how 493 their locators are rewritten so that they can take this into account. 495 With these extensions the routers are free to rewrite the locators 496 with alternate values in any IPv6 packet that has a shim6 header 497 (i.e., where some next header value is IPPROTO_SHIM6). 499 The support for this rewriting consists of: 501 o Introducing a new Sent Locator Pair option, which the receiver or 502 a packet can use to see how the routers rewrote the locators in a 503 packet sent towards it. The receiver also "echos" this 504 information to its peer using the next option. 506 o Introducing a new Received Locator Pair option, which is a echo of 507 the content of a received Sent Locator Pair option. 509 o The hosts SHOULD include a shim6 extension header for ULP payloads 510 where the sending shim does not rewrite the locators, in order to 511 allow the routers to rewrite the locators. 513 o To maximize the utility of the locator rewriting, we should avoid 514 the use of deferred context establishment. If the first packet 515 sent is an I1 packet, and the above SHOULD is honored, then the 516 routers are free to rewrite the locators in all the packets that 517 are exchanged between a pair of shim6 hosts. (If we are also 518 doing complete identifier/locator split, then there is no deferred 519 context establishment, thus this doesn't add any additional 520 costs.) 522 o As in the current shim6 specification, any source and destination 523 locator can be used on a shim6 payload message as long as the 524 context tag matches. But in addition, when the receiver of a 525 payload message observes a change in the locator pair on which it 526 receives the payload extension headers, it SHOULD notify the peer 527 of this by sending an Update Request message with a Received 528 Locator Pair option. Such update messages MUST be rate limited 529 since the locators can flap when routing is flapping. 531 3.5 Walkthrough using locator rewriting 533 The following example shows how the Sent Locator Pair and Received 534 Locator Pair options are used as part of the Shim6 context 535 establishment exchange, and indicates some of the policy choices that 536 exist in terms of what locator is chosen. The same exchange applies 537 whether the ULID is a reachable locator or not; when the ULID is an 538 unreachable identifier then there would be an ULID option in most of 539 the shim6 control messages, but we omit that aspect here as we focus 540 on the locator exchanges. 542 We assume that host A, which locators A1, A2, and A3, is 543 communicating with host B, with locators B1 and B2. 545 The walkthrough starts when A is sending an I1 message to B: 547 The shim then forms a I1 packet as specified in [7] and includes a 548 Sent Locator Pair option. The shim has chosen A1 to be the source 549 locator and B1 to be the destination locator, thus it places in both IPv6 header (as source and destination), and in the 551 Sent Locator Pair option. 553 The routers, for instance, the egress router from A's site, might 554 rewrite the IPv6 source address field with a different prefix so 555 that when the packet is receive by B it has in the IPv6 556 header (and the Sent Locator Pair option is unmodified with ). 559 B processes the I1 message as specified in [7] to generate a R1 560 message. In addition, it copies the content of the Sent Locator 561 Pair option into a Received Locator Pair option. Host B must 562 decide whether it should send the R1 message to the IP source 563 address of the R1 message, or send it to the potentially different 564 Sender Locator in the Sent Locator Pair option in the I1 message. 565 Once B has made this decision, it puts the addresses, in this 566 example in the IPv6 header as well as into a Sent Locator 567 Pair option. 569 Host A receives the R1 message and finds the context state. At 570 this point in time A can see how the router rewrote the I1 message 571 by comparing the Lp(local), Lp(peer) with the Received Locator 572 Pair option. It can also see how the locators were rewritten for 573 the return path by comparing the IPv6 header in the R1 message 574 with the Sent Locator Pair option. It might be that the Received 575 Locator Pair option has a Sender Locator which is not one of the 576 locators that host A knows as its own. In this case it it might 577 reasonable for A to treat this locator as its own, at least in 578 terms of accepting packets destined to it. Host A forms a normal 579 I2 message, but also includes a Received Locator Pair option in 580 it. The host chooses the locator pair to use when sending the I2 581 message, and if the source address of the R1 message is one of B's 582 locators, then this might be the best choice. Just as for the I1 583 message, the host adds a Sent Locator Pair option to the I2 584 message which contains a copy of the source and destination fields 585 in the IPv6 header. 587 Host B receives the I2 message and finds the context state. At 588 this point in time B can see how the routers on the return path 589 rewrote the I2 message by comparing the IPv6 header in the I2 590 message with the Sent Locator Pair option. It might be that the 591 Received Locator Pair option has a Sender Locator which is not one 592 of the locators that host B knows as its own. In this case it it 593 might reasonable for B to treat this locator as its own, at least 594 in terms of accepting packets destined to it. Host B forms a 595 normal R2 message, but also includes a Received Locator Pair 596 option in it. The host chooses the locator pair to use when 597 sending the R2 message, and if the source address of the I2 598 message is one of A's locators (that it in the Locator List 599 option), then this might be the best choice. Just as for the R1 600 message, the host adds a Sent Locator Pair option to the R2 601 message which contains a copy of the source and destination fields 602 in the IPv6 header. 604 The host maintains Lp(local) and Lp(peer) to use as the preferred 605 source and destination address when sending packets to the peer. But 606 in addition the hosts main a Lr(local) ["r" for "received"] and 607 Lr(peer) that is the locator pair in the most recently received 608 packet for the context. 610 When a packet with a Payload Extension Header is received for the 611 context and the source or destination address does not match 612 Lr(peer)/Lr(local), then, subject to rate limiting, the host forms an 613 Update Request message with a Received Locator Pair option. This 614 Update Request message is transmitted and retransmitted as specified 615 in [7]. This allows the peer to be notified should the routers 616 change the way the rewrite the locators, which the host can use to 617 make sure the packets have the correct locators as they are 618 originated. 620 3.6 Need for Coordination? 622 It might be the case that the routers are not aware of the the actual 623 prefixes assigned to each host. For instance, just because a site 624 has 7 different prefixes, there might be some host that due to 625 resource considerations or DHCP sever policy only configure addresses 626 in a subset of these prefixes. Thus the routers might rewrite the 627 source locator to be a locator which is not assigned to the source 628 host. If host B were to respond to an I1 message that had been 629 rewritten this way, then the R1 message would not be accepted by host 630 A. For this reason it is recommended that the I1 and R1 messages 631 include the Locator List option, and that the receiver of these 632 messages reply using the Sender Locator in the the Sent Locator Pair 633 option, in the case when the IPv6 source address is not part of the 634 Locator List option. 636 Also, it is recommended that hosts "learn" new locators from the 637 Received Locator Pair option, so that they will in the future accept 638 packets destined to the locators that they routers use when 639 rewriting, even if the hosts aren't otherwise configured with those 640 addresses. Note that for shim6 to be able to prove to the peer that 641 the host in fact "owns" such a locator, the host must have a CGA ULID 642 and sign an Update Request message with the new locator set. Whether 643 it is a good idea to always "adopt" locators from the Received 644 Locator Pair option is TBD. 646 4. New Option Formats 648 4.1 New DHCPv6 Option 650 This option follows the DHCPv6 [14] format for options and allows the 651 DHCP server to specify what the host will put in the Shim6 Locator 652 Preference option. The DHCPv6 option carries IPv6 address prefixes, 653 and the host will apply the logest matching such prefix to each of 654 its IPv6 locators. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | option-code | option-len | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Prefix Length1| | 662 +-+-+-+-+-+-+-+-+ Prefix 1 | 663 | | 664 | +-+-+-+-+-+-+-+-+ 665 | | Elem len 1 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Element 1 (len octets) | Prefix Length2| | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 669 | Prefix 2 | 670 | | 671 | +-+-+-+-+-+-+-+-+ 672 | | Elem len 2 | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Element 2 (len octets) | | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 676 | ... | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Fields: 681 option-code: 16-bit unsigned integer. To be allocated by the IANA. 683 option-len: 16-bit unsigned integer. The length in octets of all 684 the fields in the option which follow the option-len 685 field. 687 Prefix Length[n]: 8-bit unsigned integer. The number of relevant 688 bits in Prefix[n]. 690 Prefix[n]: An IPv6 address prefix. The length of this field is 691 the number of octets necessary to carry Prefix 692 Length[2] bits. For instance, a 47-bit Prefix Length 693 would mean that the Prefix field is 6 octets. 695 Element Len[n]: 8-bit unsigned integer. The number of octets of 696 Element[n] that follows the Element Len field. 698 Element[n]: One or more octets that can be directly copied to the 699 Shim6 Locator Prefix option's Element field. 701 4.2 New Shim6 Options 703 This document defines two new Shim6 options. 705 +------+-----------------------+ 706 | Type | Option Name | 707 +------+-----------------------+ 708 | 13 | Sent Locator Pair | 709 | | | 710 | 14 | Received Locator Pair | 711 +------+-----------------------+ 713 Table 1 715 4.2.1 Sent Locator Pair Option Format 717 This option carries the set source and destination locators as sent 718 by the sender, that is, the sender sets them to the same values as 719 the IPv6 source and destination fields. When router rewriting is in 720 use, then the routers might change the IPv6 source and destination 721 fields, this field allows the receiver to observe how the locators 722 were rewritten, and also "echo" that back to the peer. This option 723 SHOULD be included in all the Shim6 control messages. 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Type = 13 |0| Length = 36 | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Reserved2 | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 + Sender Locator + 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | 737 + Receiver Locator + 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Fields: 742 Reserved2: 32-bit field. Reserved for future use. Zero on 743 transmit. MUST be ignored on receipt. (Needed to 744 make the ULIDs start on a multiple of 8 octet 745 boundary.) 747 Sender Locator: A 128-bit IPv6 address. 749 Receiver Locator: A 128-bit IPv6 address. 751 4.2.2 Received Locator Pair Option Format 753 When a host receives a shim6 control message, such as an I1 or Update 754 Request message, from its peer and will send a response message, then 755 if the "request" contained a Sent Locator Pair option, the host will 756 "echo" that option in unchanged but with the option type changed to 757 be a Received Locator Pair option. This allows the sending host to 758 see how the router rewrote its locators, which is useful information 759 for its locator selection. 761 The control messages that carry a Received Locator Pair option should 762 also carry a Sent Locator Pair option, to allow the discovery of the 763 rewriting that happens in the reverse direction. 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Type = 14 |0| Length = 36 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Reserved2 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | | 773 + Sender Locator + 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 + Receiver Locator + 778 | | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Fields: 783 Reserved2: 32-bit field. Reserved for future use. Zero on 784 transmit. MUST be ignored on receipt. (Needed to 785 make the ULIDs start on a multiple of 8 octet 786 boundary.) 788 Sender Locator: A 128-bit IPv6 address. 790 Receiver Locator: A 128-bit IPv6 address. 792 5. Security Considerations 794 This document isn't known to introduce any new security 795 considerations other than those listed for Shim6 [7]. Since Shim6 796 satisfies the concerns specified in [22] that is likely to be 797 sufficient. 799 The suggest looking of identifiers to find the set of locators in 800 this document uses DNS. If DNSsec is not applied to the part of the 801 ip6.arpa tree where the IP identifiers are placed, then an attacker 802 could spoof the set of locators. This would result in a form of DoS 803 attack and not a redirection attack, since a host would verify the 804 CGA property when it receives the R2 message, and only the host which 805 "owns" the CGA-based ULID would be able to correctly sign the R2 806 message. 808 Of course, the DNS lookups of www.example.com to find the identifier 809 is still subject to DNS spoofing attacks, including redirection 810 attacks to a different ULID. 812 6. Acknowledgements 814 Over the years many people active in the multi6 and shim6 WGs have 815 contributed ideas a suggestions that are reflected in this 816 specification. The original ideas that has stimulated this work was 817 Mike O'Dell's GSE proposal. 819 7. References 821 7.1 Normative References 823 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 824 Levels", BCP 14, RFC 2119, March 1997. 826 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 827 Specification", RFC 2460, December 1998. 829 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 830 for IP Version 6 (IPv6)", RFC 2461, December 1998. 832 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 833 Autoconfiguration", RFC 2462, December 1998. 835 [5] Conta, A. and S. Deering, "Internet Control Message Protocol 836 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 837 Specification", RFC 2463, December 1998. 839 [6] Aura, T., "Cryptographically Generated Addresses (CGA)", 840 RFC 3972, March 2005. 842 [7] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 843 protocol", draft-ietf-shim6-proto-03 (work in progress), 844 December 2005. 846 [8] Bagnulo, M., "Hash Based Addresses (HBA)", 847 draft-ietf-shim6-hba-01 (work in progress), October 2005. 849 [9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 850 Exploration Protocol for IPv6 Multihoming", 851 draft-ietf-shim6-failure-detection-03 (work in progress), 852 December 2005. 854 7.2 Informative References 856 [10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 857 specifying the location of services (DNS SRV)", RFC 2782, 858 February 2000. 860 [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: 861 Defeating Denial of Service Attacks which employ IP Source 862 Address Spoofing", BCP 38, RFC 2827, May 2000. 864 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 865 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 867 [13] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 868 (SIP): Locating SIP Servers", RFC 3263, June 2002. 870 [14] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 871 Carney, "Dynamic Host Configuration Protocol for IPv6 872 (DHCPv6)", RFC 3315, July 2003. 874 [15] Draves, R., "Default Address Selection for Internet Protocol 875 version 6 (IPv6)", RFC 3484, February 2003. 877 [16] Bagnulo, M., "Updating RFC 3484 for multihoming support", 878 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 879 December 2005. 881 [17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 882 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 883 RFC 3550, July 2003. 885 [18] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 886 Multihoming Architectures", RFC 3582, August 2003. 888 [19] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 889 Flow Label Specification", RFC 3697, March 2004. 891 [20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 892 Requirements for Security", BCP 106, RFC 4086, June 2005. 894 [21] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 895 Addresses", RFC 4193, October 2005. 897 [22] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming 898 Solutions", RFC 4218, October 2005. 900 [23] Hinden, R. and S. Deering, "IP Version 6 Addressing 901 Architecture", RFC 4291, February 2006. 903 [24] Nikander, P., "A Non-Routable IPv6 Prefix for Keyed Hash 904 Identifiers (KHI)", draft-laganier-ipv6-khi-00 (work in 905 progress), September 2005. 907 [25] Huitema, C., "Ingress filtering compatibility for IPv6 908 multihomed sites", draft-huitema-shim6-ingress-filtering-00 909 (work in progress), September 2005. 911 [26] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", 912 draft-bagnulo-shim6-mip-00 (work in progress), July 2005. 914 [27] Nordmark, E., "Shim6 Application Referral Issues", 915 draft-ietf-shim6-app-refer-00 (work in progress), July 2005. 917 [28] Abley, J., "Shim6 Applicability Statement", 918 draft-ietf-shim6-applicability-00 (work in progress), 919 July 2005. 921 [29] Huston, G., "Architectural Commentary on Site Multi-homing 922 using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in 923 progress), July 2005. 925 [30] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-04 926 (work in progress), October 2005. 928 [31] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 929 draft-ietf-mobike-protocol-07 (work in progress), 930 December 2005. 932 Author's Address 934 Erik Nordmark 935 Sun Microsystems 936 17 Network Circle 937 Menlo Park, CA 94025 938 USA 940 Phone: +1 650 786 2921 941 Email: erik.nordmark@sun.com 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; nor does it represent that it has 950 made any independent effort to identify any such rights. Information 951 on the procedures with respect to rights in RFC documents can be 952 found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use of 957 such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository at 959 http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 Disclaimer of Validity 969 This document and the information contained herein are provided on an 970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 977 Copyright Statement 979 Copyright (C) The Internet Society (2006). This document is subject 980 to the rights, licenses and restrictions contained in BCP 78, and 981 except as set forth therein, the authors retain all their rights. 983 Acknowledgment 985 Funding for the RFC Editor function is currently provided by the 986 Internet Society.