idnits 2.17.1 draft-nordmark-multi6-noid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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.) ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 482: '... Receivers MUST silently ignore? Reject? [TBD] any message code...' 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: 'Rewritten' is mentioned on line 313, but not defined == Missing Reference: 'IANA' is mentioned on line 458, but not defined == Missing Reference: 'TBD' is mentioned on line 482, but not defined == Unused Reference: 'ADDR-ARCH' is defined on line 1138, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'AURA02' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'NIKANDER03' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 1181, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1184, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 ** Downref: Normative reference to an Informational draft: draft-nordmark-multi6-threats (ref. 'M6SEC') ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) == Outdated reference: A later version (-10) exists of draft-irtf-nsrg-report-09 == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 -- No information found for draft-odell-8 - is the name correct? -- No information found for draft-crocker-mast-protocol - is the name correct? == Outdated reference: A later version (-01) exists of draft-nordmark-multi6-sim-00 -- Duplicate reference: RFC2461, mentioned in 'DISCOVERY', was also mentioned in 'IPv6'. -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Oct 27, 2003 Sun Microsystems 5 Multihoming without IP Identifiers 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft expires April 27, 2004. 32 Abstract 34 This document outlines a potential solution to IPv6 multihoming in 35 order to stimulate discussion. 37 This proposed solution relies on verification using the existing DNS 38 to prevent redirection attacks, while allowing locator rewriting by 39 (border) routers, with no per-packet overhead. The solution does not 40 introduce a "stack name" type of identifier, instead it ensures that 41 all upper layer protocols can operate unmodified in a multihomed 42 setting while still seeing a stable IPv6 address. 44 DISCLAIMER: This work has been discussed extensively in a design 45 team. The design team is still exploring multiple approaches and 46 this is an attempt to capture one such approach on paper. Because of 47 this and due to lack of time to review the document one can not say 48 that this is a product of the DT; errors and confusions should be 49 attributed to the scribe and not to the DT. 51 Contents 53 1. INTRODUCTION............................................. 4 54 1.1. Non-Goals........................................... 4 55 1.2. Assumptions......................................... 5 57 2. TERMINOLOGY.............................................. 5 58 2.1. Notational Conventions.............................. 6 60 3. PROTOCOL OVERVIEW........................................ 6 61 3.1. Host-Pair Context................................... 10 62 3.2. Message Formats..................................... 11 64 4. PROTOCOL WALKTHROUGH..................................... 13 65 4.1. Initial Context Establishment....................... 13 66 4.2. Locator Change...................................... 15 67 4.3. Handling Locator Failures........................... 16 68 4.4. Locator Set Changes................................. 17 69 4.5. Preventing Premeditated Redirection Attacks......... 17 71 5. HANDLING STATE LOSS...................................... 18 73 6. ENCODING BITS IN THE IPv6 HEADER?........................ 19 75 7. COMPATIBILITY WITH STANDARD IPv6......................... 21 77 8. APPLICATION USAGE OF IDENTIFIERS......................... 21 79 9. CHECKSUM ISSUES.......................................... 22 81 10. IMPLICATIONS FOR PACKET FILTERING....................... 23 83 11. IPSEC INTERACTIONS...................................... 23 85 12. SECURITY CONSIDERATIONS................................. 24 87 13. DESIGN ALTERNATIVES..................................... 24 89 14. OPEN ISSUES............................................. 24 90 14.1. Handling Hosts without a FQDN...................... 25 91 14.2. Locator Set Inconsistencies........................ 25 92 14.3. Renumbering Considerations......................... 26 93 14.4. Initiator Confusion vs. "Virtual Hosting".......... 26 95 15. ACKNOWLEDGEMENTS........................................ 27 97 16. REFERENCES.............................................. 27 98 16.1. Normative References............................... 27 99 16.2. Informative References............................. 28 101 1. INTRODUCTION 103 The goal of the IPv6 multihoming work is to allow a site to take 104 advantage of multiple attachments to the global Internet without 105 having a specific entry for the site visible in the global routing 106 table. Specifically, a solution should allow users to use multiple 107 attachments in parallel, or to switch between these attachment points 108 dynamically in the case of failures, without an impact on the upper 109 layer protocols. 111 This proposed solution uses existing DNS mechanisms to perform enough 112 validation to prevent redirection attacks. 114 The goals for this proposed solution is to: 116 o Have no impact on upper layer protocols in general and on 117 transport protocols in particular. 119 o Address the security threats in [M6SEC]. 121 o Allow routers rewriting the (source) locators as a means of 122 quickly detecting which locator is likely to work for return 123 traffic. 125 o No per-packet overhead. 127 o No extra roundtrip for setup. 129 o Take advantage of multiple locators/addresses for load spreading. 131 1.1. Non-Goals 133 The assumption is that the problem we are trying to solve is site 134 multihoming, with the ability to have the set of site locator 135 prefixes change over time due to site renumbering. Further, we 136 assume that such changes to the set of locator prefixes can be 137 relatively slow and managed; slow enough to allow updates to the DNS 138 to propagate. This proposal does not attempt to solve, perhaps 139 related, problems such as host multihoming or host mobility. 141 This proposal also does not try to provide an IP identifier. Even 142 though such a concept would be useful to ULPs and applications, 143 especially if the management burden for such a name space was zero 144 and there was an efficient yet secure mechanism to map from 145 identifiers to locators, such a name space isn't necessary (and 146 furthermore doesn't seem to help) when using the DNS to verify the 147 locator relationships. 149 1.2. Assumptions 151 The main technical assumptions this proposal makes is that the DNS 152 infrastructure can be used for verification of the relationship 153 between locators on both the initiator of communication and the 154 responding peer. In particular, it assumes that getting DNS reverse 155 maps (ip6.arpa) populated for the hosts that wish to take advantage 156 of multihoming will not be a significant problem. 158 2. TERMINOLOGY 160 upper layer protocol (ULP) 161 - a protocol layer immediately above IP. Examples are 162 transport protocols such as TCP and UDP, control 163 protocols such as ICMP, routing protocols such as 164 OSPF, and internet or lower-layer protocols being 165 "tunneled" over (i.e., encapsulated in) IP such as 166 IPX, AppleTalk, or IP itself. 168 interface - a node's attachment to a link. 170 address - an IP layer name that contains both topological 171 significance and acts as a unique identifier for an 172 interface. 128 bits. 174 locator - an IP layer topological name for an interface or a 175 set of interfaces. 128 bits. The locators are 176 carried in the IP address fields as the packets 177 traverse the network. 179 identifier - an IP layer identifier for an IP layer endpoint 180 (stack name in [NSRG]). The transport endpoint is a 181 function of the transport protocol and would 182 typically include the IP identifier plus a port 183 number. NOTE: This proposal does not contain any IP 184 layer identifiers. 186 Application identifier (AID) 187 - an IP locator which has been selected for 188 communication with a peer to be used by the upper 189 layer protocol. 128 bits. This is used for 190 pseudo-header checksum computation and connection 191 identification in the ULP. Different sets of 192 communication to a host (e.g., different 193 connections) might use different AIDs in order to 194 enable load spreading. 196 address field 197 - the source and destination address fields in the 198 IPv6 header. As IPv6 is currently specified this 199 fields carry "addresses". If identifiers and 200 locators are separated these fields will contain 201 locators. 203 FQDN - Fully Qualified Domain Name 205 2.1. Notational Conventions 207 A, B, and C are hosts. X is a potentially malicious host. 209 FQDN(A) is the domain name for A. 211 Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... 212 Ln(A). 214 AID(A) is an application ID for A. In this proposal, AID(A) is 215 always one member of Ls(A). 217 3. PROTOCOL OVERVIEW 219 In order to prevent redirection attacks this protocol relies on the 220 DNS (for the hosts which support this protocol) being maintained with 221 consistent forward and reverse maps. This allows any host, given one 222 locator, to determine the corresponding FQDN and the set of locators 223 for the host. Once those lookups have been performed, and the 224 original locator is indeed part of the set, the host can happily 225 allow any of those locators without being subject to redirection 226 attacks. Keeping the FQDN around allows the solution to handle 227 graceful renumbering by being able to redo the DNS lookups (e.g., 228 based on the TTL on the resource records). 230 DNS is also used to provide an indication of multihoming capability 231 of a host. The details of this is TBD but a simple example would be 232 to introduce a new M6 RR type in the DNS which has no RDATA; thus the 233 mere existence of such a record at a FQDN would imply that the host 234 supports the M6 protocol. 236 ----------------------- 237 | Transport Protocols | 238 ----------------------- 240 ------ ------- -------------- ------------- 241 | AH | | ESP | | Frag/reass | | Dest opts | 242 ------ ------- -------------- ------------- 244 ----------------- 245 | M6 shim layer | 246 ----------------- 248 ------ 249 | IP | 250 ------ 252 Figure 1: Protocol stack 254 The proposal uses an M6 shim layer between IP and the ULPs as shown 255 in figure 1, in order to provide ULP independence. Conceptually the 256 M6 shim layer behaves as if it is an extension header, which would be 257 ordered immediately after any hop-by-hop options in the packet. 258 However, the amount of data that needs to be carried in an actual M6 259 extension header is close to zero. By using some encoding of the 260 nexthdr value it is possible to carry the common protocols/extension 261 headers without making the packets larger. The nexthdr encodings are 262 discussed later in this document. We refer to packets that use this 263 encoding to indicate to the receiver that M6 processing should be 264 applied as "M6 packets" (analogous to "ESP packets" or "TCP 265 packets"). 267 Layering AH and ESP above the M6 shim means that IPsec can be made to 268 be unaware of locator changes the same way that transport protocols 269 can be unaware. Thus the IPsec security associations remain stable 270 even though the locators are changing. Layering the fragmentation 271 header above the M6 shim makes reassembly robust in the case that 272 there is broken multi-path routing which results in using different 273 paths, hence potentially different source locators, for different 274 fragments. 276 The proposal uses router rewriting of (source) locators as one way to 277 determine which is the preferred (or only working) locator to use for 278 return traffic. But not all packets can have their locators 279 rewritten. In addition to existing IPv6 packets, the packets 280 exchanged before M6 host-pair context state is established at the 281 receiver can not have their locators rewritten. Thus a simple 282 mechanism is needed to indicate to the routers on the path whether or 283 not it is ok to rewrite the locators in the packet. Conceptually 284 this is a single bit in the IPv6 header (we call it the "rewrite ok" 285 bit) but there is no spare bit available. Later in the document we 286 show how we solve this by allocating a range of next header values to 287 denote this semantic bit. 289 Applications and upper layer protocols use AIDs which the M6 layer 290 will map to/from different locators. The M6 layer maintains state, 291 called host-pair context, in order to perform this mapping. The 292 mapping is performed consistently at the sender and the receiver, 293 thus from the perspective of the upper layer protocols packets appear 294 to be sent using AIDs from end to end, even though the packets travel 295 through the network containing locators in the IP address fields, and 296 even though those locators might be rewritten in flight. 298 ---------------------- ---------------------- 299 | Sender A | | Receiver B | 300 | | | | 301 | ULP | | ULP | 302 | | src AID(A) | | ^ | 303 | | dst AID(B) | | | src AID(A) | 304 | v | | | dst AID(B) | 305 | M6 | | M6 | 306 | | src L1(A) | | ^ | 307 | | dst L1(B) | | | src L2(A) | 308 | v | | | dst L1(B) | 309 | IP | | IP | 310 ---------------------- ---------------------- 311 | ^ 312 -- cloud with some routers ------- 313 src L2(A) [Rewritten] 314 dst L1(B) 315 Figure 2: Mapping with router rewriting of locators. 317 The result of this consistent mapping is that there is no impact on 318 the ULPs. In particular, there is no impact on pseudo-header 319 checksums and connection identification. 321 Conceptually one could view this approach as if both AIDs and 322 locators being present in every packet, but with a header compression 323 mechanism applied that removes the need for the AIDs once the state 324 has been established. As we will see below the flowid will be used 325 akin to a "compression tag" i.e., to indicate the correct context to 326 use for decompression. 328 The need for some "compression tag" is because the desire to allow 329 load spreading and handle site renumbering. Without those desires it 330 could have been possible to e.g. designate one fixed locator as the 331 AID for a host and storing that in the DNS. But instead different 332 connections between two hosts are allowed to use different AIDs and 333 on reception of a M6 packet the correct AIDs must be inserted into 334 the IP address fields before passing the packet to the ULP. The 335 flowid serves as a convenient "compression tag" without increasing 336 the packet size, and this usage doesn't conflict with other flowid 337 usage. 339 In addition to the zero overhead data messages, there are four 340 different M6 message types introduced (which could be defined as new 341 ICMPv6 messages). Three types are used to perform a 3-way handshake 342 to create state at both endpoints without creating state on the first 343 received packet (which would introduce a memory consumption DoS 344 attack), and finally a single message type to signal that state has 345 been lost. The four message types are called: 347 o Context request message; first message of the 3-way context 348 establishment. Sent by the responder when a data packet arrives 349 with no context state. An ULP packet can be piggybacked on this 350 message. 352 o Context response message; second message of the 3-way context 353 establishment. Sent in response to a context request. An ULP 354 packet can be piggybacked on this message. 356 o Context confirm message; third message of the 3-way context 357 establishment. Sent in response to a context response. An ULP 358 packet can be piggybacked on this message. 360 o Unknown context message; error which is sent when no state is 361 found. 363 Similar to MAST [MAST] the above exchange can be performed 364 asynchronously with data packets flowing between the two hosts; until 365 context state has been established at both ends the packets would 366 flow without allowing router rewriting of locators and without the 367 ability for the hosts to switch locators. 369 Once the 3-way state creation exchange has completed there is host- 370 pair context state at both hosts. At that point in time the 371 responder (which didn't use DNS before the setup) can asynchronously 372 start retrieving and verifying additional locators using the DNS. 373 Once a peer locator has been verified it will be a candidate 374 destination locator including the ability to dynamically switch to 375 using the last received source locator (that is already verified) as 376 the destination locator for return traffic. 378 3.1. Host-Pair Context 380 The host-pair context is established on the initiator of 381 communication based on information learned from the DNS (either by 382 starting with a FQDN or with an IP address -> FQDN lookup). The 383 responder will establish some initial state using the context 384 creation 3-way handshake and later discover and verify the peer's 385 locators using the DNS. 387 The context state contains the following information: 389 - the peer locator which the ULP uses as ID; AID(peer) 391 - the local locator which the ULP uses as ID; AID(local) 393 - the set of peer locators; Ls(peer) 395 - for each peer locator, a bit whether it has been verified with the 396 DNS (by doing reverse + forward lookup) 398 - the preferred peer locator - used as destination; Lp(peer) 400 - the set of local locators; Ls(local) 402 - the preferred local locator - used as source; Lp(local) 404 - the flowid used to transmit packets; F(local) 406 - the flowid to expect in receive packets; F(peer) 408 - the fully qualified domain name for the peer; FQDN(peer) 410 - State about peer locators that are in the process of being 411 verified in the DNS 413 This state is accessed differently in the transmit and receive paths. 414 In the transmit path when the ULP passes down a packet the key to the 415 context state is the tuple ; this key must 416 identify at most one state record. In the receive path it is the 417 F(peer) plus one of the locators in each of Ls(local) and Ls(peer) 418 that are used to identify at most one state record. Thus the sender 419 allocated flowid is part of the key for looking up the context state 420 at the receiver. 422 These uniqueness requirements imposed by those lookup keys uniquely 423 identifying one state record means that one can not create multiple 424 records (e.g. with different FQDN or locator sets) that have the same 425 AID pair, and the peer must pick a flowid so that host-pair contexts 426 which have at least one common members in Ls(local) and in the 427 Ls(peer) sets, but with different AID pair, gets a different 428 F(local). The context state at both ends must be consistent for this 429 to be completely robust. One way of ensuring this is to have each 430 host perform a periodic DNS lookup of its own FQDN in order to have a 431 current Ls(local) that is the same as the Ls(peer) that the peer 432 would find in the DNS. 434 Note that the flowids could be selected to be finer grain than above; 435 for instance having a different flowid for each connection. Doing so 436 requires some efficient data structure organization at the receiver 437 to map multiple F(peer) to the same context. 439 3.2. Message Formats 441 These message formats are largely the same as in [CB128] but the 442 context request, response, and confirm are sent in the opposite 443 direction. 445 The base M6 header is an ICMPv6 header as follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Code | Checksum | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 ICMPv6 Fields: 457 Type 458 TBD [IANA] 460 Code 461 8-bit field. The type of M6 message. The M6 462 header carries 4 different types of messages: 464 o Context request message; first message of the 465 3-way context establishment. An ULP packet can 466 be piggybacked on this message. 468 o Context response message; second message of the 469 3-way context establishment. An ULP packet can 470 be piggybacked on this message. 472 o Context confirm message; third message of the 473 3-way context establishment. An ULP packet can 474 be piggybacked on this message. 476 o Unknown context message; error which is sent 477 when no context state found. 479 Checksum The ICMPv6 checksum. 481 Future versions of this protocol may define message codes. 482 Receivers MUST silently ignore? Reject? [TBD] any message code 483 they do not recognize. 485 This drafts doesn't contain actual message layout for code 486 specific part. However, the content of these messages is 487 specified below. 489 The Context request message contains: 491 - Sender Nonce 493 - Sender AID 495 - Receiver AID 497 - Sender flowid (20 bits) 499 The Context response message contains: 501 - Receiver Nonce (copied from Sender Nonce in request) 503 - Context state consisting of: the two AIDs, the two flowids, and 504 the initial locators 506 - A timestamp or nonce (for sender's benefit) 508 - A hash over the context state and timestamp (to prevent 509 modification) 511 The Context confirm message contains: 513 - The context state, timestamp/nonce, and hash copied from the 514 context response. 516 The Unknown context message contains: 518 - The 20-bit flowid from the triggering packet. 520 4. PROTOCOL WALKTHROUGH 522 4.1. Initial Context Establishment 524 Here is the sequence of events when A starts talking to B: 526 1. A looks up FQDN(B) in the DNS which returns Ls(B) plus "B is 527 M6 capable". One locator is selected to be returned to the 528 application: AID(B) = L1(B). The others are installed in the 529 M6 layer on the host with AID(B) being the key to find that 530 state. 532 To make sure that the lookup from AID(B) returns a single 533 state record it appears that one needs to do a reverse lookup 534 AID(B)->FQDN and check that the result is FQDN(B). Whether 535 this check can be deferred until two entities try to use the 536 same AID(B) for a different Ls is for further study. Always 537 doing the reverse lookup would be more predictable in any 538 case. See section 14.4 for some more discussion. 540 2. The ULP creates "connection" state between AID(A)=L1(A) and 541 AID(B) and sends the first packet. L1(A) was picked using 542 regular source address selection mechanisms. 544 3. The M6 layer matches on AID(B) and finds the proto-context 545 state (setup in step #1) with Ls(B). The existence of that 546 state will make the M6 layer send a M6 packet. The M6 layer 547 selects a flowid F(local) consistent with the uniqueness 548 requirements in section 3.1 (which ensure that the receiver 549 will map to the correct AID pair). 551 4. The packet (TCP SYN or whatever) is sent to peer with 552 locators L1(A) to L1(B) i.e., the same as the AIDs. Since B 553 doesn't have any context state yet, A will not set the 554 "rewrite ok" bit in the header. 556 5. Host B receives packet and sees it is a "M6 packet". Passes 557 the packet to the M6 shim layer. The M6 layer can't create 558 state on the first packet, but since the rewrite bit is not 559 set in the packet it can pass the packet unmodified to the 560 ULP. The ULP sees a packet identified by AID(A), AID(B). 562 The M6 layer initiates a state creation 3-way exchange by 563 forming a context request message. The same technique as in 564 [MIPv6] can be used to securely do this exchange without any 565 local state; use a local key which is never shared with 566 anybody and pass the context state, a timestamp, and the 567 keyed hash of the state+timestamp in the context request 568 packet. When the state, timestamp, and keyed hash value is 569 returned in the context response message, the hash is used to 570 verify that the state hasn't been modified. 572 The 3-way exchange is done asynchronously with ULP packets, 573 but it is possible (assuming the MTU allows) to piggyback ULP 574 packets on this exchange. 576 Should ULP packets be passed down to the M6 layer on B before 577 the context response message has been received there will be 578 no context state and no state installed as a result of a DNS 579 lookup (unlike on A). This will indicate that the ULP 580 message should be passed as-is (not as an M6 message) to the 581 peer. Thus during the 3-way exchange packets can flow in 582 both directions using the original locators=AIDs. (However, 583 this has some interactions with the suggestions in section 584 5.) 586 6. Host A receives the context request message. It verifies 587 that the message is related to something it sent by looking 588 at the locators (should match the AIDs) and the flowid it 589 sent (which is in the state in the context request message). 591 If a ULP packet was piggybacked A will pass that to the ULP. 593 Then A sends a content response which has the same 594 information as the context request plus a nonce/timestamp 595 that A selected. 597 7. Host B receives the context response message. It verifies 598 that the hash of the state is correct using its per-host key 599 and verifies that the timestamp is recent. At this point in 600 time it knows that A is at least not just blasting out 601 packets as a DoS - A is also responding to context request 602 messages. Thus B goes ahead and allocates state at this 603 point in time using the state that is in the context response 604 message. 606 The M6 layer selects a flowid F(B) consistent with the 607 uniqueness requirements in section 3.1 (which ensure that the 608 receiver will map to the correct AID pair). At this point in 609 time B has enough information to handle M6 packets from A, 610 even though it hasn't yet determined and verified any 611 additional peer locators from the DNS. It has also the state 612 (F(B) mainly) necessary send data packets to A with "rewrite 613 ok" set. Thus B sends a context confirm message to A which 614 contains A's nonce/timestamp from the context response and 615 F(B). 617 If a ULP packet was piggybacked on the context response B 618 will pass that to the ULP. 620 At this point in time B can start asynchronously and 621 incrementally extracting and verifying Ls(A) from the DNS. 622 The first lookup consists of finding L1(A)=AID(A) in ip6.arpa 623 to get the FQDN and record it, and lookup the AAAA RR set for 624 that FQDN to get Ls(A). Then verify (also incrementally) 625 that each member of Ls(A) is indeed assigned to A by doing a 626 reverse lookup of each one (except L1(A) which was already 627 looked up). Only when the reverse lookup of a given peer 628 locator has completed is that locator marked as verified. 629 This reverse lookup of each locator prevents 3rd party DoS 630 attacks as described in [M6SEC]. 632 8. Host A receives the context confirm message, verifies the 633 nonce/timestamp, and records F(peer) from the packet. 635 If a ULP packet was piggybacked on the context confirm A will 636 pass that to the ULP. 638 At this point in time A knows that B has context state, thus 639 it can start sending packets with "rewrite ok" set. 641 4.2. Locator Change 643 This is the sequence of events when B receives a packet with a 644 previously unused source locator for A, for instance L2(A). 646 Host B receives M6 packet with source L2(A) and destination L1(B). 647 Looks up context state using the flowid and the locators. If this 648 lookup succeeds then the locator is acceptable for incoming 649 packets (even though it might not have been verified for use as 650 return traffic) and the packet is rewritten to contain the AIDs 651 from the context state and passed to the ULP. 653 If L2(A) has not been verified then it would make sense for B to 654 put that first in the list of asynchronous DNS verifications that 655 are needed. If/once L2(A) has been verified B can make it the 656 preferred peer locator for use when sending packets to AID(A). 658 The verification needs to complete before using the locator as a 659 destination in order to prevent 3rd party DoS attacks [M6SEC]. 661 If a host receives a packet with a known flowid but where the 662 locators (source and destination) are not part of the locator sets 663 it drops the packet and sends an Unknown context error as 664 specified in section 5. 666 4.3. Handling Locator Failures 668 Should not all locators be working when the communication is 669 initiated some extra complexity arises, because the ULP has 670 already been told which AIDs to use. If the locators that where 671 selected to be AIDs are not working it isn't possible to send a 672 zero-overhead initial packet from A to B. Instead both the AIDs 673 and the working locators need to be conveyed. This could be done 674 by either reusing IP-in-IP encapsulating or defining another M6 675 message type which carries both. Details TBD. 677 After context setup the sender can use retransmit hints from the 678 ULP to get the M6 layer to try a different verified locator. 680 If one outbound path from the site fails and the border routers 681 rewrite source locators then the peer in another site will see 682 packets with the working source locators. Once that locator has 683 been verified, the return path will switch to use the working 684 locator. As long as both ends are transmitting packets this will 685 relatively quickly switch to working locators except when both 686 hosts experience a failing locator at the same time. 688 Without locator rewriting one would need to add some notification 689 e.g., by defining a new bit in the router advertisement prefixes 690 (IMHO this is semantically different than the preferred vs. 691 deprecated stuff), but we also need some mechanism to carry this 692 info from the border routers to the routers on each subnet. 694 4.4. Locator Set Changes 696 Due to events like site renumbering the set of locators assigned 697 to a host might change at a slow rate. Since this proposal uses 698 the locators in the DNS as the credible source for which locators 699 are assigned there is some coordination necessary to ensure that 700 before a host, or the border routers for a site doing rewriting, 701 start using a new source locator, that locator has propagated 702 through the DNS so that the peer could have discovered it. 704 Due to concerns about having packets with unknown, hence 705 potentially bogus, source locators triggering DNS lookups this 706 proposal instead uses the DNS TTL as an indication that the set of 707 locators need to be refreshed. One could also envision a 708 combination of receiving a packet *and* the DNS TTL having expired 709 as the trigger to redo the DNS lookups. 711 When DNS TTL expires on either host it performs a new FQDN->Ls 712 lookup to get the new set of locators. (Presumably failures to 713 redo the lookup shouldn't have a negative effect.) 715 When a host sees (based on router advertisements [DISCOVERY]) that 716 one of its locators has become deprecated and it has additional 717 locators that are still preferred, it is recommended that the host 718 start using the preferred locator(s) with the contexts that have 719 already been established. This ensures that should the deprecated 720 locator become invalid the peers have already verified other 721 locator(s) for the host. 723 4.5. Preventing Premeditated Redirection Attacks 725 The threats document [M6SEC] talks of premeditated redirection 726 attacks that is where an attacker claims to be a host before the 727 real host appears. The absence of an actual IP layer identifier 728 in this proposal makes that a non-issue; the attacker could only 729 claim to be host A if the attacker is reachable at one of A's 730 locators. Thus by definition the attacker would have to be on the 731 path between the communicating peers and such attackers can 732 perform redirection attacks in today's Internet. 734 5. HANDLING STATE LOSS 736 The protocol needs to handle two forms of state loss: 738 - a peer loosing all state, 740 - the M6 layer garbage collecting state too early due to not 741 being aware of what all ULPs do. 743 The first case is the already existing case of a host crashing and 744 "rebooting" and as a result loosing transport and application 745 state. In this case there are some added complications from the 746 M6 layer since a peer will continue to send packets assuming the 747 context still exists and due to the loss of state on the receiver 748 it isn't even able to pass the correct packet up to the ULP (e.g., 749 to be able to get TCP to generate a reset packet) since it doesn't 750 know what AIDs to use when replacing the locators. 752 The second case is a bit more subtle. Ideally an implementation 753 shouldn't discard the context state when there is some ULP that 754 still depends on this state. While this might be possible for 755 some implementations with a fixed set of applications, it doesn't 756 appear to be possible for implementations which provide the socket 757 API; there can be things like user-level "connections" on top of 758 UDP as well as application layer "session" above TCP which retain 759 the identifiers from some previous communication and expect to use 760 those identifiers at a later date. But the M6 layer has no 761 ability to be aware of this. 763 Thus an implementation shouldn't discard context state when it 764 knows it has ULP connection state (which can be checked in e.g., 765 Unix for TCP), or when there is active communication (UDP packets 766 being sent to AID(A) recently), but when there is an infrequently 767 communicating user-level "connection" over UDP or "session" over 768 TCP the context state might be garbage collected even though it 769 shouldn't. 771 For instance, if B crashes and rebooted and A retransmits a packet 772 with flowid, L3(B), L2(A) then what is needed is a packet to L1(B) 773 from L1(A) passed to the ULP so that the ULP can send an error 774 (such as a TCP reset). But B has no matching state thus it needs 775 to send an Unknown context error back. (Should the packet not 776 have "rewrite ok" set host B can pass it to the ULP since it knows 777 that such packets contain locators that are AIDs. But once the 778 context has been established the peer is likely to send all 779 packets with "rewrite ok" set.) 781 If host B instead only lost (garbage collected too early) the M6 782 context state things are a bit more complicated for packets passed 783 down from the ULP. Without without any context state the M6 layer 784 on B can not determine whether packets to AID(A) coming from the 785 ULP are destinated to a standard IPv6 host or a host which 786 supports multihoming. Either B can determine this by doing a 787 reverse lookup of AID(A)->FQDN(A) followed by a FQDN(A) lookup to 788 see of there is an M6 record (and get the locator set of A as 789 well). Or, if DNS reverse lookups are undesirable or do not work, 790 perhaps a packet could be exchanged with A to ask it whether it 791 supports multihoming. 793 If B is communicating with both standard IPv6 hosts and hosts 794 which support multihoming then it has to avoid doing these DNS 795 lookups or peer queries for every packet sent to a standard IPv6 796 host. Implementation tricks (such as "has this socket ever used 797 M6" flag at the socket layer, and "negative caching" of peers that 798 do not support M6) can be useful to avoid performance overhead. 800 If as part of this B determines that A is M6 capable it has the 801 same information as the initiator during the initial context 802 establishment thus it can follow that procedure. If A didn't 803 garbage collect its end of the state this will require some extra 804 work to come up with a single host-pair context for a pair of AIDs 805 at both ends with consistent flowids in the two hosts (i.e., 806 F(local) needs to match F(peer) at the other host). Specifying 807 this is for further study. 809 6. ENCODING BITS IN THE IPv6 HEADER? 811 The idea is to pick extra IP protocol values for common 812 combinations, and have a designated protocol value to capture the 813 uncommon IP protocols which might use M6. The uncommon IP 814 protocol values would require an additional extension header when 815 used over M6. 817 We pick two unused ranges of IP protocol values with 8 numbers 818 each (assuming we will not need more than 7 common transport 819 protocols). The ranges start at P1 and P2, respectively: 820 P1 TCP over M6 - rewrite ok 821 P1+1 UDP over M6 - rewrite ok 822 P1+2 SCTP over M6 - rewrite ok 823 P1+3 RDDP over M6 - rewrite ok 824 P1+4 ESP over M6 - rewrite ok 825 (...) 826 P1+7 escape - any protocol over M6 - rewrite ok 827 In this case we spend another 8 bytes (minimum IPv6 828 extension header size due to alignment rule) to carry the 829 actual IP protocol. This causes some mtu concerns for those 830 protocols, but they aren't very likely to be used with M6? 832 P2 TCP over M6 - no rewrite 833 P2+1 UDP over M6 - no rewrite 834 P2+2 SCTP over M6 - no rewrite 835 P2+3 RDDP over M6 - no rewrite 836 P2+4 ESP over M6 - no rewrite 837 (...) 838 P2+7 escape - any protocol over M6 - no rewrite 839 In this case we spend another 8 bytes (minimum IPv6 840 extension header size due to alignment rule) to carry the 841 actual IP protocol. This causes some mtu concerns for those 842 protocols, but they aren't very likely to be used with M6? 844 Thus a router would check if the protocol is in the P1 range and 845 if so, it can rewrite the locator(s). A host would check a 846 received packet against both P1 and P2 ranges and if so pass it to 847 the M6 shim layer. 849 Some possible alternatives to the above encoding is to: 851 - use some combination of the universal/local and group bit in 852 the interface id of the source address field to indicate 853 "rewrite ok". 855 - steal the ECN bits from the traffic class before ECN becomes a 856 proposed standard? Don't think this will be popular! 858 - always have a shim header - adds 8 bytes overhead per packet. 860 7. COMPATIBILITY WITH STANDARD IPv6 862 A host can easily implement M6 in a way that interoperates with 863 current IPv6 as follows. 865 When the DNS lookup routines do not find an M6 record for the peer 866 they will return the AAAA resource record set to the application; 867 those would be the IPv6 addresses. When the ULP passes down these 868 addresses the M6 layer will not have any state generated by the 869 DNS lookup code, thus no M6 processing will take place on the 870 sender. (Note that this relates to the M6 layer state recovery in 871 section 5.) 873 The receive side handles both standard IPv6 and M6 since it 874 demultiplexing on whether a packet is an M6 packet. 876 8. APPLICATION USAGE OF IDENTIFIERS 878 The upper level protocols will operate on AIDs which are mere 879 locators. Thus as long as a site hasn't renumbered the AID can be 880 used to either send packets to the host, or (e.g. if that locator 881 isn't working), it is possible for an application to do a reverse 882 lookup plus forward lookup of the AID to get the set of locators 883 for the peer. 885 Once a site has been renumbered the AIDs which contain the old 886 prefix will no longer be useful. Hence applications must try to 887 honor the DNS TTL somehow. 889 Applications which use to map the peer's IP address to a domain 890 name today perform a reverse lookup in the DNS (e.g., using the 891 getnameinfo() API). This proposal doesn't add or subtract to the 892 benefits of performing such reverse lookups. 894 9. CHECKSUM ISSUES 896 The IPv6 header does not have a checksum field; the IPv6 address 897 fields are assumed to be protected by the ULP pseudo-header 898 checksum. The general approach of an M6 shim which replaces 899 locators with identifiers (where only the identifiers are covered 900 by the ULP checksum) raises the potential issue of robustly 901 handling bit errors in the address fields. 903 With the definition of the M6 shim there can be undetectable bit 904 errors in the flowid field or the nexthdr field which might 905 adversely affect the operation of the protocol. And since the 906 AIDs are what's covered by the ULP's pseudo-header checksum the 907 locators in the address fields are without checksum protection. 908 An undetected bit error in the source locator would look like an 909 unverified source locator to the receiver. Thus the packet would 910 (after replacing locators with identifiers based on the context) 911 be passed to the ULP and a challenge response exchange be 912 triggered. In the case of a bit error in the locator this 913 challenge isn't likely to receive a response; and if there is a 914 response by someone it wouldn't be from the actual peer thus the 915 verification would fail. Thus such an undetected bit error is 916 harmless. 918 Except for the obscure case when Ls(A) contains multiple verified 919 locators, one or more of those are not working, and the bit error 920 causes L1(A) to be replaced by L2(A). That would make the return 921 traffic go to L2(A), but that might be a non-functioning locator. 922 In this case the mistake will be corrected when a subsequent 923 packet is received from A. 925 An undetected bit error in the destination address field is also 926 harmless; it might cause misdelivery of the packet to a host which 927 has no context but the reception of the resulting Unknown context 928 error message will show that it arrives from the incorrect locator 929 thus it will be ignored. 931 An undetected bit error in the IPv6 next header field can 932 potentially make a M6 packet appear as a non-M6 packet and vice 933 versa. This isn't any different than undetected bit errors in 934 IPv6 next header field without multihoming support. 936 An undetected bit error in the flowid in a data message could have 937 two possible effects: not finding any context state, or finding 938 the incorrect context state. In the first case the Unknown 939 context error message would be dropped by the peer since the 940 flowid included in the error message doesn't match the flowid that 941 was originally sent. In the second case this will result in a 942 packet with incorrect identifiers being delivered to the ULP which 943 most like will drop it due to ULP checksums not matching. 945 10. IMPLICATIONS FOR PACKET FILTERING 947 Ingress filtering should be replaced by locator rewrite when the 948 "rewrite ok" bit is set. 950 Locator rewriting (when the bit is set) can be applied at places 951 where ingress filtering isn't currently performed (e.g., due to 952 multihoming issues). 954 Firewall filtering potentially require modifications to be aware 955 of M6. All the packets contain locator thus a firewall would need 956 to be aware of the context state to let the correct packets 957 through. Such firewalls could optionally perform their own 958 verification by issuing DNS lookups the same way as the endpoint. 959 However, the firewalls probably has to be more careful not 960 exposing themselves to DoS attacks by doing too much DNS lookups. 962 11. IPSEC INTERACTIONS 964 As specified all of ESP, AH, and key management is layered above 965 the M6 layer. Thus they benefit from the stable identifiers 966 provided above the M6 layer. This means the IPsec security 967 associations are unaffected by switching locators. 969 The alternative would be to layer M6 above IPsec, but that doesn't 970 seem to provide any benefits. Since we want to allow routers 971 performing locator rewriting it wouldn't be possible to take 972 advantage of for instance AH to protect the integrity of the IP 973 headers. 975 12. SECURITY CONSIDERATIONS 977 This analysis is far from complete. Early analysis indicates this 978 addresses the issues in [M6SEC]. 980 Just as in today's Internet hosts on the path can inject bogus 981 packets; in this proposal they need to extract the flowids from 982 the packets in order to do this which wouldn't be hard. Packet 983 injection from off-path places becomes harder since it requires 984 guessing the 20 bit flowid together with locators that are in the 985 locator sets. 987 DNS verification implications TBD 989 13. DESIGN ALTERNATIVES 991 Use an actual extension header for M6 and use a context tag in 992 that header instead of using the flowid. This would make the 993 packets 8 bytes larger since the minimum extension header size is 994 8 bytes due to the alignment rules for extension headers in IPv6. 996 14. OPEN ISSUES 998 DNS lookup fails or times out on the receiver; what should one do? 999 Send error? 1001 Is it possible to facilitate transition to M6 using some "M6 1002 proxy" at site boundaries until all important hosts in a site have 1003 been upgraded to support M6? Would would be the properties of 1004 such a proxy? Would it place any additional requirements on the 1005 protocol itself? 1007 One of the issues with FQDNs mapping to AAAA records is that in 1008 some cases multiple AAAA records mean a multihomed host and in 1009 other cases it means multiple hosts providing the same service. 1010 If we need to introduce a new RR type for M6, would it be useful 1011 to try to make this host/service distinction more clear at the 1012 same time? An example solution would be that the M6 record would 1013 by its existence indicate the M6 capability, and its RDATA would 1014 contain a list of host names which would be used to resolve the 1015 AAAA records for each host implementing the service. 1017 Would destination locator rewriting be a useful way for the 1018 routing system to pass some information to the host? Or is source 1019 locator rewriting sufficient? 1021 Understanding the performance of DNS verification with and without 1022 DNSsec. With DNSsec how many public key signature verifications 1023 are likely to be needed for the reverse lookup of each locator? 1025 14.1. Handling Hosts without a FQDN 1027 As specified in this document each host (including the initiating 1028 one) whether or not multihomed needs to have a FQDN. 1030 However, it isn't hard to allow hosts without a FQDN to 1031 communicate with multihomed hosts that have a FQDN; as a result 1032 the hosts without a FQDN would not benefit from "rehoming". 1034 This requires that when a responder tries to verify the peer by 1035 performing DNS lookups (reverse and forward) if it fails to 1036 perform a reverse lookup on the peer AID then it will assume that 1037 the peer has no FQDN. In this case the Ls(peer) will contain only 1038 the AID(peer) i.e., the peer locator can not change. 1040 Whether the reverse lookup on the AID should be repeated (in order 1041 to handle transient failures) is TBD. 1043 14.2. Locator Set Inconsistencies 1045 Due to transient failures of the DNS lookups, misconfigured DNS 1046 (returning different information "locally" than in remote 1047 lookups), or changes to the resource record sets during a 1048 renumbering event, the two ends of a context host-pair might have 1049 conflicting views on each others locator sets. 1051 This can result in black holes if the sender uses a source locator 1052 which the receiver has not discovered using DNS lookups. It is 1053 unclear whether the error messages sent back could be used to 1054 detect and recover from this type of inconsistency. 1056 But it is possible to add an additional protocol mechanism to make 1057 the two ends converge on the set of locators which is the 1058 intersection of what the two ends know. This could be done any 1059 time after the context has been established. 1061 For example, A could send some new message type to B containing 1062 what it thinks is Ls(A) and Ls(B). When B receives this message 1063 it calculates the intersection between the received sets and its 1064 knowledge of the locator sets. The result is used both in B's 1065 context state and sent back to A. When A receives the response it 1066 can verify that the result is in fact a subset of its existing 1067 locator sets (simply by forming the intersection between its state 1068 and the received sets) and use that. As a sanity check the AIDs 1069 should not be removed from the locator sets as part of this 1070 exchange. 1072 Verifying the flowids in this exchange guards against off-path 1073 attackers artificially reducing the locator sets. 1075 14.3. Renumbering Considerations 1077 Need to write down any special coordination needed when a locator 1078 is added to a locator set or when one is removed; this can happen 1079 when a site is renumbered. 1081 14.4. Initiator Confusion vs. "Virtual Hosting" 1083 When A wants to communicate with host B and host X at the same 1084 time there can be some confusion since the DNS could return 1085 partially overlapping locator sets for the two remote hosts. For 1086 example, 1088 The lookup of FQDN(B) returns Ls(B) which contains L1(B), L2(B), 1089 ... Ln(B). 1091 The lookup of FQDN(X) returns L1(B), L1(X) 1093 The result is that connections that could be intended to go to B 1094 and to X could both end up with an AID=L1(B), but the multihoming 1095 shim layer would have two separate locator sets associated with 1096 L1(B). Thus at a minimum when the second of the two 1097 communications starts there has to be some way to resolve this 1098 conflict. 1100 In section 4.1 this is resolved by the initiator performing a 1101 reverse lookup on the AID. Thus looking up L1(B) in the ip6.arpa 1102 tree in the above example. That works because it would return 1103 FQDN(B) thus X could be safely declared as being bogus. As a 1104 result communication with X would not be possible. 1106 However, in many (IPv4) hosting setups today multiple domain names 1107 (www.foo.com, www.bar.com) are served by a single IP address. In 1108 this case the reverse lookup can't point back at both names unless 1109 the PTR resource record contains multiple records with different 1110 names. Per [RFC2181] section 10.2 this is allowed but it doesn't 1111 appear to be commonly used. 1113 Can we depend on this little used feature of the PTR usage? If 1114 not it would seems to mean that each locator can only be used with 1115 one FQDN which would be more restrictive than we have with IPv4 1116 today. 1118 15. ACKNOWLEDGEMENTS 1120 This document is the result of discussions in a MULTI6 design team 1121 but is not the "product" of that design team. The scribe wishes 1122 to acknowledge the contributions of (in alphabetical order): 1123 Iljitsch van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, and 1124 Pekka Savola. 1126 The idea to allow locator rewriting by routers was first presented 1127 by Mike O'Dell [ODELL96]. The techniques for avoiding state DoS 1128 attacks on the first packet are patterned after [MIPv6]. 1130 16. REFERENCES 1132 16.1. Normative References 1134 [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6 1135 multihoming solutions", draft-nordmark-multi6-threats- 1136 00.txt, October 2003. 1138 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1139 Addressing Architecture", RFC 3513, April 2003. 1141 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, 1142 Version 6 (IPv6) Specification", RFC 2461. 1144 16.2. Informative References 1146 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from 1147 the NSRG", draft-irtf-nsrg-report-09.txt (work in 1148 progress), March 2003. 1150 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support 1151 in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in 1152 progress), June 2003. 1154 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 1155 draft-aura-mipv6-bu-attacks-01 (work in progress), March 1156 2002. 1158 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and 1159 E. Nordmark, "Mobile IP version 6 Route Optimization 1160 Security Design Background", draft-nikander-mobileip- 1161 v6-ro-sec-01 (work in progress), June 2003. 1163 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture 1164 for IPv6", draft-odell-8+8-00.txt, October 1996, 1166 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT 1167 (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast- 1168 protocol-01.txt, October, 2003. 1170 [CB128] E. Nordmark, "Strong Identity Multihoming using 128 bit 1171 Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim- 1172 00.txt, October 2003. 1174 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 1175 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1176 1998. 1178 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1179 Protocol". RFC 2401, November 1998. 1181 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1182 November 1998. 1184 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload 1185 (ESP)", RFC 2406, November 1998. 1187 [RFC2181] R. Elz, and R. Bush, "Clarifications to the DNS 1188 Specification", RFC 2181, July 1997. 1190 AUTHORS' ADDRESSES 1192 Erik Nordmark 1193 Sun Microsystems, Inc. 1194 17 Network Circle 1195 Mountain View, CA 1196 USA 1198 phone: +1 650 786 2921 1199 fax: +1 650 786 5896 1200 email: erik.nordmark@sun.com 1202 Full Copyright Statement 1204 Copyright (C) The Internet Society (2003). All Rights Reserved. 1206 This document and translations of it may be copied and furnished to 1207 others, and derivative works that comment on or otherwise explain it 1208 or assist in its implementation may be prepared, copied, published 1209 and distributed, in whole or in part, without restriction of any 1210 kind, provided that the above copyright notice and this paragraph are 1211 included on all such copies and derivative works. However, this 1212 document itself may not be modified in any way, such as by removing 1213 the copyright notice or references to the Internet Society or other 1214 Internet organizations, except as needed for the purpose of 1215 developing Internet standards in which case the procedures for 1216 copyrights defined in the Internet Standards process must be 1217 followed, or as required to translate it into languages other than 1218 English. 1220 The limited permissions granted above are perpetual and will not be 1221 revoked by the Internet Society or its successors or assignees. 1223 This document and the information contained herein is provided on an 1224 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1225 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1226 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1227 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1228 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1230 Acknowledgement 1232 Funding for the RFC Editor function is currently provided by the 1233 Internet Society.