idnits 2.17.1 draft-ietf-shim6-l3shim-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1281. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 a Security Considerations section. ** 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.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3484' is mentioned on line 289, but not defined ** Obsolete undefined reference: RFC 3484 (Obsoleted by RFC 6724) == Missing Reference: 'M6REFER' is mentioned on line 302, but not defined == Missing Reference: 'RFC 3041' is mentioned on line 359, but not defined ** Obsolete undefined reference: RFC 3041 (Obsoleted by RFC 4941) == Missing Reference: 'RFC2461' is mentioned on line 685, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) == Missing Reference: 'RFC2462' is mentioned on line 691, but not defined ** Obsolete undefined reference: RFC 2462 (Obsoleted by RFC 4862) == Missing Reference: 'RFC 3697' is mentioned on line 920, but not defined ** Obsolete undefined reference: RFC 3697 (Obsoleted by RFC 6437) == Unused Reference: 'ADDR-ARCH' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'RFC3697' is defined on line 1146, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-multi6-multihoming-threats-00 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-threats (ref. 'M6THREATS') ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) -- Possible downref: Normative reference to a draft: ref. 'M6FUNC' == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-00 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-00 == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-08 == Outdated reference: A later version (-02) exists of draft-ietf-ipv6-ula-central-00 -- No information found for draft-crocker-mast-protocol - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 Summary: 14 errors (**), 0 flaws (~~), 20 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 July 9, 2005 Sun Microsystems 4 Marcelo Bagnulo 5 UC3M 7 Multihoming L3 Shim Approach 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet Draft expires January 9, 2006. 36 Abstract 38 This document specifies a particular approach to IPv6 multihoming. 39 The approach is based on using a multihoming shim placed between the 40 IP endpoint sublayer and the IP routing sublayer, and, at least 41 initially, using routable IP locators as the identifiers visible 42 above the shim layer. The approach does not introduce a "stack name" 43 type of identifier, instead it ensures that all upper layer protocols 44 can operate unmodified in a multihomed setting while still seeing a 45 stable IPv6 address. 47 This document does not specify the mechanism for authenticating and 48 authorizing the "rehoming" - this is specified in the HBA document. 50 Nor does it specify the messages used to establish multihoming state. 52 The document does not even specify the packet format used for the 53 data packets. Instead it discusses the issue of receive side 54 demultiplexing and the different tradeoffs. The resolution of this 55 issue will affect the packet format for the data packets. 57 Contents 59 1. Introduction............................................. 4 60 1.1. Non-Goals........................................... 4 61 1.2. Assumptions......................................... 5 63 2. Terminology.............................................. 5 64 2.1. Notational Conventions.............................. 7 66 3. Overview................................................. 7 68 4. Locators as Upper-layer Identifiers...................... 8 69 4.1. IP Multicast........................................ 8 70 4.2. Renumbering Implications............................ 9 72 5. Placement of the multihoming shim........................ 9 73 5.1. Shim Implications on Flow Label Usage............... 12 74 5.2. Shim Implications on ICMP errors.................... 12 75 5.3. Other Shim Protocol Implications.................... 13 76 5.4. MTU Implications.................................... 13 78 6. Deferred Context Establishment........................... 14 80 7. Assumptions about the DNS................................ 14 81 7.1. DNS and Unique-local Addresses...................... 15 83 8. Protocol Walkthrough..................................... 15 84 8.1. Initial Context Establishment....................... 15 85 8.2. Locator Change...................................... 16 86 8.3. Concurrent Context Establishment.................... 17 87 8.4. Handling Initial Locator Failures................... 17 89 9. Demultiplexing of data packets in shim6 communications... 18 90 9.1. Approaches preventing the existence of ambiguities.. 19 91 9.1.1. Pre-agreed identifiers......................... 19 92 9.1.2. N-square addresses............................. 20 93 9.2. Providing additional information to the receiver.... 20 94 9.2.1. Flow-label..................................... 21 95 9.2.2. Extension Header............................... 23 96 9.3. Host-Pair Context................................... 23 98 10. IPSEC INTERACTIONS...................................... 24 100 11. OPEN ISSUES............................................. 24 102 12. ACKNOWLEDGMENTS......................................... 25 104 13. REFERENCES.............................................. 25 105 13.1. Normative References............................... 25 106 13.2. Informative References............................. 26 108 14. CHANGE LOG.............................................. 27 110 AUTHORS' ADDRESSES........................................... 29 112 1. Introduction 114 The goal of the IPv6 multihoming work is to allow a site to take 115 advantage of multiple attachments to the global Internet without 116 having a specific entry for the site visible in the global routing 117 table. Specifically, a solution should allow users to use multiple 118 attachments in parallel, or to switch between these attachment points 119 dynamically in the case of failures, without an impact on the upper 120 layer protocols. 122 The goals for this approach is to: 124 o Preserve established communications through failures, for example, 125 TCP connections and application communications using UDP. 127 o Have no impact on upper layer protocols in general and on 128 transport protocols in particular. 130 o Address the security threats in [M6THREATS] through a separate 131 document [HBA] 133 o No extra roundtrip for setup; deferred setup. 135 o Take advantage of multiple locators/addresses for load spreading 136 so that different sets of communication to a host (e.g., different 137 connections) might use different locators of the host. 139 1.1. Non-Goals 141 The assumption is that the problem we are trying to solve is site 142 multihoming, with the ability to have the set of site locator 143 prefixes change over time due to site renumbering. Further, we 144 assume that such changes to the set of locator prefixes can be 145 relatively slow and managed; slow enough to allow updates to the DNS 146 to propagate. But it is not a goal to try to make communication 147 survive a renumbering event (which causes all the locators of a host 148 to change to a new set of locators). This proposal does not attempt 149 to solve, perhaps related, problems such as host multihoming or host 150 mobility. 152 This proposal also does not try to provide an IP identifier. Even 153 though such a concept would be useful to ULPs and applications, 154 especially if the management burden for such a name space was zero 155 and there was an efficient yet secure mechanism to map from 156 identifiers to locators, such a name space isn't necessary (and 157 furthermore doesn't seem to help) to solve the multihoming problem. 159 1.2. Assumptions 161 This approach assumes that packets with arbitrary combinations of 162 source and destination locators will make it from end to end unless 163 there is some form of failure. Due to the interaction between 164 ingress filtering [RFC2827] and source address selection, this 165 assumption might not be true in IPv6 today. As a result there is a 166 need to work out a solution that doesn't make the ingress filtering 167 in ISPs drop more packets than needed. 169 Furthermore, a solution following the outline in this document and 170 companion shim6 WG documents will most likely end up assuming that a 171 host can affect the exit path from the site. In particular, should 172 the host send packets with all combinations of its addresses in the 173 IP source address field and all of the peers addresses in the 174 destination field, that with high probability that set of packets 175 ends up using multiple exits from the site (going via different 176 ISPs), when the site is connected to multiple ISPs. (Of course, the 177 network admin might have disabled this somehow, but in order for the 178 multihoming solution to find a working path it needs to have the 179 ability to explore different exits somehow.) 181 Some solutions to this have been proposed in [INGRESS]. 183 2. Terminology 185 upper layer protocol (ULP) 186 - a protocol layer immediately above IP. Examples are 187 transport protocols such as TCP and UDP, control 188 protocols such as ICMP, routing protocols such as 189 OSPF, and internet or lower-layer protocols being 190 "tunneled" over (i.e., encapsulated in) IP such as 191 IPX, AppleTalk, or IP itself. 193 interface - a node's attachment to a link. 195 address - an IP layer name that contains both topological 196 significance and acts as a unique identifier for an 197 interface. 128 bits. This document only uses the 198 "address" term in the case where it isn't specific 199 whether it is a locator or a identifier. 201 locator - an IP layer topological name for an interface or a 202 set of interfaces. 128 bits. The locators are 203 carried in the IP address fields as the packets 204 traverse the network. 206 identifier - an IP layer name for an IP layer endpoint (stack 207 name in [NSRG]). The transport endpoint name is a 208 function of the transport protocol and would 209 typically include the IP identifier plus a port 210 number. NOTE: This proposal does not specify any 211 new form of IP layer identifier, but still separates 212 the identifying and locating properties of the IP 213 addresses. 215 upper-layer identifier (ULID) 216 - an IP locator which has been selected for 217 communication with a peer to be used by the upper 218 layer protocol. 128 bits. This is used for 219 pseudo-header checksum computation and connection 220 identification in the ULP. Different sets of 221 communication to a host (e.g., different 222 connections) might use different ULIDs in order to 223 enable load spreading. 225 Since the ULID is just one of the IP 226 locators/addresses of the node, there is no need for 227 a separate name space and allocation mechanisms. 229 address field 230 - the source and destination address fields in the 231 IPv6 header. As IPv6 is currently specified this 232 fields carry "addresses". If identifiers and 233 locators are separated these fields will contain 234 locators for packets on the wire. 236 FQDN - Fully Qualified Domain Name 238 Host-pair context 239 - the state that the multihoming shim maintains for a 240 particular peer. The peer is identified by one or 241 more ULIDs. 243 2.1. Notational Conventions 245 A, B, and C are hosts. X is a potentially malicious host. 247 FQDN(A) is the domain name for A. 249 Ls(A) is the locator set for A, which consists of the locators L1(A), 250 L2(A), ... Ln(A). 252 ULID(A) is an upper-layer ID for A. In this proposal, ULID(A) is 253 always one member of A's locator set. 255 3. Overview 257 This document specifies certain aspects of the approach, yet leaves 258 other aspects open. 260 The main points are about using locators as the ULIDs, the exact 261 placement of the multihoming shim in the protocol stack, and an 262 outline of a protocol for a protocol for establishing and and 263 managing the necessary state in the multihoming shim. 265 The draft also discusses issues about receive side demultiplexing, 266 which affects the packet format for data packets. 268 The approach assumes that there are mechanisms (specified in other 269 drafts) which: 271 - can prevent redirection attacks [HBA] 273 - can prevent 3rd party DoS attacks [HBA, M6FUNC] 275 - can detect whether or not a peer supports the shim6 protocol 276 [M6FUNC, M6DET] 278 - can explore all the locator pairs to find a working pair when the 279 initial pair does not work [M6DET] 281 4. Locators as Upper-layer Identifiers 283 Central to this approach is to not introduce a new identifier name 284 space but instead use one of the locators as the upper-layer ID, 285 while allowing the locators used in the address fields to change over 286 time in response to failures of using the original locator. 288 This implies that the ULID selection is performed as today's default 289 address selection as specified in [RFC 3484]. Underneath, and 290 transparently, the multihoming shim selects working locator pairs 291 with the initial locator pair being the ULID pair. When 292 communication fails the shim can test and select alternate locators. 293 A subsequent section discusses the issues when the selected ULID is 294 not initially working hence there is a need to switch locators up 295 front. 297 Using one of the locators as the ULID has certain benefits for 298 applications which have long-lived session state, or performs 299 callbacks or referrals, because both the FQDN and the 128-bit ULID 300 work as handles for the applications. However, using a single 128- 301 bit ULID doesn't provide seamless communication when that locator is 302 unreachable. See [M6REFER] for further discussion of the application 303 implications. 305 There has been some discussion of using non-routable locators, such 306 as unique-local addresses [ULA], as ULIDs in a multihoming solution. 307 While this document doesn't specify all aspects of this, it is 308 believed that the approach can be extended to handle such a case. 309 For example, the protocol already needs to handle ULIDs that are not 310 initially reachable. Thus the same mechanism can handle ULIDs that 311 are permanently unreachable from outside their site. The issue 312 becomes how to make the protocol perform well when the ULID is not 313 reachable, for instance, avoiding any timeout and retries in this 314 case. In addition one would need to understand how the ULAs would be 315 entered in the DNS to avoid a performance impact on existing, non- 316 shim6 aware, IPv6 hosts potentially trying to communicate to the 317 (unreachable) ULA. 318 4.1. IP Multicast 320 IP Multicast requires that the IP source address field contain a 321 topologically correct locator for interface that is used to send the 322 packet, since IP multicast routing uses both the source address and 323 the destination group to determine where to forward the packet. 324 (This isn't much different than the situation with widely implemented 325 ingress filtering [RFC2827] for unicast.) 327 While in theory it would be possible to apply the shim re-mapping of 328 the IP address fields between ULIDs and locators, the fact that all 329 the multicast receivers would need to know the mapping to perform, 330 makes such an approach difficult in practice. Thus it makes sense to 331 have multicast ULPs operate directly on locators and not use the 332 shim. This is quite a natural fit for protocols which use RTP 333 [RFC3550], since RTP already has an explicit identifier in the form 334 of the SSRC field in the RTP headers. Thus the actual IP address 335 fields are not important to the application. 336 4.2. Renumbering Implications 338 As stated above, this approach does not try to make communication 339 survive renumbering. However, the fact that a ULID might be used 340 with a different locator over time open up the possibility that 341 communication between two ULIDs might continue to work after one or 342 both of those ULIDs are no longer reachable as locators, for example 343 due to a renumbering event. This opens up the possibility that the 344 ULID (or at least the prefix on which it is based) is reassigned to 345 another site while it is still being used (with another locator) for 346 existing communication. 348 Worst case we could end up with two separate hosts using the same 349 ULID while both of them are communicating with the same host. 351 This potential source for confusion can be avoided if we require that 352 any communication using a ULID must be terminated when the ULID 353 becomes invalid (due to the underlying prefix becoming invalid). 355 However, this might be an overkill. Even when an IPv6 prefix is 356 retired and reassigned to some other site, there is still a very 357 small probability that another host in that site picks the same 128 358 bit address (whether using DHCPv6, stateless address 359 autoconfiguration, or picking a random interface ID [RFC 3041]). 360 Should the identical address be used by another host, then there 361 still wouldn't be a problem until that host attempts to communicate 362 with the same host with which the initial user of the IPv6 address 363 was communicating. 365 5. Placement of the multihoming shim 366 ----------------------- 367 | Transport Protocols | 368 ----------------------- 370 ------ ------- -------------- ------------- IP endpoint 371 | AH | | ESP | | Frag/reass | | Dest opts | sub-layer 372 ------ ------- -------------- ------------- 374 --------------------- 375 | shim6 shim layer | 376 --------------------- 378 ------ IP routing 379 | IP | sub-layer 380 ------ 382 Figure 1: Protocol stack 384 The proposal uses an multihoming shim layer within the IP layer, 385 i.e., below the ULPs, as shown in figure 1, in order to provide ULP 386 independence. Conceptually the multihoming shim layer behaves as if 387 it is associated with an extension header, which would be ordered 388 immediately after any hop-by-hop options in the packet. However, the 389 amount of data that needs to be carried in an actual shim6 extension 390 header is close to zero, thus it might not be necessary to add bytes 391 to each packet. See section 9. 393 We refer to packets that at least conceptually have this extension 394 header, i.e., packets that should be processed by the multihoming 395 shim on the receiver, as "shim6 packets" (analogous to "ESP packets" 396 or "TCP packets"). 398 Layering AH and ESP above the multihoming shim means that IPsec can 399 be made to be unaware of locator changes the same way that transport 400 protocols can be unaware. Thus the IPsec security associations 401 remain stable even though the locators are changing. The MOBIKE WG 402 is looking at ways to have IPsec security associations survive even 403 though the IP addresses changes, which is a different approach. 405 Layering the fragmentation header above the multihoming shim makes 406 reassembly robust in the case that there is broken multi-path routing 407 which results in using different paths, hence potentially different 408 source locators, for different fragments. Thus, effectively the 409 multihoming shim layer is placed between the IP endpoint sublayer, 410 which handles fragmentation, reassembly, and IPsec, and the IP 411 routing sublayer, which on a host selects which default router to use 412 etc. 414 Applications and upper layer protocols use ULIDs which the shim6 415 layer will map to/from different locators. The shim6 layer maintains 416 state, called host-pair context, per ULID pairs (that is, applies to 417 all ULP connections between the ULID pair) in order to perform this 418 mapping. The mapping is performed consistently at the sender and the 419 receiver, thus from the perspective of the upper layer protocols, 420 packets appear to be sent using ULIDs from end to end, even though 421 the packets travel through the network containing locators in the IP 422 address fields, and even though those locators might be changed by 423 the transmitting shim6 layer. 425 The context state in this approach is maintained per remote ULID i.e. 426 approximately per peer host, and not at any finer granularity. In 427 particular, it is independent of the ULPs and any ULP connections. 428 When two hosts are communicating with each other using multiple 429 different ULID pairs, there is an option to "merge" the context state 430 for the two (or more) ULID pairs. Doing so would mean that the 431 protocol to test and select working locators after a failure can be 432 shared across the multiple ULID pairs between the two hosts. 433 However, if it will be uncommon that two hosts communicate using 434 multiple ULID pairs, the added complexity of merging the state might 435 not be worth while. Thus this is for further study. 437 ---------------------------- ---------------------------- 438 | Sender A | | Receiver B | 439 | | | | 440 | ULP | | ULP | 441 | | src ULID(A)=L1(A) | | ^ | 442 | | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) | 443 | v | | | dst ULID(B)=L1(B) | 444 | multihoming shim | | multihoming shim | 445 | | src L2(A) | | ^ | 446 | | dst L3(B) | | | src L2(A) | 447 | v | | | dst L3(B) | 448 | IP | | IP | 449 ---------------------------- ---------------------------- 450 | ^ 451 ------- cloud with some routers ------- 453 Figure 2: Mapping with changed locators. 455 The result of this consistent mapping is that there is no impact on 456 the ULPs. In particular, there is no impact on pseudo-header 457 checksums and connection identification. 459 Conceptually one could view this approach as if both ULIDs and 460 locators are being present in every packet, but with a header 461 compression mechanism applied that removes the need for the ULIDs 462 once the state has been established. In order for the receiver to 463 recreate a packet with the correct ULIDs there might be a need to 464 include some "compression tag" in the data packets. This would serve 465 to indicate the correct context to use for decompression when the 466 locator pair in the packet is insufficient to uniquely identify the 467 context. 469 5.1. Shim Implications on Flow Label Usage 471 The use of a shim has implications on a class of protocols which have 472 host as well as router functions. This section discusses the 473 implications for the flow label field, which might be used for QoS 474 handling where the hosts set the flow label and initiate some flow 475 signaling protocols, and the routers participate in the flow 476 signaling protocol and as a result perform different action on 477 packets based on the flow (which is identified by the IP address 478 fields and the flow label field). 480 The shim will leave the flow label unmodified. This means that the 481 {Flow Label, Source ULID, Dest ULID} that the upper-layer protocol 482 sends will appear on the wire as the set of {Flow Label, Source 483 Locator, Destination Locator} for the different locators. 485 This does have implications for protocols which do explicit signaling 486 to create flow state; such protocols would somehow need to be made 487 shim6 aware so that they can perform the signaling for all the tuples 488 of {Flow Label, Source Locator, Destination Locator} that are used on 489 the wire. Note that this need to modify such signaling protocols 490 would apply even if the flows were identified without the use of the 491 flow label field, due to the different locators which might be used. 493 5.2. Shim Implications on ICMP errors 495 Another protocol which requires consistency between the upper layer 496 protocols on the hosts and the routers are the ICMP errors. The 497 routers (and in some cases the peer host) will generate ICMP errors 498 based on the locators contained in the IP address fields, but when 499 the host implementation delivers a notification to the ULP that an 500 ICMP error was received, the ULP instance needs to be discovered 501 based on the ULIDs. This means that for ICMP error reception the 502 host needs to be able to take the initial part of a shim6 packet (the 503 part returned in an ICMP error) and do the inverse translation of the 504 IP address fields that it did when sending the packet, and then 505 deliver the notification to the ULP. 507 Being able to demultiplex based on the information returned in an 508 ICMP error presumably has some implications on the packet format and 509 mechanism for receive-side demultiplexing. 511 5.3. Other Shim Protocol Implications 513 As stated above, there might be other protocols in addition to flow 514 management and ICMP errors that assume that the ULPs at the hosts and 515 the IP address fields seen by the routers are the same. 517 Any such protocol is potentially impacted by the introduction of the 518 multihoming shim. 520 5.4. MTU Implications 522 Depending on how demultiplexing is handled at the receiver (see 523 subsequent sections) there may or may not be a need for the shim to 524 add an extension header to the packets. In some cases such an 525 extension header would only need to be added to some and not all data 526 packets. 528 This has implications on the MTU that is available to the upper layer 529 protocols hence will require some extra handling in the host 530 implementation. At some level this is similar to the MTU 531 implementations of IPsec, in that the IP layer would add bytes to 532 some ULP packets and not others, but in the case of IPsec one would 533 expect all or no packets in a particular ULP connection to be 534 affected, whereas in shim6 some packets, such as those sent after a 535 locator failure, would be subject to a reduction in the available 536 MTU. 538 The MTU can also change because after a rehoming event a different 539 path (with a different MTU) is being used to exchange packets between 540 the peers. So, after a rehoming event, the need to include an 541 additional extension header, and the usage of a different path affect 542 the MTU. However, it should be noted that the shim6 is aware of the 543 path change and that the MTU discovery techniques already have a 544 mechanism to cope with changes in the path MTU when the path changes. 546 While the effects of these are local to the host implementation they 547 are likely to be a bit complicated. There needs to be a mechanism so 548 that the ULP can be notified when the available MTU changes due to an 549 extension header either being added, or no longer being added. Also, 550 ICMPv6 packet too big errors need to result in a notification to the 551 ULP which takes into account whether or not an extension header is 552 being added. Finally, certain ULPs such as UDP might need to rely on 553 IP fragmentation down to the available MTU, while other ULPs such as 554 TCP will adapt their segment size to the available MTU. 556 6. Deferred Context Establishment 558 The protocol will use some context establishment exchange in order to 559 setup shim6 state at the two endpoints. Similar to MAST [MAST] this 560 initial exchange can be performed asynchronously with data packets 561 flowing between the two hosts; until context state has been 562 established at both ends the packets would flow just as for 563 unmodified IPv6 hosts i.e., without the ability for the hosts to 564 switch locators. This approach allows the hosts to have some local 565 policy on when to attempt to establish shim6 state with a peer; 566 perhaps based on the transport protocols and port numbers, or perhaps 567 based on the number of packets that have flowed to/from the peer. 569 Once the initial exchange has completed there is host-pair context 570 state at both hosts, and both ends know a set of locators for the 571 peer that are acceptable as the source in received packets. This 572 will trigger some verification of the set of locators, which is the 573 subject of the security scheme. 575 7. Assumptions about the DNS 577 This approach assumes that hosts in multihomed sites have multiple 578 AAAA records under a single name, in order to allow initial 579 communication to try all the locators. For shim6 capable hosts, the 580 content of those records are the locators (which also serve as 581 ULIDs). 583 However, the approach does not assume that all the AAAA records for a 584 given name refer to the same host. For instance, the AAAA records 585 could point at different hosts providing the same service. This is 586 handled by the context establishment mechanism allowing each host to 587 pass its locators to the peer. This set contains a non-null subset 588 of the locators presented in the AAAA record set and it may contain 589 additional locators, not contained in the AAAA record set 591 The approach makes no assumption about the reverse tree since the 592 approach does not use it. However, applications might rely on the 593 reverse tree whether shim6 is used or not. 595 When the reverse DNS tree is populated so that any locator for the 596 host can be used to find a FQDN and that FQDN can be used to find all 597 the locators of the host, then this property can be used by the 598 applications when doing referals by the application only passing one 599 locator to the peer and having the peer application do the DNS 600 lookups to find the other locators. However, such a mechanism does 601 not work when the reverse DNS is not setup to satisfy this property. 602 Suggestions for how to handle the general case of application 603 referals is captured in [APP-REFER] 605 Note that in some cases, even when the reverse DNS is populated, it 606 can be hard to satisfy the above property. For instance, a home site 607 using two "consumer" ISPs each providing DNS service including 608 reverse DNS. In this case there might be no way for the site to 609 control what goes in the DNS for the reverse tree. 610 7.1. DNS and Unique-local Addresses 612 Earlier we've mentioned that the protocol might provide the basic 613 mechanism to use Unique-local addresses [ULA] as ULIDs. 615 In the cases where hosts have been assigned centrally assigned ULAs 616 [ULA-CENTRAL], one can potentially take advantage of this to provide 617 better support for applications. With centrally assigned ULAs it is 618 possible to register them in the reverse DNS tree. As a result, one 619 could use the DNS not only for applications which care about reverse 620 and forward tree being consistent, but also to find the full set of 621 locators from the ULID, the same way as outlined in the previous 622 section. But again, this doesn't handle the general case of 623 application referals. 625 For ULAs that are not centrally allocated it is not likely to be 626 possible to register them in the global DNS, thus this possibility 627 does not exist. 629 8. Protocol Walkthrough 630 8.1. Initial Context Establishment 632 Here is the sequence of events when A starts talking to B: 634 1. A looks up FQDN(B) in the DNS which returns a locator set which 635 includes some locators for B. (The set could include locators 636 for other hosts since e.g., www.example.com might include AAAA 637 records for multiple hosts.) The default address selection 638 [RFC3484] would make that set into an ordered list. The 639 application would typically try to connect using the first 640 locator in the list i.e., ULID(B) = L1(B). The application is 641 prepared to try the other locators should the first one fail. 643 2. The ULP creates "connection" state between ULID(A)=L1(A) and 644 ULID(B) and sends the first packet down to the IP/shim6 shim 645 layer on A. L1(A) was picked using regular source address 646 selection mechanisms [RFC3484]. Note that should communication 647 fail using the initial locator/ULID pair, there has to be a 648 mechanism to retry with both different destination locators and 649 different source locators. 651 3. The packet passes through the shim6 layer, which has no state 652 for ULID(B). A local policy will be used to determine when, if 653 at all, to attempt to setup shim6 state with the peer. Until 654 this state triggers packets pass back and forth between A and B 655 as they do in unmodified IPv6 today. 657 When the policy is triggered, which could be on either A or B, 658 an initial context establishment takes place. This exchange 659 will fail if the peer does not support the shim6 protocol. If 660 it succeeds it results in both ends receiving the locator sets 661 from their respective peer, and the security mechanism provides 662 some way to verify these sets. 664 At this point in time it is possible for the hosts to change to 665 a different locator in the set. But until they have exchanged 666 the locator sets, and probably until they rehome the context to 667 use different locators, they continue sending and receiving IPv6 668 packets as before. 670 As long as both hosts have been informed of the state at the 671 peer i.e., know the locators of the peer and know that the peer 672 has received its locators, each host can make an independent 673 decision when it sees a need to change either the source or 674 destination locator in the packets it is sending. Thus the 675 approach does not require coordinating the actual locator 676 changes between the peers. 678 8.2. Locator Change 680 When a host detects that communication is no longer working it can 681 try to switch to a different locator pair. A host might suspect that 682 communication isn't working due to 684 - lack of positive advice from the ULP (akin to the NUD advice in 685 [RFC2461] 687 - negative advice from the ULP 689 - failure of some explicit shim6 "heartbeat" messages 690 - local indications such as the local locator becoming invalid 691 [RFC2462] or the interface being disabled 693 Given that each host knows the locator set for its peer, the host can 694 just switch to using a different locator pair. It might make sense 695 for the host to test the locator pair before using it for ULP 696 traffic, both to verify that the locator pair is working and to 697 verify that it is indeed the peer that is present at the other end; 698 the latter to prevent 3rd party DoS attacks. Such testing needs to 699 complete before using the locator as a destination in order to 700 prevent 3rd party DoS attacks [M6THREATS]. 702 8.3. Concurrent Context Establishment 704 Should both A and B attempt to contact each other at about the same 705 time using the same ULIDs for each other, the context establishment 706 should create a single host-pair context. The NOID draft [NOID] 707 contains a proof-of-concept that a 4-way context establishment 708 exchange can ensure that a single context is created in this case. 710 However, if different ULIDs are used this would result in two 711 completely independent contexts between the two hosts following the 712 basic content establishment above; the context is per ULID pair. As 713 noted above, in this case it might be desirable to "merge" i.e., 714 share certain information, such as the reachability of different 715 locator pairs, across the different ULID pairs that are between the 716 same pair of hosts. 718 8.4. Handling Initial Locator Failures 720 Should not all locators be working when the communication is 721 initiated some extra complexity arises, because the ULP has already 722 been told which ULIDs to use. If the locators that were selected to 723 be ULIDs are not working and the shim6 layer does not know of 724 alternate locators, it has no other choice than to have the 725 application try a different ULID. Note that the mechanism need to be 726 able to try both different source ULIDs as well as different 727 destination ULIDs, to make sure all combinations are explored. 729 Thus the simplest approach is to always punt initial locator failures 730 up the stack to the application. However, this might imply 731 significant delays while transport protocol times out. Also, the 732 current default address selection mechanism [RFC3484] doesn't have a 733 mechanism to try different source addresses for a single destination 734 address; it can only cycle through different destination addresses 735 with each destination address being used with a single source 736 address. 738 It is possible to optimize initial locator failures when the shim6 739 layer already has alternate locators for the peer. This might be the 740 case when the two hosts have already communicated, or it might be 741 possible to have the DNS resolver library provide alternate locators 742 to the shim in the speculation that they might be useful. Such an 743 optimization must not assume that the AAAA records refer to the same 744 host, since it isn't uncommon that a FQDN have multiple AAAA records 745 for the same *service* but for different hosts. For instance, the 746 protocol would need to verify with the peer that the ULID in question 747 is in fact assigned to the peer in this case. Potentially the trust 748 level for the different locators retrieved from the DNS in this case, 749 as opposed to retrieving the ULIDs from the DNS and the locators from 750 the peer itself using the multihoming protocol, might be different. 751 Note however, that this is an optimization and is not required for 752 the protocol to work. 754 Should the shim6 layer know alternate locators for the peer, it needs 755 to perform the shim6 protocol before upper layer protocol packets are 756 exchanged. This means that the context establishment can not be 757 deferred, and that there is a rehoming event, with the necessary 758 security checks, before the first ULP packets can be successfully 759 exchanged. 761 9. Demultiplexing of data packets in shim6 communications 763 The mechanisms for preserving established communications through 764 outages that reside in the multihoming shim layer manage the multiple 765 locators available in the multihomed node so that a reachable locator 766 is used in the communication. Since reachability may vary during the 767 communication lifetime, different locators may have to be used in 768 order to keep packets flowing. However, the locators presented by 769 the shim layer to the upper layer protocols must remain constant 770 through the locator changes, so that received packets are recognized 771 by the upper layer protocols as belonging to the established 772 communication. In other words, in order to preserve established 773 communications through outages, the shim layer will use different 774 locators for exchanging packets while presenting the same ULIDs to 775 the upper layer protocols. This means that upon the reception of an 776 incoming packet with a pair of locators, the shim layer will need to 777 translate the received locators to the ULIDs that are being used by 778 the upper layer protocols in the particular communication. This 779 operation is called demultiplexing. 781 For example, if a host has address A1 and A2 and starts communicating 782 with a peer with addresses B1 and B2, then some communication 783 (connections) might use the pair as ULID and others might 784 use e.g., . Initially there are no failures so these address 785 pairs are used as locators i.e. in the IP address fields in the 786 packets on the wire. But when there is a failure the shim6 layer on 787 A might decide to send packets that used as ULIDs using as the locators. In this case B needs to be able to rewrite the 789 IP address field for some packets and not others, but the packets all 790 have the same locator pair. 792 Either we must prevent this from happening, or provide some 793 additional information to B so that it can tell which packets need to 794 have the IP address fields rewritten. 796 In this section, we will analyze different approaches to perform the 797 demultiplexing operation. The possible approaches can be classified 798 into two categories: First, the approaches that prevent the existence 799 of ambiguities on the demultiplexing operation i.e. each received 800 locator corresponds to one and only one ULID. Second, the approaches 801 that use a context tag to provide additional information to the 802 receiver that indicates the ULIDs that correspond to the locators 803 contained in the packets. 805 Note that the sender also needs to be able to demultiplex ICMP errors 806 as noted in Section 5.2, however the analysis below does not take 807 that added constraint into account. 809 9.1. Approaches preventing the existence of ambiguities 811 One could think this problem can be avoided if the host never used 812 the same locators for different ULIDs when communicating with the 813 same peer host. However, the host can't tell a priori whether two 814 peers share an IP stack. For instance, if A connects to www.foo.com 815 with AAAA=B1 and www.bar.com with AAAA=B2 it can't tell whether B1 or 816 B2 are assigned to the same IP stack or not until it communicates 817 with B1 and B2 and retrieves there complete locator sets. (And even 818 this might not suffice, since the peer might want to preserve the 819 illusion of being two different hosts by returning B3 as an 820 alternative locator for B1 and B4 as an alternate for B2.) 822 9.1.1. Pre-agreed identifiers 824 The simplest approach of this type is to designate one of the 825 available addresses as the ULID to be used for all the communications 826 while the remaining addresses will only be used as locators. This 827 means that the upper layer protocols will only be aware of a single 828 address, the one used as ULID, and all the remaining addresses that 829 are used as locators will remain invisible to them. Consequently, 830 only the ULID can be returned by the resolver to the applications. 831 The addresses used as locators cannot be returned to the applications 832 by the resolver. So, if no additional information about the role of 833 the addresses is placed in the DNS, only the ULID can be published in 834 the DNS. This configuration has reduced fault tolerance capabilities 835 during the initial contact, since the initiator will have only one 836 address available to reach the receiver. If the ULID placed in the 837 DNS is not reachable, the communication will fail. It would be 838 possible to overcome this limitation by defining a new DNS record for 839 storing information about addresses that can be only used as 840 locators. If such record is defined, the initiator can use an 841 alternative locator, even for initial contact, while still presenting 842 the ULID to the upper layer protocols. However, this approach 843 requires support from the initiator node, implying that only upgraded 844 nodes will obtain improved fault tolerance while legacy nodes that 845 don't support the new DNS record will still obtain reduced fault 846 tolerance capabilities. 848 9.1.2. N-square addresses 850 In order to overcome the limitations presented by the previous 851 scheme, it is possible to create additional addresses that have a 852 pre-determined role. In this approach, each multihomed node that has 853 n prefixes available, will create n^2 addresses, or in other words, 854 the node will have n sets of n addresses each. Each set will contain 855 one address per prefix. So, in each set, one address will be 856 designated as ULID while the remaining addresses will be designated 857 as locators. The ULIDs will have different prefixes in the different 858 sets. The result is that there will be n ULIDs, one per available 859 prefix, and each ULID will have an associated set of n-1 addresses 860 that can only be used as locators. The ULIDs will be published in 861 the DNS while the addresses usable only as locators must not be AAAA 862 records in the DNS to prevent them from ever being used as ULIDs. 863 The applications and default address selection [RFC3484] will only 864 have knowledge of the ULIDs, and only the shim layer will deal with 865 locators. The resulting configuration has full fault tolerance 866 capabilities since n addresses (one per prefix) will be published in 867 the DNS, allowing the usage of different addresses to make the 868 initial contact. 870 9.2. Providing additional information to the receiver 872 When two nodes establish a shim6 enabled communication, a context is 873 created at the shim layers of each node. The context stores 874 information about the ULIDs and also about the locator set available 875 for each node. In this approach, data packets carry a context tag 876 that allows the receiver determine which is the context that has to 877 be used to perform the demultiplexing operation. There are several 878 ways to carry the context tag within the data packets. In this 879 section we will explore the following options: the Flow Label, and an 880 Extension Header. 882 9.2.1. Flow-label 884 A possible approach is to carry the context tag in the Flow Label 885 field of the IPv6 header. This means that when a shim6 context is 886 established, a Flow Label value is associated with this context (and 887 perhaps a separate flow label for each direction). 889 The simplest approach that does this is to have the triple identify the context at 891 the receiver. 893 The sender and receiver needs to agree to allocate the flow labels so 894 that each context between a pair of IP stacks receives a different 895 flow label. While this might seem simple at first sight, the 896 possibilities that different ULIDs refer to the same IP stack, and 897 even that different FQDNs refer to the same IP stack, severely 898 constrains how flow labels can be allocated. For instance, when 899 communication is initiated from a host H to both foo.example (with 900 ULIDs A and B) and bar.example (with ULIDs C and D), then host H 901 might think it is communicating to two different IP stacks, when in 902 fact they might be the same IP stack. Later when the locator sets 903 are updated, for instances, after some failure, it might be told that 904 ULID A has locators A, B, C, and D. Hence the two communications 905 would need to have separate flow labels for the packets sent from H. 907 A protocol can handle this either by having H (in this example) 908 allocate the flow label for the packets it is sending, or having the 909 intended receiver allocate them. In the former case, H would need to 910 allocate different flow labels for the different ULID pairs, since it 911 doesn't know which peers are the same IP stack or not. In the latter 912 case, the intended receiver would pick a flow label which is unique 913 i.e., it can disambiguate the two contexts in this case. This 914 implies that the flow label will not be assigned until the 915 multihoming protocol has established the context state. 917 A modification to this suggested on the mailing list, which does not 918 need establish the context state before the flow label is assigned, 919 is to start the communication with unmodified flow label usage (could 920 be zero, or as suggested in [RFC 3697]). The packets sent after a 921 failure when a different locator pair is used would use a completely 922 different flow label, and this flow label can be allocated as part of 923 the shim context establishment. Since it is allocated during the 924 context establishment, the receiver of the "failed over" packets can 925 pick a flow label of its choosing, without any performance impact, 926 and respecting that for each locator pair, the flow label value used 927 for a given locator pair doesn't change due to the operation of the 928 multihoming shim. 930 A, perhaps minor, limitation imposed by overloading the flow label 931 all the potential source and destination locators have to be known 932 beforehand by the receiver in order to be recognized. This means 933 that before sending packets with a new locator, the sender has to 934 inform the receiver about the new locator, while for other approaches 935 it is probably possible to start sending packets using a new locator 936 and the same context tag in parallel with carrying information about 937 the new locator to the peer, if the context tag would be sufficient 938 by itself to identify the context i.e., the source locator isn't used 939 to identify the context. 941 Note that we do not yet understand how beneficial it would be to be 942 able to accept packets from unknown source locators (the rules for 943 packet reception can probably be more relaxed than for where packets 944 are sent, for instance if the context tag matches). Requiring a 945 match on would make 946 this impossible. Instead the locator change signaling would need to 947 be acknowledged before the peer can start sending using a new source 948 locator. 950 An attempt to remove the above limitation would be to try to have the 951 receiver only identify the context based on the flow label field, 952 i.e., without taking the locators into account in the lookup. This 953 requires constraining flow label allocation for the hosts that 954 implement shim6 so that for shim6 packets the receiver wouldn't have 955 to compare the locators but only use the flow label. Due to the 956 deferred shim6 capability discovery this would have to apply to all 957 flow label assignments on a host which implements shim6. 959 It also requires carrying some additional information in the packet 960 to identify whether the Flow Label field is actually being used as a 961 context tag or not. In other words, additional information is needed 962 to identify shim6 packets from regular IPv6 packets. This is 963 because, the same Flow Label value that is being used as context tag 964 in shim6 enabled communication can be used for other purposes by a 965 non-shim6 enabled host, resulting in two communications using the 966 same Flow Label value. The result of this situation would be that 967 packets of the non-shim6 enabled communication would be demultiplexed 968 using the context associated to the Flow Label value carried in the 969 packets. A possible approach to solve this issue it to use an 970 additional bit to identify data packets that belong to shim6 capable 971 communications and that have to be demultiplexed using the Flow Label 972 value. However, there are no obvious choices for that bit, since all 973 bits of the IPv6 header are currently in use. A possibility would be 974 to use new Next Header values to indicate that the packet belongs to 975 a shim6 enabled communication and that the Flow Label carries context 976 information as proposed in [NOID]. 978 9.2.2. Extension Header 980 Another approach is to define a new Extension Header to carry the 981 context tag. This context tag is agreed between the involved parties 982 during the shim6 protocol initial negotiation. Following data 983 packets will be demultiplexed using the tag carried in the Extension 984 Header. This seems a clean approach since it does not overload 985 existing fields. However, it introduces additional overhead in the 986 packet due to the additional header. The additional overhead 987 introduced is 8 octets. However, it should be noted that the context 988 tag is only required when a locator other than the one used as ULID 989 is contained in the packet. Packets where both the source and 990 destination address fields contain the ULIDs do not require a context 991 tag, since no rewriting is necessary at the receiver. This approach 992 would reduce the overhead. On the other hand, this approach would 993 cause changes in the available MTU for some packets, since packets 994 that include the Extension Header will have an MTU 8 octets shorter. 996 9.3. Host-Pair Context 998 The host-pair context is established on each end of the communication 999 when one of the endpoints performs the shim6 signaling (the 4-way 1000 handshake referred to in [M6FUNC]). 1002 This context is accessed differently in the transmit and receive 1003 paths. In the transmit path when the ULP passes down a packet the 1004 key to the context state is the tuple ; this 1005 key must identify at most one state record. In the receive path the 1006 context must be found based on what is in the packet, be it just the 1007 locators, or the locators plus some additional "context tag" as 1008 discussed above, or just a "context tag". 1010 10. IPSEC INTERACTIONS 1012 As specified, all of ESP, AH, and key management is layered above the 1013 shim6 layer. Thus they benefit from the stable ULIDs provided above 1014 the shim6 layer. This means the IPsec security associations are 1015 unaffected by switching locators. 1017 The alternative would be to layer shim6 above IPsec, but that doesn't 1018 seem to provide any benefits and it would add the need to create 1019 different IPsec SAs when the locators change due to rehoming. 1021 A result of layering shim6 above IPsec is that the shim6 protocol can 1022 potentially be used to redirect IPsec protected traffic as a 1023 selective DoS mechanism. If we somehow could require IPsec for the 1024 shim6 protocol packets when the ULP packets between the same hosts 1025 use IPsec, then we could prevent such attacks. 1027 However, due to the richness in IPsec policy, this would be a bit 1028 tricky. If only some protocols or port numbers/selectors are to be 1029 protected by IPsec per a host's IPsec policy, then how would one 1030 determine whether shim6 traffic needs to be protected? Should one 1031 take the conservative approach that if any packets between the 1032 hosts/ULIDs need to be protected, then the shim6 traffic should also 1033 be protected? 1035 For this to be useful both communicating hosts would need to make the 1036 same policy decisions, so if we are to take this path there would 1037 need to some standardization in this area. 1039 11. OPEN ISSUES 1041 Receive side demultiplexing issue as described above. 1043 How is the shim6 state managed, in particular, what mechanism is used 1044 for removing the state? There seems to be two choices: 1046 - a harder state approach which relies on some "CLOSE" message 1047 exchange (in combination with timers). An example of this is in 1048 [HIP-BASE]. 1050 - a soft-state mechanism where a node can discard the shim6 state at 1051 any time, combined with an error message "I have no state for you" 1052 that triggers the peer to reestablish the context. 1054 Related to the state management and the demultiplexing issues is how 1055 the protocol detects a loss of context state, which can occur due to 1056 a complete state loss (a host crashing and rebooting) or due to the 1057 shim garbage collecting the shim state even though the peer might 1058 continue to rely on it. 1060 The actual packet formats for the shim6 protocol. 1062 Is it possible to facilitate transition to shim6 using some "shim6 1063 proxy" at site boundaries until all important hosts in a site have 1064 been upgraded to support shim6? Would would be the properties of 1065 such a proxy? Would it place any additional requirements on the 1066 protocol itself? 1068 12. ACKNOWLEDGMENTS 1070 This document was originally produced of a MULTI6 design team 1071 consisting of (in alphabetical order): Jari Arkko, Iljitsch van 1072 Beijnum, Marcelo Bagnulo Braun, Geoff Huston, Erik Nordmark, Margaret 1073 Wasserman, and Jukka Ylitalo. 1075 The idea to use a set of locators and not inventing a new identifier 1076 name space, as well as using the DNS for verification of the 1077 locators, was first brought up by Tony Li. 1079 Greg Daley suggested that the flow label approach can be more easily 1080 used if different flow label values are used for the different 1081 locator pairs. 1083 13. REFERENCES 1085 13.1. Normative References 1087 [M6THREATS] Nordmark, E., and T. Li, "Threats relating to IPv6 1088 multihoming solutions", draft-ietf-multi6-multihoming- 1089 threats-00.txt, July 2004. 1091 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1092 Addressing Architecture", RFC 3513, April 2003. 1094 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 1095 6 (IPv6) Specification", RFC 2461. 1097 [M6FUNC] Functional decomposition of the M6 protocol, draft-ietf- 1098 shim6-functional-dec-00.txt 1100 [HBA] Hash Based Addresses (HBA), draft-ietf-shim6-hba-00.txt 1102 [M6DET] Jari Arkko, Failure Detection and Locator Selection in 1103 Multi6, draft-ietf-shim6-failure-detection-00.txt 1105 13.2. Informative References 1107 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 1108 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 1109 March 2003. 1111 [ULA] R. Hinden, and B. Haberman, Unique Local IPv6 Unicast 1112 Addresses, draft-ietf-ipv6-unique-local-addr-08.txt 1114 [ULA-CENTRAL] R. Hinden, and B. Haberman, Centrally Assigned Unique 1115 Local IPv6 Unicast Addresses, draft-ietf-ipv6-ula-central- 1116 00.txt 1118 [APP-REFER] Shim6 Application Referral Issues, July 2005, 1121 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", Oct 27, 1122 2003, 1124 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): 1125 AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, 1126 October, 2003. 1128 [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless 1129 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1131 [RFC2827] Ferguson P., and D. Senie, "Network Ingress Filtering: 1132 Defeating Denial of Service Attacks which employ IP Source 1133 Address Spoofing", RFC 2827, May 2000. 1135 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1136 "RTP: A Transport Protocol for Real-Time Applications", 1137 July 2003, RFC 3550. 1139 [INGRESS] C. Huitema, R. Draves, and M. Bagnulo, "Ingress filtering 1140 compatibility for IPv6 multihomed sites", Oct 2004, 1141 1143 [RFC3484] R. Draves, "Default Address Selection for Internet 1144 Protocol version 6 (IPv6)", February 2003, RFC 3484. 1146 [RFC3697] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 1147 Flow Label Specification", March 2004, RFC 3697. 1149 [HIP-BASE] Robert Moskowitz, "Host Identity Protocol", draft-ietf- 1150 hip-base-03.txt 1152 14. CHANGE LOG 1154 Changes since draft-ietf-multi6-l3shim-00.txt: 1156 o Renamed to draft-ietf-shim6-l3shim 1158 o Renamed protocol and layer from "multi6" to "shim6". 1160 o Using "address" vs. "locator" and "ULID" more consistently and 1161 carefully. 1163 o Made it more clear that the ULID is just an IPv6 address. (Requested 1164 on mailing list.) 1166 o In "Renumbering Implications" added text to point out the small 1167 probability of there being a problem. (Requested on mailing list.) 1169 o Extended the assumption about ingress filtering and exit selection. 1170 (Requested on mailing list.) 1172 o Added clarification to MTU implications. (Requested on mailing 1173 list.) 1175 o Clarified what Centrally assigned ULAs can do which regular IPv6 1176 addresses can't do with respect to the DNS. (Requested on mailing 1177 list.) 1179 o Added suggestion from mailing list that one can use different flow 1180 label for the communication when ULIDs=locators, and when they are 1181 different. 1183 o Listed a few more open issues. 1185 Changes since draft-nordmark-multi6dt-shim-00.txt: 1187 o Added assumption that something else handles the interaction between 1188 ingress filtering and source address selection. 1190 o Clarified things with respect to using ULAs in general, and added 1191 separate text about centrally assigned ULAs. 1193 o Added more text about MTU dropping implications and ICMP too big re- 1194 mapping 1196 o Added text specifying how the shim handles the flow label field, and 1197 the impact on flow setup protocols. 1199 o Added text about the need for the sender to handle ICMP errors 1201 o Added text that there might be other protocols than flow setup 1202 protocols and ICMP errors that might be impacted by the shim. 1204 o Added text about IP multicast in a new section. 1206 o Added clarification in section 8.4 about AAAA records being for a 1207 service and not a host needing some care. 1209 o Added a clarification in section 8.4 that learning the different 1210 locators during initial communication from the DNS potentially has 1211 different trust issues than learning them from the peer. 1213 o Clarified the two models of flow label usage for demultiplexing 1215 o In section 5 clarified that state maintenance is not per ULP 1216 connection. 1218 o In section 5 clarified merging option. 1220 o Clarified in section 9.1 why it isn't sufficient to avoid using the 1221 same locators for different ULIDs for the same peer host. 1223 o Clarified in section 9.1.1/9.1.2 that there is multi6 state at the 1224 receiver to tell how/whether to rewrite the source address field. 1226 o Clarified the aspect of section 9.2.1 which talks about not being 1227 able to use a new locator until the peer has been told of the new 1228 locator. 1230 o Added text about the implications of renumbering and reassignment. 1232 o Clarified section on flow labels to first talk about the simple case 1233 of using and its 1234 complexities, and then about the potential to just use the flow label 1235 by itself to identify the context. 1237 AUTHORS' ADDRESSES 1239 Erik Nordmark 1240 Sun Microsystems, Inc. 1241 17 Network Circle 1242 Mountain View, CA 1243 USA 1245 phone: +1 650 786 2921 1246 fax: +1 650 786 5896 1247 email: erik.nordmark@sun.com 1249 Marcelo Bagnulo 1250 Universidad Carlos III de Madrid 1251 Av. Universidad 30 1252 Leganes, Madrid 28911 1253 SPAIN 1255 Phone: 34 91 6249500 1256 EMail: marcelo@it.uc3m.es 1257 URI: http://www.it.uc3m.es 1259 Intellectual Property Statement 1261 The IETF takes no position regarding the validity or scope of any 1262 Intellectual Property Rights or other rights that might be claimed to 1263 pertain to the implementation or use of the technology described in 1264 this document or the extent to which any license under such rights 1265 might or might not be available; nor does it represent that it has 1266 made any independent effort to identify any such rights. Information 1267 on the procedures with respect to rights in RFC documents can be 1268 found in BCP 78 and BCP 79. 1270 Copies of IPR disclosures made to the IETF Secretariat and any 1271 assurances of licenses to be made available, or the result of an 1272 attempt made to obtain a general license or permission for the use of 1273 such proprietary rights by implementors or users of this 1274 specification can be obtained from the IETF on-line IPR repository at 1275 http://www.ietf.org/ipr. 1277 The IETF invites any interested party to bring to its attention any 1278 copyrights, patents or patent applications, or other proprietary 1279 rights that may cover technology that may be required to implement 1280 this standard. Please address the information to the IETF at 1281 ietf-ipr@ietf.org. 1283 Disclaimer of Validity 1284 This document and the information contained herein are provided on an 1285 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1286 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1287 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1288 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1289 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1290 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1292 Copyright Statement 1294 Copyright (C) The Internet Society (2005). This document is subject 1295 to the rights, licenses and restrictions contained in BCP 78, and 1296 except as set forth therein, the authors retain all their rights. 1298 Acknowledgment 1300 Funding for the RFC Editor function is currently provided by the 1301 Internet Society.