idnits 2.17.1 draft-nordmark-multi6-noid-00.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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 307, but not defined == Missing Reference: 'TBD' is mentioned on line 775, but not defined == Unused Reference: 'ADDR-ARCH' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'AURA02' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'NIKANDER03' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 902, 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 -- 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 (~~), 15 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark 3 Oct 20, 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 20, 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 63 4. PROTOCOL WALKTHROUGH..................................... 11 64 4.1. Initial Context Establishment....................... 11 65 4.2. Locator Change...................................... 13 66 4.3. Handling Locator Failures........................... 14 67 4.4. Locator Set Changes................................. 14 69 5. HANDLING STATE LOSS...................................... 15 71 6. ENCODING BITS IN THE IPv6 HEADER?........................ 17 73 7. COMPATIBILITY WITH STANDARD IPv6......................... 18 75 8. APPLICATION USAGE OF IDENTIFIERS......................... 18 77 9. CHECKSUM ISSUES.......................................... 19 79 10. IMPLICATIONS FOR PACKET FILTERING....................... 19 81 11. IPSEC INTERACTIONS...................................... 20 83 12. SECURITY CONSIDERATIONS................................. 20 85 13. DESIGN ALTERNATIVES..................................... 20 87 14. OPEN ISSUES............................................. 20 89 15. ACKNOWLEDGEMENTS........................................ 21 91 16. REFERENCES.............................................. 21 92 16.1. Normative References............................... 21 93 16.2. Informative References............................. 22 95 AUTHORS' ADDRESSES........................................... 23 97 1. INTRODUCTION 99 The goal of the IPv6 multihoming work is to allow a site to take 100 advantage of multiple attachments to the global Internet without 101 having a specific entry for the site visible in the global routing 102 table. Specifically, a solution should allow users to use multiple 103 attachments in parallel, or to switch between these attachment points 104 dynamically in the case of failures, without an impact on the upper 105 layer protocols. 107 This proposed solution uses existing DNS mechanisms to perform enough 108 validation to prevent redirection attacks. 110 The goals for this proposed solution is to: 111 o Have no impact on upper layer protocols in general and on 112 transport protocols in particular. 114 o Address the security threats in [M6SEC]. 116 o Allow routers rewriting the (source) locators as a means of 117 quickly detecting which locator is likely to work for return 118 traffic. 120 o No per-packet overhead. 122 o No extra roundtrip for setup. 124 o Take advantage of multiple locators/addresses for load spreading. 126 1.1. Non-Goals 128 The assumption is that the problem we are trying to solve is site 129 multihoming, with the ability to have the set of site locator 130 prefixes change over time due to site renumbering. The assumption is 131 that such changes to the set of locator prefixes can be relatively 132 slow and managed; slow enough to allow updates to the DNS to 133 propagate. Thus this proposal does not attempt to solve, perhaps 134 related, problems such as host multihoming or host mobility. 136 This proposal also does not try to provide an IP identifier. Even 137 though such a concept would be useful to ULPs and applications, 138 especially if the management burden for such a name space was zero 139 and there was an efficient yet secure mechanism to map from 140 identifiers to locators, such a name space isn't necessary (and 141 furthermore doesn't seem to help) when using the DNS to verify the 142 locator relationships. 144 1.2. Assumptions 146 The main technical assumptions this proposal makes is that the DNS 147 infrastructure can be used for verification of the relationship 148 between locators on both the initiator of communication and the 149 responding peer. In particular, it assumes that getting DNS reverse 150 maps (ip6.arpa) populated for the nodes that wish to take advantage 151 of multihoming will not be a significant problem. 153 2. TERMINOLOGY 155 upper layer protocol (ULP) 156 - a protocol layer immediately above IP. Examples are 157 transport protocols such as TCP and UDP, control 158 protocols such as ICMP, routing protocols such as 159 OSPF, and internet or lower-layer protocols being 160 "tunneled" over (i.e., encapsulated in) IP such as 161 IPX, AppleTalk, or IP itself. 163 interface - a node's attachment to a link. 165 address - an IP layer name that contains both topological 166 significance and acts as a unique identifier for an 167 interface. 128 bits. 169 locator - an IP layer topological name for an interface or a 170 set of interfaces. 128 bits. The locators are 171 carried in the IP address fields as the packets 172 traverse the network. 174 identifier - an IP layer identifier for an IP layer endpoint 175 (stack name in [NSRG]). The transport endpoint is a 176 function of the transport protocol and would 177 typically include the IP identifier plus a port 178 number. NOTE: This proposal does not contain any IP 179 layer identifiers. 181 Application identifier (AID) 182 - an IP locator which has been selected for 183 communication with a peer to be used by the upper 184 layer protocol. 128 bits. This is used for 185 pseudo-header checksum computation and connection 186 identification in the ULP. Different sets of 187 communication to a node (e.g., different 188 connections) might use different AIDs in order to 189 enable load spreading. 191 address field 192 - the source and destination address fields in the 193 IPv6 header. As IPv6 is currently specified this 194 fields carry "addresses". If identifiers and 195 locators are separated these fields will contain 196 locators. 198 FQDN - Fully Qualified Domain Name 200 2.1. Notational Conventions 202 A, B, and C are nodes. 204 FQDN(A) is the domain name for A. 206 Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... 207 Ln(A). 209 AID(A) is an application ID for A. AID(A) is always one member of 210 Ls(A). 212 3. PROTOCOL OVERVIEW 214 In order to prevent redirection attacks this protocol relies on the 215 DNS (for the nodes which support this protocol) having maintained and 216 consistent forward and reverse maps. This allows any node, given one 217 locator, to determine the corresponding FQDN and the set of locators 218 for the node. Once those lookups have been performed, and the 219 original locator is indeed part of the set, the node can happily 220 allow any of those locators without being subject to redirection 221 attacks. Keeping the FQDN around allows the solution to handle 222 graceful renumbering by being able to redo the DNS (e.g., based on 223 the TTL on the resource records). 225 DNS is also used to provide an indication of M6 capability of a node. 226 The details of this is TBD but a simple example would be to introduce 227 a new M6 RR type in the DNS which has no RDATA; thus the mere 228 existence of such a record at a FQDN implies that the node supports 229 the M6 protocol. 231 ----------------------- 232 | Transport Protocols | 233 ----------------------- 235 ------ ------- -------------- ------------- 236 | AH | | ESP | | Frag/reass | | Dest opts | 237 ------ ------- -------------- ------------- 239 ----------------- 240 | M6 shim layer | 241 ----------------- 243 ------ 244 | IP | 245 ------ 247 Figure 1: Protocol stack 249 The proposal uses an M6 shim layer between IP and the ULPs as shown 250 in figure 1, in order to provide ULP independence. Conceptually the 251 M6 shim layer behaves as if it is an extension header, which would be 252 ordered immediately after any hop-by-hop options in the packet. 253 However, the amount of data that needs to be carried in an actual M6 254 extension header is close to zero. By using some encoding of the 255 nexthdr value it is possible to carry the common protocols/extension 256 headers without making the packets larger. The nexthdr encodings are 257 discussed later in this document. We refer to packets that use this 258 encoding to indicate to the receiver that M6 processing should be 259 applied as "M6 packets" (analogous to "ESP packets" or "TCP 260 packets"). 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 causes different paths, 268 hence potentially different source locators, for different fragments. 270 The proposal uses router rewriting of (source) locators as one way to 271 determine which is the preferred (or only working) locator to use for 272 return traffic. But not all packets can have their locators 273 rewritten. In addition to existing IPv6 packets, the packets 274 exchanged before M6 host-pair context state is established at the 275 receiver can not have their locators rewritten. Thus a simple 276 mechanism is needed to indicate to the routers on the path whether or 277 not it is ok to rewrite the locators in the packet. Conceptually 278 this is a single bit in the IPv6 header (we call it the "rewrite ok" 279 bit) but there is no spare bit available. Later in the document we 280 show how we solve this by allocating a range of next header values to 281 denote this semantic bit. 283 Applications and upper layer protocols use AIDs which the M6 layer 284 will map to/from different locators. The M6 layer maintains state, 285 called host-pair context, in order to perform this mapping. The 286 mapping is performed consistently at the sender and the receiver, 287 thus from the perspective of the upper layer protocols packets appear 288 to be sent using AIDs from end to end, even though the packets travel 289 through the network containing locators in the IP address fields, and 290 even though those locators might be rewritten in flight. 292 ---------------------- ---------------------- 293 | Sender A | | Receiver B | 294 | | | | 295 | ULP | | ULP | 296 | | src AID(A) | | ^ | 297 | | dst AID(B) | | | src AID(A) | 298 | v | | | dst AID(B) | 299 | M6 | | M6 | 300 | | src L1(A) | | ^ | 301 | | dst L1(B) | | | src L2(A) | 302 | v | | | dst L1(B) | 303 | IP | | IP | 304 ---------------------- ---------------------- 305 | ^ 306 -- cloud with some routers ------- 307 src L2(A) [Rewritten] 308 dst L1(B) 309 Figure 2: Mapping with router rewriting of locators. 311 The result of this consistent mapping is that there is no impact on 312 the ULPs. In particular, there is no impact on pseudo-header 313 checksums and connection identification. 315 Conceptually one could view this approach as if both AIDs and 316 locators being present in every packet, but with a header compression 317 mechanism applied that removes the need for the AIDs once the state 318 has been established. As we will see below the flowid will be used 319 akin to a "compression tag" i.e., to indicate the correct context to 320 use for decompression. 322 The need for some "compression tag" is because the desire to allow 323 load spreading and handle site renumbering. Without those desires it 324 could have been possible to e.g. designate one fixed locator as the 325 AID for a node and storing that in the DNS. But instead different 326 connections between two nodes are allowed to use different AIDs and 327 on reception of a M6 packet the correct AIDs my be inserted into the 328 IP address fields before passing the packet to the ULP. The flowid 329 serves as a convenient "compression tag" without increasing the 330 packet size, and this usage doesn't conflict with other flowid usage. 332 In addition to the zero overhead data messages, there are three 333 different M6 message types introduced (which could be defined as new 334 ICMPv6 messages). They are used to perform a 3-way handshake to 335 create state at both endpoints without creating state on the first 336 received packet (which would introduce a memory consumption DoS 337 attack). The three message types are called: 339 o Context request message; first message of the 3-way context 340 establishment. Sent by the responder when a data packet arrives 341 witn no context state. An ULP packet can be piggybacked on this 342 message. 344 o Context response message; second message of the 3-way context 345 establishment. Sent in response to a context request. An ULP 346 packet can be piggybacked on this message. 348 o Context confirm message; third message of the 3-way context 349 establishment. Sent in response to a context response. An ULP 350 packet can be piggybacked on this message. 352 Similar to MAST [MAST] the above exchange can be performed 353 asynchronously with data packets flowing between the two nodes; until 354 context state has been established at both ends the packets would 355 flow without allowing router rewriting of locators and without the 356 ability for the hosts to switch locators. 358 Once the 3-way state creation exchange has completed there is host- 359 pair context state at both hosts. At that point in time the 360 responder (which didn't use DNS before the setup) can asynchronously 361 start retrieving and verifying additional locators using the DNS. 362 Once a peer locator has been verified the node will accept packets 363 from that locator as well as dynamically switch to using the last 364 received source locator (that is already verified) as the destination 365 locator for return traffic. 367 3.1. Host Pair Context 369 The host pair context is established on the initiator of 370 communication based on information learned from the DNS (either by 371 starting with a FQDN or with an IP address -> FQDN lookup). The 372 responder will establish some initial state using the context 3-way 373 handshake and later discover and verify the peer's locators using the 374 DNS. 376 The context state contains the following information: 378 - the peer locator which the ULP uses as ID; AID(peer) 380 - the local locator which the ULP uses as ID; AID(local) 382 - the set of peer locators; Ls(peer) 384 - for each peer locator, a bit whether it has been verified with the 385 DNS (by doing reverse + forward lookup) 387 - the preferred peer locator - used as destination; Lp(peer) 389 - the set of local locators; Ls(local) 391 - the preferred local locator - used as source; Lp(local) 393 - the flowid used to transmit packets; F(local) 395 - the flowid to expect in receive packets; F(peer) 397 - the fqdn for the peer; FQDN(peer) 399 - State about peer locators that are in the process of being 400 verified in the DNS 402 This state is accessed differently in the transmit and receive paths. 403 In the transmit path when the ULP passes down a packet the key to the 404 context state is the tuple ; this key must 405 identify at most one state record. In the receive path it is the 406 F(peer) plus one of the locators in each of Ls(local) and Ls(peer) 407 that are used to identify at most one state record. 409 These uniqueness requirements imposed by those lookup keys uniquely 410 identifying one state record means that one can not create multiple 411 records (e.g. with different FQDN or locator sets) that have the same 412 AID pair, and the peer must pick a flowid so that host pair contexts 413 which have at least one common members in Ls(local) and in the 414 Ls(peer) sets, but with different AID pair, gets a different 415 F(local). The context state at both ends must be consistent for this 416 to be completely robust. One way of ensuring this is to have each 417 node perform a periodic DNS lookup of its own FQDN in order to have a 418 current Ls(local) that is the same as the Ls(peer) that the peer 419 would find in the DNS. 421 Note that the flowids could be selected to be finer grain than above; 422 for instance having a different flowid for each connection. Doing so 423 requires some efficient datastructure organization at the receiver to 424 map multiple F(peer) to the same context. 426 4. PROTOCOL WALKTHROUGH 428 4.1. Initial Context Establishment 430 Here is the sequence of events when A starts talking to B: 432 1. A looks up FQDN(B) in the DNS which returns Ls(B) plus "B is M6 433 capable" One locator is selected to be returned to the 434 application: AID(B) = L1(B) The others are installed in the M6 435 layer on the host with AID(B) being the key to find that state. 436 To make sure that the lookup from AID(B) returns a single state 437 record it appears that one needs to do a reverse lookup AID(B)- 438 >fqdn and check that the result is FQDN(B). Whether this check 439 can be deferred until two entities try to use the same AID(B) 440 for a different Ls is for further study. Always doing the 441 reverse lookup would be more predictable in any case. 443 2. The ULP creates "connection" state between AID(A)=L1(A) and 444 AID(B) and sends the first packet. L1(A) was picked using 445 regular source address selection mechanisms. 447 3. The M6 layer matches on AID(B) and finds the proto-context state 448 (setup in step #1) with Ls(B). The existence of that state will 449 make the M6 layer send a M6 packet. The M6 layer selects a 450 flowid F(local) consistent with the above uniqueness 451 requirements (which ensure that the receiver will map to the 452 correct AID pair). 454 4. The packet (TCP SYN or whatever) is sent to peer with locators 455 L1(A) to L1(B) i.e., the same as the AIDs. Since B doesn't have 456 any context state yet, A will not set the "rewrite ok" bit in 457 the header. 459 5. Node B receives packet and sees it is a "M6 packet". Passes the 460 packet to the M6 shim layer. The M6 layer can't create state on 461 the first packet, but since the rewrite bit is not set in the 462 packet it can pass the packet unmodified to the ULP. The ULP 463 sees a packet identified by AID(A), AID(B). 465 The M6 layer initiates a state creation 3-way exchange by 466 forming a context request message. The same technique as in 467 [MIPv6] can be used to securely do this exchange without any 468 local state; use a local key which is never shared with anybody 469 and pass the context state, a timestamp, and the keyed hash of 470 the state+timestamp in the context request packet. When the 471 state, timestamp, and keyed hash value is returned in the 472 context response message, the hash is used to verify that the 473 state hasn't been modifed. 475 The 3-way exchange is done asynchronously with ULP packets, but 476 it is possible (assuming the MTU allows) to piggyback ULP 477 packets on this exchange. 479 Should ULP packets be passed down to the M6 layer on B before 480 the context response message has been received there will be no 481 context state and no state installed as a result of a DNS lookup 482 (as on A). This will indicate that the ULP message should be 483 passed as-is (not as an M6 message) to the peer. Thus during 484 the 3-way exchange packets can flow in both directions using the 485 original locators=AIDs. 487 6. Node A receives the context request message. It verifies that 488 the message is related to something it sent by looking at the 489 locators (should match the AIDs) and the flowid it sent (which 490 is in the state in the context request message). 492 If a ULP packet was piggybacked A will pass that to the ULP. 494 Then A sends a content response which has the same information 495 as the context request plus a nonce/timestamp that A selected. 497 7. Node B receives the context response message. It verifies that 498 the hash of the state is correct using its per-node key. At 499 this point in time it knows that A is at least not just blasting 500 out packets as a DoS - A is also responding to context request 501 messages. Thus B goes ahead and allocates state at this point 502 in time using the state that is in the context response message. 504 The M6 layer selects a flowid F(B) consistent with the above 505 uniqueness requirements (which ensure that the receiver will map 506 to the correct AID pair). At this point in time B has enough 507 information to handle M6 packets from A, even though it hasn't 508 yet determined and verified any additional peer locators from 509 the DNS. It has also the state (F(B) mainly) necessary send 510 data packets to A with "rewrite ok" set. Thus B sends a context 511 confirm message to A which contains A's nonce/timestamp from the 512 context response and F(B). 514 If a ULP packet was piggybacked on the context response B will 515 pass that to the ULP. 517 At this point in time B can start asynchronously and 518 incrementally to extract and verify Ls(A) from the DNS. The 519 first lookup consists of finding L1(A)=AID(A) in ip6.arpa to get 520 the FQDN and record it, and lookup the AAAA RR set for that FQDN 521 to get Ls(A). Then verify (also incrementally) that each member 522 of Ls(A) is indeed assigned to A by doing a reverse lookup of 523 each one (except L1(A) which was already looked up). Only when 524 the reverse lookup of a given peer locator has completed is that 525 locator marked as verified. 527 8. Node A receives the context confirm message, verifies the 528 nonce/timestamp, and records F(peer) from the packet. 530 If a ULP packet was piggybacked on the context confirm A will 531 pass that to the ULP. 533 At this point in time A knows that B has context state, thus it 534 can start sending packets with "rewrite ok" set. 536 4.2. Locator Change 538 This is the sequence of events when B receives a packet with a 539 previously unused source locator for A, for instance L2(A). 541 Node B receives M6 packet with source L2(A) and destination L1(B). 542 Looks up context state using the flowid and the locators. If this 543 lookup succeds then the locator is acceptable for incoming packets 544 (even though it might not have been verified for use as return 545 traffic) and the packet is rewritten to contain the AIDs from the 546 context state and passed to the ULP. 548 If L2(A) has not been verified then it would make sense for B to put 549 that first in the list of asynchronous DNS verifications that are 550 needed. If/once L2(A) has been verified B can make it the preferred 551 peer locator for use when sending packets to AID(A). 553 The verification needs to complete before using the locator as a 554 destination in order to prevent 3rd party DoS attacks [M6SEC]. 556 If a node receives a packet with a known flowid but where the 557 locators (src and dst) are not part of the sets it drops the packet. 558 [TBD: Useful vs. harmful to send ICMP error?] 560 4.3. Handling Locator Failures 562 Should not all locators be working when the communication is 563 initiated some extra complexity arises, because the ULP has already 564 been told which AIDs to use. If the locators that where selected to 565 be AIDs are not working it isn't possible to send a zero-overhead 566 initial packet from A to B. Instead both the AIDs and the working 567 locators need to be conveyed. This could be done by either reusing 568 IP-in-IP encapsulating or defining another M6 message type which 569 carries both. 571 After context setup the sender can use retransmit hints from the ULP 572 to get the M6 layer to try a different verified locator. 574 If one outbound path from the site fails and the border routers 575 rewrite source locators then the peer in another site will see 576 packets with the working source locators. Once that has locator been 577 verified, the return path will switch to use the working locator. As 578 long as both ends are transmitting packets this will relatively 579 quickly switch to working locators except when both nodes experience 580 a failing locator at the same time. 582 Without locator rewriting one would need to add some notification 583 e.g., by defining a new bit in the router advertisement prefixes 584 (IMHO this is semantically different than the preferred vs. 585 deprecated stuff), but we also need some mechanism to carry this info 586 from the border routers to the routers on each subnet. 588 4.4. Locator Set Changes 590 Due to events like site renumbering the set of locators assigned to a 591 node might change at a slow rate. Since this proposal uses the 592 locators in the DNS as the credible source for which locators are 593 assigned there is some coordination necessary to ensure that before a 594 host, or the border routers for a site doing rewriting, start using a 595 new source locator, that locator has propagated through the DNS so 596 that the peer could have discovered it. 598 Due to concerns about having packets with unknown, hence potentially 599 bogus, source locators triggering DNS lookups this proposal instead 600 uses the DNS TTL as an indication that the set of locators need to be 601 refreshed. One could also envision a combination of receiving a 602 packet *and* the DNS TTL having expired as the trigger to redo the 603 DNS lookups. 605 When DNS TTL expires on either node it performs a new fqdn->Ls lookup 606 to get the new set of locators. (Presumably failures to redo the 607 lookup shouldn't have a negative effect.) 609 5. HANDLING STATE LOSS 611 The protocol needs to handle two forms of state loss: 613 - a peer loosing all state, 615 - the M6 layer garbage collecting state too early due to not being 616 aware of what all ULPs do. 618 The first case is the already existing case of a node crashing and 619 "rebooting" and as a result loosing transport and application state. 620 In this case there are some added complications from the M6 layer 621 since a peer will continue to send packets assuming the context still 622 exists and due to the loss of state on the receiver it isn't even 623 able to pass the correct packet up to the ULP (e.g., to be able to 624 get TCP to generate a reset packet) since it doesn't know what AIDs 625 to use when replacing the locators. 627 The second case is a bit more subtle. Ideally an implementation 628 shouldn't discard the context state when there is some ULP that still 629 depends on this state. While this might be possible for some 630 implementations with a fixed set of applications, it doesn't appear 631 to be possible for implementations which provide the socket API; 632 there can be things like user-level "connections" on top of UDP as 633 well as application layer "session" above TCP which retain the 634 identifiers from some previous communication and expect to use those 635 identifiers at a later date. But the M6 layer has no ability to be 636 aware of this. 638 Thus an implementation shouldn't discard context state when it knows 639 it has ULP connection state (which can be checked in e.g., Unix for 640 TCP), or when there is active communication (UDP packets being sent 641 to AID(A) recently), but when there is an infrequently communicating 642 user-level "connection" over UDP or "session" over TCP the context 643 state might be garbage collected even though it shouldn't. 645 For instance if B lost all state and A retransmits a packet with 646 flowid, L3(B), L2(A) then what is needed is a packet to L1(B) from 647 L1(A) passed to the ULP so that the ULP can send an error (such as a 648 TCP reset). But B has no matching state thus it needs to send an 649 error back. Should the packet not have "rewrite ok" set it can pass 650 it to the ULP since it knows that such packets contain locators that 651 are AIDs. Thus the protocol needs a "Unknown context" error message 652 - probably akin to the one defined in [CB128]. 654 Local loss of context state (on B in this example) has slightly 655 different issues since without any context state the M6 layer on B 656 can not determine whether a peer is a standard IPv6 node or a node 657 which supports multihoming. B can determine this by doing a reverse 658 lookup of AID(A)->FQDN(A) followed by a FQDN(A) lookup to see of 659 there is an M6 record (and get the locator set of A as well). 661 But if B is communicating with both standard IPv6 nodes and nodes 662 which support multihoming then it has to avoid doing these DNS 663 lookups for every packet sent to a standard IPv6 node. 664 Implementation tricks (such as "has this socket ever used M6" flag at 665 the socket layer, and "negative caching" of peers that do not support 666 M6) can be useful to avoid performance overhead. 668 If as part of this B determines that A is M6 capable it has the same 669 information as the initiator during the initial context establishment 670 thus it can follow that procedure. If A didn't garbage collect its 671 end of the state this will require some extra work to come up with a 672 single host-pair context for a pair of AIDs at both ends with 673 consistent flowids in the two nodes (i.e., F(local) needs to match 674 F(peer) at the other node). Specifying this is for further study. 676 6. ENCODING BITS IN THE IPv6 HEADER? 678 The idea is to pick extra IP protocol values for common combinations, 679 and have a designated protocol value to capture the uncommon IP 680 protocols which might use M6. 682 We pick two unused ranges of IP protocol values which 8 numbers each 683 (assuming we will not need more than 7 common transport protocols). 684 The ranges start at P1 and P2, respectively: 685 P1 TCP over M6 - rewrite ok 686 P1+1 UDP over M6 - rewrite ok 687 P1+2 SCTP over M6 - rewrite ok 688 P1+3 RDDP over M6 - rewrite ok 689 P1+4 ESP over M6 - rewrite ok 690 P1+7 escape - any protocol over M6 - rewrite ok 691 In this case we spend another 8 bytes (minimum IPv6 692 extension header size due to alignment rule) to carry 693 the actual IP protocol. This causes some mtu concerns for those 694 protocols, but they aren't very likely to be used with M6? 696 P2 TCP over M6 - no rewrite 697 P2+1 UDP over M6 - no rewrite 698 P2+2 SCTP over M6 - no rewrite 699 P2+3 RDDP over M6 - no rewrite 700 P2+4 ESP over M6 - no rewrite 701 P2+7 escape - any protocol over M6 - no rewrite 702 In this case we spend another 8 bytes (minimum IPv6 703 extension header size due to alignment rule) to carry 704 the actual IP protocol. This causes some mtu concerns for those 705 protocols, but they aren't very likely to be used with M6? 707 Thus a router would check if the protocol is in the P1 range and if 708 so, it can rewrite the locator(s). A host would check a received 709 packet against both P1 and P2 ranges and if so pass it to the M6 shim 710 layer. 712 Some possible alternatives to the above encoding is to: 714 - use something combination of the universal/local and group bit in 715 the interface id of the source address to indicate "rewrite ok". 717 - steal the ECN bits from the traffic class before ECN becomes a 718 proposed standard? Don't think this will be popular! 720 - always have a shim header - adds 8 bytes overhead per packet. 722 7. COMPATIBILITY WITH STANDARD IPv6 724 A node can easily implement M6 in a way that interoperates with 725 current IPv6 as follows. 727 When the DNS lookup routines do not find an M6 record for the peer 728 they will return the AAAA resource record set to the application; 729 those would be the IPv6 addresses. When the ULP passes down these 730 addresses the M6 layer will not have any state generated by the DNS 731 lookup code, thus no M6 processing will take place on the sender. 732 (Note that this interferes with the M6 layer state recovery concerns 733 above.) 735 The receive side handles both standard IPv6 and M6 since it 736 demultiplexing on whether a packet is an M6 packet. 738 8. APPLICATION USAGE OF IDENTIFIERS 740 The upper level protocols will operate on AIDs which are mere 741 locators. Thus as long as a site hasn't renumbered the AID can be 742 used to either send packets to the node, or (e.g. if that locator 743 isn't working), it is possible for an application to do a reverse 744 lookup plus forward lookup of the AID to get the set of locators for 745 the peer. 747 Once a site has been renumbered the AIDs which contain the old prefix 748 will no longer be useful. Hence applications must try to honor the 749 DNS TTL somehow. 751 Applications which use to map the peer's IP address to a domain name 752 today perform a reverse lookup in the DNS (e.g., using the 753 getnameinfo() API). This proposal doesn't add or subtract to the 754 benefits of performing such reverse lookups. 756 9. CHECKSUM ISSUES 758 The IPv6 header does not have a checksum field; the IPv6 address 759 fields are assumed to be protected by the ULP pseudo-header checksum. 760 The general approach of an M6 shim which replaces locators with 761 identifiers (where only the identifiers are covered by ULP checksum) 762 raises the potential issue of robustly handling bit errors in the 763 address fields. 765 With the definition of the M6 shim there can be undetectable bit 766 errors in the flowid field or the nexthdr field which might adversely 767 affect the operation of the protocol. And since the AIDs are what's 768 covered by the ULP's pseudo-header checksum the locators in the 769 address fields are without checksum protection. Since the locators 770 are verified against the set of locators determined from the DNS, the 771 worst effect of an undetected bit error in the locators is an error 772 message being sent back [TBD] 774 Undetected bit errors in the flowid can have the following effects 775 [TBD] 777 10. IMPLICATIONS FOR PACKET FILTERING 779 Ingress filtering should be replaced by locator rewrite when the 780 "rewrite ok" bit is set. 782 Locator rewriting (when the bit is set) can be applied at places 783 where ingress filtering isn't currently performed (e.g., due to 784 multihoming issues). 786 Firewall filtering potentially require modifications to be aware of 787 M6. All the packets contain locator thus a firewall would need to be 788 aware of the context state to let the correct packets through. Such 789 firewalls could optionally perform their own verification by issuing 790 DNS lookups the same way as the endpoint. However, the firewalls 791 probably has to be more careful not exposing themselves to DoS 792 attacks by doing too much DNS lookups. 794 11. IPSEC INTERACTIONS 796 As specified all of ESP, AH, and key management is layered above the 797 M6 layer. Thus they benefit from the stable identifiers provided 798 above the M6 layer. This means the IPsec security associations are 799 unaffected by switching locators. 801 The alternative would be to layer M6 above IPsec, but that doesn't 802 seem to provide any benefits. Since we want to allow routers 803 performing locator rewriting it isn't possible to take advantage of 804 for instance AH to protect the integrity of the IP headers. 806 12. SECURITY CONSIDERATIONS 808 Early analysis indicates this addresses the issues in [M6SEC]. 810 13. DESIGN ALTERNATIVES 812 Use an actual extension header for M6 and place the context tag in 813 that header instead of using the flowid. This would make the packets 814 8 bytes larger since the minimum extension header size is 8 bytes due 815 to the alignment rules for extension headers in IPv6. 817 14. OPEN ISSUES 819 DNS lookup fails or times out on the receiver; what should one do? 820 Send error? 822 Is it possible to facilitate transition to M6 using some "M6 proxy" 823 at site boundaries until all important hosts in a site have been 824 upgraded to support M6? Would would be the properties of such a 825 proxy? Would it place any additional requirements on the protocol 826 itself? 827 One of the issues with FQDNs mapping to AAAA records is that in some 828 cases multiple AAAA records mean a multihomed host and in other cases 829 it means multiple hosts providing the same service. If we need to 830 introduce a new RRtype for M6, would it be useful to try to make this 831 host/service distinction more clear at the same time? An example 832 solution would be that the M6 record would by its existence indicate 833 the M6 capability, and its RDATA would contain a list of host names 834 which would be used to resolve the AAAA records for each host 835 implementing the service. 837 Would destination locator rewriting be a useful way for the routing 838 system to pass some information to the node? Or is source locator 839 rewriting sufficient? 841 15. ACKNOWLEDGEMENTS 843 This document is the result of discussions in a MULTI6 design team 844 but is not the "product" of that design team. The scribe wishes to 845 acknowledge the contributions of (in alphabetical order): Iljitsch 846 van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, and Pekka Savola. 848 The idea to allow locator rewriting by routers was first presented by 849 Mike O'Dell [ODELL96]. The techniques for avoiding state DoS attacks 850 on the first packet are patterned after [MIPv6]. 852 16. REFERENCES 854 16.1. Normative References 856 [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6 857 multihoming solutions", draft-nordmark-multi6-threats- 858 00.txt, October 2003. 860 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 861 Addressing Architecture", RFC 3513, April 2003. 863 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 864 6 (IPv6) Specification", RFC 2461. 866 16.2. Informative References 868 [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the 869 NSRG", draft-irtf-nsrg-report-09.txt (work in progress), 870 March 2003. 872 [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in 873 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), 874 June 2003. 876 [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", 877 draft-aura-mipv6-bu-attacks-01 (work in progress), March 878 2002. 880 [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. 881 Nordmark, "Mobile IP version 6 Route Optimization Security 882 Design Background", draft-nikander-mobileip-v6-ro-sec-01 883 (work in progress), June 2003. 885 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture 886 for IPv6", draft-odell-8+8-00.txt, October 1996, 888 [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): 889 AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, 890 October, 2003. 892 [CB128] E. Nordmark, "Strong Identity Multihoming using 128 bit 893 Identifiers (SIM/CBID128)", draft-nordmark-multi6-sim- 894 00.txt, October 2003. 896 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 897 Protocol". RFC 2401, November 1998. 899 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 900 November 1998. 902 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 903 RFC 2406, November 1998. 905 AUTHORS' ADDRESSES 907 Erik Nordmark 908 Sun Microsystems, Inc. 909 17 Network Circle 910 Mountain View, CA 911 USA 913 phone: +1 650 786 2921 914 fax: +1 650 786 5896 915 email: erik.nordmark@sun.com 917 Full Copyright Statement 919 Copyright (C) The Internet Society (2003). All Rights Reserved. 921 This document and translations of it may be copied and furnished to 922 others, and derivative works that comment on or otherwise explain it 923 or assist in its implementation may be prepared, copied, published 924 and distributed, in whole or in part, without restriction of any 925 kind, provided that the above copyright notice and this paragraph are 926 included on all such copies and derivative works. However, this 927 document itself may not be modified in any way, such as by removing 928 the copyright notice or references to the Internet Society or other 929 Internet organizations, except as needed for the purpose of 930 developing Internet standards in which case the procedures for 931 copyrights defined in the Internet Standards process must be 932 followed, or as required to translate it into languages other than 933 English. 935 The limited permissions granted above are perpetual and will not be 936 revoked by the Internet Society or its successors or assignees. 938 This document and the information contained herein is provided on an 939 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 940 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 941 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 942 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 943 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Acknowledgement 947 Funding for the RFC Editor function is currently provided by the 948 Internet Society.