idnits 2.17.1 draft-nordmark-multi6-sim-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 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances 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 424: '... Receivers MUST silently ignore? Reject? [TBD] any message type...' 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 306, but not defined == Missing Reference: 'TBD' is mentioned on line 424, but not defined == Unused Reference: 'ADDR-ARCH' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'AURA02' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'NIKANDER03' is defined on line 1173, but no explicit reference was found in the text == Unused Reference: 'PAXSON01' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'INGRESS' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'NOID' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1205, 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'CBID' ** Obsolete normative reference: RFC 3513 (ref. 'ADDR-ARCH') (Obsoleted by RFC 4291) == 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? -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'IPv6') (Obsoleted by RFC 4861) == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-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: 6 errors (**), 0 flaws (~~), 19 warnings (==), 10 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 Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) 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 contains a rough outline of a potential solution to 35 IPv6 multihoming in order to stimulate discussion. 37 This proposed solution uses 126 bit identifiers which are hashes of 38 public keys (know as Cryptographically-based Identifiers) which are 39 created in an autonomous fashion by every host. When there is a need 40 to verify whether a new locator should be used with an identifier 41 than a public-key based challenge-response is used. 43 The proposal allows locator rewriting by (border) routers, and 44 ensures that the upper layer protocols can operate unmodified in a 45 multihomed setting using the stable identifiers. 47 Contents 49 1. INTRODUCTION............................................. 3 50 1.1. Non-Goals........................................... 3 51 1.2. Assumptions......................................... 4 53 2. TERMINOLOGY.............................................. 4 54 2.1. Notational Conventions.............................. 5 56 3. PROTOCOL OVERVIEW........................................ 6 57 3.1. Host-Pair Context................................... 8 58 3.2. Message Formats..................................... 9 60 4. PROTOCOL WALKTHROUGH..................................... 12 61 4.1. Initial Context Establishment....................... 12 62 4.2. Locator Change...................................... 13 63 4.3. Handling Locator Failures........................... 14 64 4.4. Locator Set Changes................................. 15 65 4.5. Preventing Premeditated Redirection Attacks......... 15 67 5. HANDLING STATE LOSS...................................... 17 69 6. APPLICATION USAGE OF IDENTIFIERS......................... 18 71 7. COMPATIBILITY WITH STANDARD IPv6......................... 19 73 8. CHECKSUM ISSUES.......................................... 20 75 9. IMPLICATIONS FOR PACKET FILTERING........................ 21 77 10. IPSEC INTERACTIONS...................................... 22 79 11. SECURITY CONSIDERATIONS................................. 22 81 12. OPEN ISSUES............................................. 23 82 12.1. Initiator Confusion vs. "Virtual Hosting".......... 24 84 13. FUTURE WORK............................................. 25 86 14. ACKNOWLEDGEMENTS........................................ 26 88 15. REFERENCES.............................................. 26 89 15.1. Normative References............................... 26 90 15.2. Informative References............................. 27 92 AUTHORS' ADDRESSES........................................... 28 94 1. INTRODUCTION 96 The goal of the IPv6 multihoming work is to allow a site to take 97 advantage of multiple attachments to the global Internet without 98 having a specific entry for the site visible in the global routing 99 table. Specifically, a solution should allow users to use multiple 100 attachments in parallel, or to switch between these attachment points 101 dynamically in the case of failures, without an impact on the upper 102 layer protocols. 104 This proposed solution uses crypto-based identifiers [CBID] 105 properties to perform enough validation to prevent redirection 106 attacks. 108 The goals for this proposed solution is to: 110 o Have no impact on upper layer protocols in general and on 111 transport protocols in particular. 113 o Address the security threats in [M6SEC]. 115 o Allow routers rewriting the (source) locators as a means of 116 quickly detecting which locator is likely to work for return 117 traffic. 119 o Minimal per-packet overhead. 121 o No extra roundtrip for setup through optional piggybacking. 123 o Take advantage of multiple locators for load spreading. 125 1.1. Non-Goals 127 The assumption is that the problem we are trying to solve is site 128 multihoming, with the ability to have the set of site locator 129 prefixes change over time due to site renumbering. Further, we 130 assume that such changes to the set of locator prefixes can be 131 relatively slow and managed; slow enough to allow updates to the DNS 132 to propagate. This proposal does not attempt to solve, perhaps 133 related, problems such as host multihoming or host mobility. 135 This proposal introduces an IP layer identifier, but it does not make 136 this identifier a first class object. In particular, there is no 137 method for taking a identifier and using it to lookup other 138 information (FQDN, set of locators, etc) about the identified entity. 139 Even with this limitation the introduction of the identifier is quite 140 useful in identifying the a host. See discussion in the section on 141 future work how it might be possible to add a lookup function over 142 time. 144 1.2. Assumptions 146 The main technical assumptions this proposal makes is that using 147 public key signatures during the more uncommon operations would 148 provide acceptable performance. The proposal doesn't require such 149 operations during normal communication; only when a locator changes 150 for a host will it need to be verified before return traffic will be 151 sent to that locator, or when two hosts claim to use the same 152 identifier. 154 Another assumption is that where DNS is already used (normally at the 155 initiating end of communication) it is acceptable to lookup the 156 identifier of the peer in the DNS in addition to the current AAAA 157 lookup (of the addresses/locators). 159 2. TERMINOLOGY 161 upper layer protocol (ULP) 162 - a protocol layer immediately above IP. Examples are 163 transport protocols such as TCP and UDP, control 164 protocols such as ICMP, routing protocols such as 165 OSPF, and internet or lower-layer protocols being 166 "tunneled" over (i.e., encapsulated in) IP such as 167 IPX, AppleTalk, or IP itself. 169 interface - a node's attachment to a link. 171 address - an IP layer name that contains both topological 172 significance and acts as a unique identifier for an 173 interface. 128 bits. 175 locator - an IP layer topological name for an interface or a 176 set of interfaces. 128 bits. The locators are 177 carried in the IP address fields as the packets 178 traverse the network. 180 identifier - an IP layer identifier for an IP layer endpoint 181 (stack name in [NSRG]). The transport endpoint is a 182 function of the transport protocol and would 183 typically include the IP identifier plus a port 184 number. 186 Application identifier (AID) 187 - The 128 bit quantity used by upper layer protocols 188 for identifying a peer. In this proposal the AID=ID 189 i.e. an IP layer identifier. This is used for 190 pseudo-header checksum computation and connection 191 identification in the ULP. 193 address field 194 - the source and destination address fields in the 195 IPv6 header. As IPv6 is currently specified this 196 fields carry "addresses". If identifiers and 197 locators are separated these fields will contain 198 locators. 200 FQDN - Fully Qualified Domain Name 202 2.1. Notational Conventions 204 A, B, and C are hosts. X is a potentially malicious host. 206 FQDN(A) is the domain name for A. 208 Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... 209 Ln(A). 211 ID(A) is an application ID for A. ID(A) is a 128 bit number 212 consisting of two fixed bits (e.g., 10) followed by 126 bits of a 213 truncated SHA1 hash of a public key that the host has generated. 215 CT(A) is a 64 bit "context tag" allocated by A and used when B sends 216 packets to A. The packets contain the low-order 32 bits of the tag, 217 named CT32(A). The full tag is used for DoS-attack prevention during 218 the PK challenge/response. 220 3. PROTOCOL OVERVIEW 222 In order to prevent redirection attacks this protocol relies on the 223 ability to verify (using public key crypto as in [CBID]) that the 224 entity requesting redirection indeed holds the private key where the 225 hash of the corresponding public key hashes to the ID itself. 227 The initiator of communication, where it uses DNS today to lookup 228 FQDN->addresses, will instead lookup both FQDN->identifier (probably 229 using some new DNS RR type) and FQDN->locator set (using AAAA 230 resource records). The existence of the identifier RR for the name 231 is an indication that the node supports multihoming. 233 ----------------------- 234 | Transport Protocols | 235 ----------------------- 237 ------ ------- -------------- ------------- 238 | AH | | ESP | | Frag/reass | | Dest opts | 239 ------ ------- -------------- ------------- 241 ----------------- 242 | M6 shim layer | 243 ----------------- 245 ------ 246 | IP | 247 ------ 249 Figure 1: Protocol stack 251 The proposal uses an M6 shim layer between IP and the ULPs as shown 252 in figure 1, in order to provide ULP independence. The M6 layer 253 corresponds to an extension header which is the minimum 8 octets for 254 data packets but larger for the messages used to establish the state 255 at the two ends and perform the public key challenge response 256 exchanges. In addition to carrying data packets, the M6 protocol has 257 three message types to perform a 3-way handshake to establish state 258 at the two ends, two message types to perform a challenge 259 request/response exchange when a new locator is introduced, and 260 finally a single message type to signal that state has been lost. 262 Layering AH and ESP above the M6 shim means that IPsec can be made to 263 be unaware of locator changes the same way that transport protocols 264 can be unaware. Thus the IPsec security associations remain stable 265 even though the locators are changing. Layering the fragmentation 266 header above the M6 shim makes reassembly robust in the case that 267 there is broken multi-path routing which results in using different 268 paths, hence potentially different source locators, for different 269 fragments. 271 The proposal uses router rewriting of (source) locators as one way to 272 determine which is the preferred (or only working) locator to use for 273 return traffic. But not all packets can have their locators 274 rewritten. Thus a simple mechanism is needed to indicate to the 275 routers on the path whether or not it is ok to rewrite the locators 276 in the packet. Conceptually this is a single bit in the IPv6 header 277 (we call it the "rewrite ok" bit) but there is no spare bit 278 available. Instead we allocate two next header values for M6; one 279 which means "rewrite ok" and one which means the rewrite should not 280 be performed by routers. 282 Applications and upper layer protocols use IDs which the M6 layer 283 will map to/from different locators. The M6 layer maintains state, 284 called host-pair context, in order to perform this mapping. The 285 mapping is performed consistently at the sender and the receiver, 286 thus from the perspective of the upper layer protocols packets appear 287 to be sent using IDs from end to end, even though the packets travel 288 through the network containing locators in the IP address fields, and 289 even though those locators might be rewritten in flight. 291 ---------------------- ---------------------- 292 | Sender A | | Receiver B | 293 | | | | 294 | ULP | | ULP | 295 | | src ID(A) | | ^ | 296 | | dst ID(B) | | | src ID(A) | 297 | v | | | dst ID(B) | 298 | M6 | | M6 | 299 | | src L1(A) | | ^ | 300 | | dst L1(B) | | | src L2(A) | 301 | v | | | dst L1(B) | 302 | IP | | IP | 303 ---------------------- ---------------------- 304 | ^ 305 -- cloud with some routers ------- 306 src L2(A) [Rewritten] 307 dst L1(B) 308 Figure 2: Mapping with router rewriting of locators. 310 The result of this consistent mapping is that there is no impact on 311 the ULPs. In particular, there is no impact on pseudo-header 312 checksums and connection identification. 314 Conceptually one could view this approach as if both IDs and locators 315 being present in every packet, but with a header compression 316 mechanism applied that removes the need for the IDs once the state 317 has been established. As we will see below the context tag will be 318 used akin to a "compression tag" i.e., to indicate the correct 319 context to use for decompression. 321 The use of the context tag allows the receiver to find the correct 322 context without relying on the locators in the packet. 324 3.1. Host-Pair Context 326 The host-pair context is established on the initiator of 327 communication based on information learned from the DNS (either by 328 starting with a FQDN or with an IP address -> FQDN lookup). The 329 responder will establish some initial state using the context 330 creation 3-way handshake. Both hosts later update the peer locators 331 based on the source locator in received packets after having verified 332 the new locator using a challenge exchange. 334 The context state contains the following information: 336 - the peer ID; ID(peer) 338 - the local ID; ID(local) 340 - the set of peer locators; Ls(peer) 342 - for each peer locator, a bit whether it has been verified for 343 return traffic using a PK challenge. 345 - the preferred peer locator - used as destination; Lp(peer) 347 - the set of local locators; Ls(local) 349 - the preferred local locator - used as source; Lp(local) 351 - the context tag used to transmit packets; CT(local) 353 - the context to expect in receive packets; CT(peer) 355 - State about peer locators that are in the process of being 356 verified in using challenge/response. 358 This state is accessed differently in the transmit and receive paths. 359 In the transmit path when the ULP passes down a packet the key to the 360 context state is the tuple ; this key must 361 identify at most one state record. In the receive path it is the 362 CT32(local) that is used to identify at most one state record. 364 At the initiating end it is possible that the DNS lookup of different 365 FQDNs return the same ID and different locator sets. This is 366 discussed in section 4.1 and 12.1. 368 The receiving end allocates the context tags thus it can trivially 369 ensure that the CT32(local) is unique. 371 3.2. Message Formats 373 The base M6 header is as follows: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Next Header | Type | Checksum | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 M6 Fields: 385 Next Header 386 8-bit selector. Identifies the type of header 387 immediately following the M6 header. Uses the same 388 values as the IPv4 Protocol field [RFC-1700 et 389 seq.]. 391 Type 392 8-bit field. The type of M6 message. The M6 393 header carries 7 different message types: 395 o Data message; to be passed to the ULP after 396 replacing the locators with the identifiers. 398 o Context request message; first message of the 399 3-way context establishment. An ULP packet can 400 be piggybacked on this message. 402 o Context response message; second message of the 403 3-way context establishment. An ULP packet can 404 be piggybacked on this message. 406 o Context confirm message; third message of the 407 3-way context establishment. An ULP packet can 408 be piggybacked on this message. 410 o Challenge request message; first message of the 411 2-way challenge. 413 o Challenge response message; second message of 414 the 2-way challenge. 416 o Unknown context message; error which is sent 417 when no state for context tag. 419 Checksum The Internet checksum applied to the IPv6 address 420 fields and the M6 header. When computing the 421 checksum the checksum field is set to zero. 423 Future versions of this protocol may define message types. 424 Receivers MUST silently ignore? Reject? [TBD] any message type 425 they do not recognize. 427 The M6 data message is as follows: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Next Header | Type = 0 | Checksum | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Context Tag | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 M6 Fields: 439 Context Tag 440 32-bit field. Identifies the context at the 441 receiver. 443 This drafts doesn't contain actual message layout for the other M6 444 message types. However, the content of these messages is specified 445 below. 447 The Context request message contains: 449 - Sender Nonce 451 - Sender ID 453 - Receiver ID 455 - Sender context tag (64 bits) 457 The Context response message contains: 459 - Receiver Nonce (copied from Sender Nonce in request) 461 - Context state consisting of: the two IDs, the two context tags, 462 and the initial locators 464 - A timestamp or nonce (for sender's benefit) 466 - A hash over the context state and timestamp (to prevent 467 modification) 469 The Context confirm message contains: 471 - The context state, timestamp/nonce, and hash copied from the 472 context response. 474 The Challenge request message contains: 476 - Sender generated nonce/timestamp 478 - The two IDs 480 - The 32-bit context tag from the received data message 482 - The source locator from the received data message 484 The Challenge response message contains: 486 - The nonce/timestamp from the challenge request 488 - The 32-bit context tag (from the challenge request) 490 - The above locator 492 - A hash value (H2) which proves that the sender knows the full 64 493 bits of both the context tags. This allows the receiver of the 494 response to avoid verifying the PK signature generated by a host 495 which can't be the original peer. 497 - The public key of the sender. 499 - The public key signature of all of the above fields. 501 The Unknown context message contains: 503 - The 32 bit context tag in the triggering data message. 505 4. PROTOCOL WALKTHROUGH 507 4.1. Initial Context Establishment 509 Here is the sequence of events when A starts talking to B: 511 1. A looks up FQDN(B) in the DNS. The lookup is both for the new 512 ID records and the AAAA records. If no ID record then the peer 513 is a standard IPv6 host and the set of AAAA records is returned 514 to the application as today. If an ID record is found then only 515 that record is returned to the application. The ID and AAAA 516 content is passed to the M6 layer on the host as ID(B) and 517 Ls(B). To make sure that the lookup from ID(B) returns a single 518 state record in the M6 layer there has to be a check if there is 519 already a record for that ID with a different Ls. One could 520 envision sending a PK challenge to the locators to resolve such 521 a conflict. See section 12.1 for more discussion. 523 2. The ULP creates "connection" state between ID(A) and ID(B) and 524 sends the first packet. ID(A) was picked using regular source 525 address selection mechanisms. 527 3. The leading two bits of the destination address (10) makes the 528 transmit side go through M6 processing. The M6 layer matches on 529 ID(B) and finds the proto-context state containing Ls(B) created 530 in step 1. The fact that the context state isn't complete 531 triggers context creation. 533 4. A picks a random Nonce to include in the Context Request 534 message. A picks pseudo-random 64-bit context tags (CT(A)) and 535 checks for duplicates against existing context state records 536 until it finds a unique one. The nonce and CT(A) are saved in 537 the context state. Then A sends the context request message to 538 one of B's locators. The data packet (TCP SYN or whatever) can 539 be piggybacked on the context request message. The "rewrite ok" 540 bit is set in the header. 542 5. The M6 layer on B receives context request message. It does not 543 find any context state for the pair of IDs. It forms the 64-bit 544 pseudo-random CT(B) and checks it against duplicates for 545 existing contexts. (It can't check against other contexts in 546 progress of being created since it doesn't create any state 547 until the context confirm is received. Hence the duplicate 548 check is redone on the context confirm.) It forms a keyed hash 549 (using K(B) which is never shares with anybody) of the context 550 state and a timestamp. Then puts the state, timestamp and hash 551 in the context response message. 553 If there was a piggybacked packet on the context request message 554 then B passes packet to ULP after putting the identifiers in the 555 IP address fields. The ULP sees a packet identified by ID(A), 556 ID(B). 558 6. The M6 layer on A receives the context response message. It 559 looks up the state using CT32(A). It verifies that the stored 560 nonce matches the echoed nonce in the message. It records the 561 source address field in as Lp(peer). It sends back a context 562 confirm message containing what was in the response message. 564 If there was a piggybacked packet on the context response 565 message then A passes packet to ULP after putting the 566 identifiers in the IP address fields. The ULP sees a packet 567 identified by ID(A), ID(B). 569 7. The M6 layer on B receives context confirm message. It looks up 570 context state using CT32(B). If state is found and the 571 identifiers are different than in the context confirm this must 572 have been a duplicate caused by concurrent context creations in 573 progress. Requires restarting by responding with a new context 574 response with a different CT(B). 576 B verifies that the timestamp is recent and then verifies that 577 the hash over the state is correct. Then it can create the 578 context state. 580 If there was a piggybacked packet on the context confirm message 581 then B passes packet to ULP after putting the identifiers in the 582 IP address fields. The ULP sees a packet identified by ID(A), 583 ID(B). 585 4.2. Locator Change 587 This is the sequence of events when B receives a packet with a 588 previously unknown source locator for A. 590 1. Host B receives a data message. Finds the context using the 591 CT32(B) that is in the message. B passes the packet to the ULP 592 after replacing the locators with the IDs (whether or not the 593 source locator is known). 595 If the source locator is in Ls(peer) and already verified then 596 the preferred return locator (Lp(peer)) is updated to use it for 597 return packets. 599 If the source locator is previously unknown then it is added to 600 the context state as a Ls(peer) awaiting verification and a 601 Challenge Request packet is generated. The challenge request 602 includes a nonce generated by B, CT32(B) (that was received in 603 the packet from the unknown locator), the identifiers and the 604 previously unknown peer locator. 606 2. Host A receives the challenge request packet. Verifies that it 607 has state for those identifiers with the CT32(peer) it received 608 on the request. 610 It computes the hash H2 to show to B that it knows both full 64 611 bit context tags as H2 = SHA1(nonce from request, CT(A), CT(B), 612 ID(A), ID(B)) 614 It includes its public key (the one whose hash is ID(A)) and 615 signs the whole challenge response using its private key. 617 3. Host B receives the challenge response packet. It finds the 618 context state using CT32(B). It verifies the nonce against what 619 it used for sending the challenge request. It verifies H2. 620 (Only devices on the path between A and B during the context 621 establishment knows CT(A) and CT(B), thus this check limits DoS 622 attacks based on forcing PK signature verification to attackers 623 on the path.) Then it verifies that the hash of the public key 624 equals ID(A), and finally the public key signature using that 625 public key. 627 4.3. Handling Locator Failures 629 The M6 layer is responsible for retransmitting context request 630 messages using different locators until a contest response is 631 received. 633 After context setup the sender can use retransmit hints from the ULP 634 to get the M6 layer to try a different verified locator. 636 If one outbound path from the site fails and the border routers 637 rewrite source locators then the peer in another site will see 638 packets with the working source locators. Once that locator has been 639 verified, the return path will switch to use the working locator. As 640 long as both ends are transmitting packets this will relatively 641 quickly switch to working locators except when both hosts experience 642 a failing locator at the same time. 644 Without locator rewriting one would need to add some notification 645 e.g., by defining a new bit in the router advertisement prefixes 646 (IMHO this is semantically different than the preferred vs. 647 deprecated stuff), but we also need some mechanism to carry this info 648 from the border routers to the routers on each subnet. 650 4.4. Locator Set Changes 652 Should the set of locators change after the context has been 653 established the ability to learn and verify new peer locators will 654 handle this fine. 656 The DNS only needs to be updated with new locators in order to allow 657 new communication to be established. 659 When a host sees (based on router advertisements [DISCOVERY]) that 660 one of its locators has become deprecated and it has additional 661 locators that are still preferred, it is recommended that the host 662 start using the preferred locator(s) with the contexts that have 663 already been established. This ensures that should the deprecated 664 locator become invalid the peers have already verified other 665 locator(s) for the host. 667 4.5. Preventing Premeditated Redirection Attacks 669 The threats document [M6SEC] talks of premeditated redirection 670 attacks that is where an attacker claims to be a host before the real 671 host appears. 673 This proposal is potentially subject to this threat because for 674 performance reasons there is no public-key challenge when the context 675 state is initially established. 677 The following sequence shows how such a redirection attack is 678 detected when X pretends to be A: 680 1. Host X with locator L1(X) sends a content request message to B. 681 In the message it claims to have ID(A) and includes CT(X). 683 2. The context response and context confirm messages are exchanged 684 resulting on B selecting CT(B) for communicating with X (which B 685 believes has identifier ID(A)). 687 3. X and B happily communicate without B performing any higher- 688 level, such as IKE/IPsec, identity check on its peer. 690 4. Host A tries to communicate with B. It sends a context request 691 message to B where the message claims to have ID(A) and includes 692 CT(A). 694 5. Host B receives the context request and discovers it already has 695 context state for ID(A). B doesn't do anything different than 696 if there was no context state - the difference in processing 697 happens when the context confirm is received - except that any 698 piggybacked ULP packet is not passed to the ULP. Thus, as in 699 section 4.1, a context tag is selected and the context reply is 700 sent, which makes A send back a context confirm. 702 6. Host B receives the context confirm and verifies it the same way 703 as in section 4.1. Then it looks if there is already a context 704 for ID(A) and finds the context which contains CT(X) and L1(X). 706 The existence of this "old" context could be due to multiple 707 reasons: 709 - The peer lost state while B retained the context state. In 710 this case one would expect that the old context has not been 711 used to receive packets for some time. (Having a protocol 712 constant denoting the minimum time after sending a packet 713 that state can be lost and later recreated would be helpful 714 here.) In this case it would also be common that the source 715 address of the packet would fall in the locator set for the 716 old context. But it isn't impossible that a peer state loss 717 and using a different locator happens at the same time. 719 - The old host was performing a premediated redirection attack. 721 - The new host is attempting a redirection attack. 723 In all cases the approach consists of sending a challenge to 724 both the "new" A and the "old" A. But depending on the time 725 since packets where last received from the "old" A the order can 726 be different. The first peer locator which responds with a 727 valid challenge response will "win" and the other context state 728 will be deleted. 730 TBD: The above has DoS concerns in terms of verifying the challenge 731 response. Having both ends remove the context state at about the 732 same time would be beneficial since it would reduce the frequency of 733 this happening in the absence of attacks, thus it would be more 734 realistic to apply resource limits for this type of challenges. 736 5. HANDLING STATE LOSS 738 The protocol needs to handle two forms of state loss: 740 - a peer loosing all state, 742 - the M6 layer garbage collecting state too early due to not being 743 aware of what all ULPs do. 745 The first case is the already existing case of a host crashing and 746 "rebooting" and as a result loosing transport and application state. 747 In this case there are some added complications from the M6 layer 748 since a peer will continue to send packets assuming the context still 749 exists and due to the loss of state on the receiver it isn't even 750 able to pass the correct packet up to the ULP (e.g., to be able to 751 get TCP to generate a reset packet) since it doesn't know what IDs to 752 use when replacing the locators. 754 The second case is a bit more subtle. Ideally an implementation 755 shouldn't discard the context state when there is some ULP that still 756 depends on this state. While this might be possible for some 757 implementations with a fixed set of applications, it doesn't appear 758 to be possible for implementations which provide the socket API; 759 there can be things like user-level "connections" on top of UDP as 760 well as application layer "session" above TCP which retain the 761 identifiers from some previous communication and expect to use those 762 identifiers at a later date. But the M6 layer has no ability to be 763 aware of this. 765 Thus an implementation shouldn't discard context state when it knows 766 it has ULP connection state (which can be checked in e.g., Unix for 767 TCP), or when there is active communication (UDP packets being sent 768 to ID(A) recently), but when there is an infrequently communicating 769 user-level "connection" over UDP or "session" over TCP the context 770 state might be garbage collected even though it shouldn't. 772 Independently whether the state loss was for the whole host or for 773 just the M6 layer things can be recovered when the loss is detected 774 as a result of receiving a packet from the peer. Should B receive a 775 packet from some locator without being able to find any context state 776 for the CT32(B) that is in the packet, it will send back an Unknown 777 context message to the source. The unknown context message includes 778 the receive tag (and it can't receive much other useful information 779 since B has no state). The Unknown context message is sent without 780 setting the "rewrite ok" bit since locator rewriting would make it 781 harder for A to perform sanity checks on this error message. 783 When A receives the Unknown context message it verifies that the 784 CT32(B) value is used by a context with the locators that are in the 785 IP address fields, and that the source address field is Lp(peer) for 786 the context (the preferred peer locator - to which an earlier data 787 message would have been sent). Once this verification has been done 788 A needs to restart the 3-way context establishment; A can reuse CT(A) 789 for this if it so desires. 791 As a result of this error handling mechanism an attacker on the path 792 between A and B can send frequent Unknown context messages (but an 793 off-path attacker cannot since it wouldn't know CT32(B)). Since 794 state loss is expected to be infrequent it is reasonable to rate 795 limit the handling of Unknown context messages per context to one per 796 minute. 798 In the case of M6 layer state loss (due to too early garbage 799 collection) the above provides recovery when the peer transmits. But 800 there is also the possibility that the lack of state will be detected 801 when the ULP is passing down a packet to transmit. In this case M6 802 would see a packet which needs state (because the leading to bits of 803 the address field is 10) but there is no state. Unless we invent a 804 method (see section 14) to lookup identifiers there is nothing that 805 can be done in that case (except perhaps wait for a while in case the 806 peer will send a packet triggering recovery using the Unknown context 807 message). Thus it is quite important that the context state is not 808 discarded prematurely. 810 TBD: If we decide to explore the approach in this proposal further, 811 would be it useful to add APIs that allow applications to advise when 812 it isn't and when it is ok to discard the context state for a 813 particular id? 815 6. APPLICATION USAGE OF IDENTIFIERS 817 In this proposal the upper layer protocols will operate on the 818 identifiers. As long as the M6 layer doesn't garbage collect context 819 state too early then those identifiers can be used by other 820 applications on the same host; they will only become useless if none 821 of the locators stored in Ls(peer) stop working for instance due to 822 renumbering of the peer. 824 But the identifier is rather useless for referrals; should B pass 825 ID(A) to C there is no mechanism for C to find A's locators. It is 826 only if A somehow contacts C that it can tell that it is indeed A. 828 In order to be able to use an identifier for establishing 829 communication a host would also need a set of locators where at least 830 one locator is still current and working. 832 Thus with this approach, unless we defer until we have explored the 833 future work in section 14, it would make sense to perform referrals 834 by either passing FQDNs or by passing an ID plus the list of locators 835 know by the referring host. One could envision a getpeerlocators() 836 API which, given an ID, would extract the locator set from the 837 context on the host itself. 839 Applications which use to map the peer's IP address to a domain name 840 today perform a reverse lookup in the DNS (e.g., using the 841 getnameinfo() API). Since the flat identifier space can't be 842 effectively added to the ip6.arpa tree, the getnameinfo() can instead 843 extract the locators from the local context state. For example, this 844 operation by B on ID(A) would find Ls(A) in the context and do a 845 reverse lookup (presumably only on one of them); L1(A). This would 846 be likely to return FQDN(A). Applications which today perform a 847 forward+reverse lookup would need then lookup FQDN(A) - to find the 848 identifier. Note that the above doesn't show that A actually is the 849 "owner" of ID(A). 851 One could envision providing an optional stronger verification to the 852 applications using the CBID properties; a verification of ID(A) would 853 extract Ls(A) and then send a challenge request to the locator. That 854 proof of ownership of ID(A) coupled with the locator->FQDN->ID DNS 855 looks gives stronger assurance of the identity of the peer IP layer 856 than today. But as pointed out in [M6SEC], applications which 857 require strong identity authentication typically also want integrity 858 with or without confidentiality for the communication. Thus identity 859 checks unrelated to payload cryptography might be unnecessary as a 860 specific service to the application layer. 862 7. COMPATIBILITY WITH STANDARD IPv6 864 A host can easily implement M6 in a way that interoperates with 865 current IPv6 as follows. 867 When the DNS lookup routines do not find an ID record for the peer 868 they will return the AAAA resource record set to the application; 869 those would be the IPv6 addresses. When the ULP passes down these 870 addresses the M6 layer will see that the leading two bits are not 871 (10) thus it will pass things through. 873 It is an open issue whether or not it makes sense to check in an 874 implementation that the content of the returned ID records start with 875 binary 10 and that the content of the returned AAAA records not start 876 with binary 10. 878 8. CHECKSUM ISSUES 880 The IPv6 header does not have a checksum field; the IPv6 address 881 fields are assumed to be protected by the ULP pseudo-header checksum. 882 The general approach of an M6 shim which replaces locators with 883 identifiers (where only the identifiers are covered by the ULP 884 checksum) raises the potential issue of robustly handling bit errors 885 in the address fields. 887 This proposal as currently written has an M6 checksum field to cover 888 the locators and the M6 header, but it isn't obvious that such a 889 checksum is strictly required for the data packets. 891 If there is an undetected bit error in the source address field, this 892 would look like an unverified source locator to the receiver. Thus 893 the packet would (after replacing locators with identifiers based on 894 the context) be passed to the ULP and a challenge response exchange 895 be triggered. In the case of a bit error in the locator this 896 challenge isn't likely to receive a response; and if there is a 897 response by someone it wouldn't be from the actual peer thus the 898 verification would fail. Thus such an undetected bit error is 899 harmless. 901 Except for the obscure case when Ls(A) contains multiple verified 902 locators, one or more of those are not working, and the bit error 903 causes L1(A) to be replaced by L2(A). That would make the return 904 traffic go to L2(A), but that might be a non-functioning locator. In 905 this case the mistake will be corrected when a subsequent packet is 906 received from A. 908 An undetected bit error in the destination address field is also 909 harmless; it might cause misdelivery of the packet to a host which 910 has no context but the reception of the resulting Unknown context 911 error message will show that it arrives from the incorrect locator 912 thus it will be ignored. 914 An undetected bit error in the M6 next header field isn't any 915 different than for the base IPv6 next header field. 917 An undetected bit error in the context tag in a data message could 918 have two possible effects: not finding any context state, or finding 919 the incorrect context state. In the first case the Unknown context 920 error message would be dropped by the peer since the tag doesn't 921 match the tag that was originally sent. In the second case this will 922 result in a packet with incorrect identifiers being delivered to the 923 ULP which most like will drop it due to ULP checksums not matching. 925 NOTE: If one thinks that new peer locators could be used for return 926 traffic without any challenge/response (e.g., relying on the hard to 927 guess context tags), then clearly a checksum must protect against 928 undetected bit errors causing the return packets to be sent to a 929 bogus locator. 931 9. IMPLICATIONS FOR PACKET FILTERING 933 Ingress filtering should be replaced by locator rewrite when the 934 "rewrite ok" bit is set. 936 Locator rewriting (when the bit is set) can be applied at places 937 where ingress filtering isn't currently performed (e.g., due to 938 multihoming issues). 940 Firewall filtering potentially require modifications to be aware of 941 M6. All the packets contain locator thus a firewall would need to be 942 aware of the context state to let the correct packets through. Such 943 firewalls could optionally perform their own verification by issuing 944 challenge request messages (the protocol doesn't explicitly allow for 945 this; they would have to pretend being the actual endpoint sending 946 the challenge). 948 10. IPSEC INTERACTIONS 950 As specified all of ESP, AH, and key management is layered above the 951 M6 layer. Thus they benefit from the stable identifiers provided 952 above the M6 layer. This means the IPsec security associations are 953 unaffected by switching locators. 955 The alternative would be to layer M6 above IPsec, but that doesn't 956 seem to provide any benefits. Since we want to allow routers 957 performing locator rewriting it wouldn't possible to take advantage 958 of for instance AH to protect the integrity of the IP headers. 960 11. SECURITY CONSIDERATIONS 962 This analysis is far from complete. Early analysis indicates this 963 addresses the issues in [M6SEC]. 965 Just as in today's Internet hosts on the path can inject bogus 966 packets; in this proposal they need to extract the context tags from 967 the packets in order to do this which wouldn't be hard. Packet 968 injection from off-path places becomes harder since it requires 969 guessing the 32 bit context tag. 971 Hosts on the path can also launch PK signature verification DoS 972 attacks against either end since they can observe the context tags 973 from the establishment and therefor compute the H2 hash in the 974 challenge response packet. This would force the endpoint to run the 975 signature verification algorithm which is expensive. If we don't 976 expect the locator sets to be very dynamic one could restrict the 977 rate at which such verification takes place, at least after the first 978 few locators have been verified for a peer. 980 The initial setup of a host-pair context does not perform any 981 verification using public key crypto, but this does not seem to make 982 the result less secure than today's Internet. Applications which do 983 not perform access control based on it's notion of the peer wouldn't 984 care about the strength of the peer's identifier. And applications 985 which perform strict access control hopefully do this using strong 986 crypto (IPsec, TLS, etc) today and would continue to do so. That 987 leaves applications which perform the questionable practise of merely 988 verifying the forward plus reverse lookups in the DNS and then using 989 the IP address (or resulting FQDN) for access control discussions. 990 As discussed in section 6 the application's lookup of locator->FQDN- 991 >ID and verifying that the identifier matches provides about the same 992 strength. [TBD are we really sure?] 994 The CBIDs are only statistically unique. But 126 bit identifiers 995 seems large enough to make collisions unlikely enough to keep the 996 protocol simple. (If not one could envision complications like 997 making the protocol capable of detecting collisions by storing the 998 public key in the context state and seeing if a host claims to use 999 the same ID but has a different public key.) While at about 8*10^18 1000 hosts in the Internet there is approximately a 50% probability that 1001 there exists 2 hosts with the same 126-bit identifier this has no 1002 effect on the protocol per see. It is not until a single host has 1003 that order of magnitude of context state records that it could get 1004 confused due to collisions. 1006 12. OPEN ISSUES 1008 Some protocol complexity is added by not performing a mutual public- 1009 key challenge immediately when a context is created. At the 1010 expensive of a performance hit one could simplify the protocol to 1011 always to these challenges. 1013 Is it possible to facilitate transition to M6 using some "M6 proxy" 1014 at site boundaries until all important hosts in a site have been 1015 upgraded to support M6? Would would be the properties of such a 1016 proxy? Would it place any additional requirements on the protocol 1017 itself? 1019 One of the issues with FQDNs mapping to AAAA records is that in some 1020 cases multiple AAAA records mean a multihomed host and in other cases 1021 it means multiple hosts providing the same service. If we need to 1022 introduce a new "ID" resource record type for multihoming, would it 1023 be useful to try to make this host/service distinction more clear at 1024 the same time? An example solution would be that the ID record in 1025 addition to returning the identifier return the FQDN under which to 1026 lookup the locators. 1028 Would destination locator rewriting be a useful way for the routing 1029 system to pass some information to the host? Or is source locator 1030 rewriting sufficient? 1032 With a context tag sufficiently large, what would happen to the 1033 residual threats if redirection was allowed without PK checks; either 1034 by just verifying the H2 hash result (which prevents off-path 1035 attackers from redirecting) or by only verifying the correct context 1036 tag in the received packets? In that case the public key 1037 verification would only occur when there is a conflict i.e. trying to 1038 create state for an ID when context state already exists for that ID 1039 perhaps with different peer locators. 1041 The mechanisms allow adding locators to a locator set but there is 1042 currently no mechanism for removing a locator (e.g., when a host 1043 renumbers). Does it make sense to add such a mechanism? 1045 The responder only discovers the peer's locators once they are used 1046 as sources in packets. Would it make sense to allow the initiator to 1047 pass a list of its locators to the responder? (They would still need 1048 to be verified before use to prevent 3rd party DoS attacks [M6SEC]). 1050 12.1. Initiator Confusion vs. "Virtual Hosting" 1052 When A wants to communicate with host B and host X at the same time 1053 there can be some confusion since the DNS could return the same 1054 identifier for B and X while returning different locator sets. For 1055 example, 1057 The lookup of FQDN(B) returns ID(B), Ls(B) 1059 The lookup of FQDN(X) returns ID(B), Ls(X) 1061 The result is that connections that could be intended to go to B and 1062 to X would both end up with the same ID at the ULP, but the 1063 multihoming shim layer would have two separate locator sets 1064 associated with ID(B). Thus at a minimum when the second of the two 1065 communications starts there has to be some way to resolve this 1066 conflict. 1068 If multiple FQDNs map to the same host, which is common in virtual 1069 hosting using IPv4 today, and the locator set is being modified for 1070 that host then this could be quite normal; looking up www.foo.com 1071 would provide the ID of the peer and a perhaps staler set of locators 1072 for the ID than looking up www.bar.com. 1074 Is it reasonable to assume when there is some overlap between Ls(B) 1075 and Ls(X) above that this is a normal condition? Should one form the 1076 intersection of Ls(B) and Ls(X) and use that for the existing context 1077 state? Or at least purge unverified peer locators, those from which 1078 the host hasn't seen a challenge response, that are not in the 1079 intersection from the locator set 1080 Section 4.1 suggests using a challenge request/response exchange when 1081 the second lookup takes place. Should the challenge be performed 1082 with the newer or older locator sets? What are the DoS issues in 1083 performing such a challenge? 1085 13. FUTURE WORK 1087 It would be desirable to explore making identifiers first class 1088 objects and having a lookup system, perhaps based on distributed hash 1089 tables, for identifiers. But there are significant scaling issues in 1090 this domain. 1092 Instead of making the identifier a hash of a host public key it could 1093 be composed in two parts (about 60 bits each): 1094 - A hash of a site public key 1096 - A hash of a host-within site certificate 1098 The certificate would be issued by using the site key. 1100 Thus the verification of a challenge response would consist of 1101 verifying that 1103 - the site public key hashes to top N bits of the ID 1105 - the host certificate hashes to the bottom 126-N bits of the ID 1107 - the host certificate is signed by the site public key 1109 - the response is signed by the host public key 1111 While this in itself isn't interesting, it would make it more 1112 feasible to use techniques like distributed hash tables to build a 1113 mapping system from IDs to locators; once (if?) we could do so the IP 1114 identifiers could become a first class object in the architecture. 1116 Doing a DHT which scales to having one entry for every IP addressable 1117 device in the Internet is less likely to be feasible than designing 1118 an DHT which only needs to scale to one entry per site in the 1119 Internet. 1121 There are several issues related to designing such a DHT such as 1122 ensuring that lookups for IDs within the same site don't depend on 1123 external connectivity (and the above scheme can easily handle that), 1124 making the DHT robust against failures and malice, and making it so 1125 that those deploying hosts in the DHT benefit themselves somehow. 1127 The use of CBIDs make authorizing insertion and modification 1128 straightforward; a PK challenge using the CBID property can take care 1129 of that. 1131 14. ACKNOWLEDGEMENTS 1133 This document has benefited from discussions with (in alphabetical 1134 order): Marcelo Bagnulo, Iljitsch van Beijnum, Brian Carpenter, Dave 1135 Crocker, Tony Li, Pekka Nikander, Mike O'Dell, and Pekka Savola. 1137 The idea to allow locator rewriting by routers was first presented by 1138 Mike O'Dell [ODELL96]. The techniques for avoiding state DoS attacks 1139 on the first packet are patterned after [MIPv6]. There are certain 1140 similarities with HIP, but the SIM design factors things so that the 1141 strength of the identifier (for "rehoming") is separate from payload 1142 protection (which can use existing techniques like IPsec). 1144 15. REFERENCES 1146 15.1. Normative References 1148 [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6 1149 multihoming solutions", draft-nordmark-multi6-threats- 1150 00.txt, October 2003. 1152 [CBID] G. Montenegro and C. Castelluccia, "Statistically Unique and 1153 Cryptographically Verifiable Identifiers and Addresses", 1154 ISOC NDSS02, San Diego, February 2002. 1156 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1157 Addressing Architecture", RFC 3513, April 2003. 1159 15.2. Informative References 1161 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 1162 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 1163 March 2003. 1165 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 1166 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), 1167 June 2003. 1169 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 1170 draft-aura-mipv6-bu-attacks-01 (work in progress), March 1171 2002. 1173 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 1174 Nordmark, "Mobile IP version 6 Route Optimization Security 1175 Design Background", draft-nikander-mobileip-v6-ro-sec-01 1176 (work in progress), June 2003. 1178 [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for 1179 Distributed Denial-of-Service Attacks", Computer 1180 Communication Review 31(3), July 2001. 1182 [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: 1183 Defeating Denial of Service Attacks which employ IP Source 1184 Address Spoofing", RFC 2827, May 2000. 1186 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture 1187 for IPv6", draft-odell-8+8-00.txt, October 1996, 1189 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 1190 6 (IPv6) Specification", RFC 2461. 1192 [NOID] E. Nordmark, "Multihoming without IP Identifiers", draft- 1193 nordmark-multi6-noid-00.txt, October 2003. 1195 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 1196 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1197 1998. 1199 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1200 Protocol". RFC 2401, November 1998. 1202 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1203 November 1998. 1205 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 1206 RFC 2406, November 1998. 1208 AUTHORS' ADDRESSES 1210 Erik Nordmark 1211 Sun Microsystems, Inc. 1212 17 Network Circle 1213 Mountain View, CA 1214 USA 1216 phone: +1 650 786 2921 1217 fax: +1 650 786 5896 1218 email: erik.nordmark@sun.com 1220 Full Copyright Statement 1222 Copyright (C) The Internet Society (2003). All Rights Reserved. 1224 This document and translations of it may be copied and furnished to 1225 others, and derivative works that comment on or otherwise explain it 1226 or assist in its implementation may be prepared, copied, published 1227 and distributed, in whole or in part, without restriction of any 1228 kind, provided that the above copyright notice and this paragraph are 1229 included on all such copies and derivative works. However, this 1230 document itself may not be modified in any way, such as by removing 1231 the copyright notice or references to the Internet Society or other 1232 Internet organizations, except as needed for the purpose of 1233 developing Internet standards in which case the procedures for 1234 copyrights defined in the Internet Standards process must be 1235 followed, or as required to translate it into languages other than 1236 English. 1238 The limited permissions granted above are perpetual and will not be 1239 revoked by the Internet Society or its successors or assignees. 1241 This document and the information contained herein is provided on an 1242 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1243 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1244 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1245 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1246 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1248 Acknowledgement 1250 Funding for the RFC Editor function is currently provided by the 1251 Internet Society.