idnits 2.17.1 draft-despres-softwire-6rdplus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([6rd]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5041 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Figure 1' is mentioned on line 188, but not defined == Unused Reference: 'ARP' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC3489' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 797, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-03) exists of draft-nakibly-v6ops-tunnel-loops-02 -- Obsolete informational reference (is this intentional?): RFC 5389 (ref. 'STUN') (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Despres 3 Internet-Draft RD-IPtech 4 Intended status: Experimental July 5, 2010 5 Expires: January 6, 2011 7 Rapid Deployment of Native IPv6 Behind IPv4 NATs (6rd+) 8 draft-despres-softwire-6rdplus-00 10 Abstract 12 The [6rd] mechanism permit IPv6 "rapid deployment" across IPv4 13 infrastructures of Internet Service Providers, but only in cases 14 where customer-premise equipments can be upgraded to support it. 6rd+ 15 extends this IPv6 rapid deployment capability to hosts behind 16 customer-premise equipments that cannot be upgraded (provided these 17 hosts can be upgraded themselves to support 6rd+). Like [6rd], 6rd+ 18 provides native IPv6 addresses, so that quality of service can be 19 guaranteed by Internet Service Providers; it operates statelessly, 20 which ensures simplicity and scalability; and it transmits 21 encapsulated IPv6 packets along optimized paths, which contributes to 22 efficiency and acceptability. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 6, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. The 6rd+ Protocol . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Participating Entities and IPv6 Paths . . . . . . . . . . 5 62 3.2. 6rd+C Locator Formats . . . . . . . . . . . . . . . . . . 7 63 3.3. 6rd+ Datagram Formats . . . . . . . . . . . . . . . . . . 9 64 3.4. Mapping Rules of 6rd+Cs and 6rd+Ps . . . . . . . . . . . . 11 65 3.5. Acquisition of 6rd+ parameters by 6rd+Cs . . . . . . . . . 14 66 3.6. Anti-Spoofing and Anti-Routing-Loop Protections . . . . . 16 67 4. Security considerations . . . . . . . . . . . . . . . . . . . 17 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 Although most operating systems now support IPv6, the large installed 78 base of IPv4-only customer-premise equipments (CPEs) acts as a 79 deterrent to IPv6 rapid deployment. Mechanisms such as [Tunnel 80 Broker] and [Teredo] are designed to provide IPv6 connectivity behind 81 such CPEs, but with too severe limitations to be generalized: [Tunnel 82 Broker] necessitates that hosts be individually registered in tunnel- 83 broker servers, and tends to produce unnecessarily long IPv6 paths; 84 [Teredo] does not work with all types of customer-site NATs, and, 85 because it uses IPv6 addresses that start with a Teredo-specific 86 prefix, prevents Internet Service Providers (ISPs) to control the 87 IPv6 quality of service (QoS) experienced by their customers. 89 6rd+ is designed to avoid these limitations: 91 o All types of NATs are supported. 93 o IPv6 addresses obtained behind IPv4-only CPEs are "native" 94 (unicast starting with ISP-allocated prefixes), so that ISPs can 95 control the IPv6 QoS experienced by their customers. 97 o IPv6 paths are optimized. 99 o Hosts don't need to be individually registered in any specific 100 server. 102 The name 6rd+ is derived from that of [6rd], to express that it 103 extends its IPv6 "rapid deployment" to cases not covered so far. 104 Like [6rd], 6rd+ uses IPv6-packet encapsulations and stateless 105 address mappings, but where [6rd] necessitates CPEs to be upgraded, 106 6rd+ does not. The counterpart is that hosts behind non-upgraded 107 CPEs have to support 6rd+ to obtain their native IPv6 connectivity. 108 Their upgrade is expected to be feasible with a downloadable module, 109 at least with Linux for which similar stateless functions have been 110 shown to be downloadable. 112 Other approaches to extend [6rd] to traverse IPv4-only CPEs have been 113 proposed in [6rd UDP] and [SAMPLE], but without optimization of IPv6 114 paths. As this optimization is expected to be important for a wide 115 use of native IPV6, 6rd+ is proposed as a more complete solution. 117 Formats 6rd+ based IPv6 addresses presuppose that the rule of 119 [RFC4291] that IPv6 addresses must contain 64-bit-IIDs is partially 120 relaxed. This relaxation is needed to keep formats of 6rd+ based 121 addresses simple, and does not conflict with the technical rationale 122 for this rule. The 64-bits IID is indeed justified for addresses 123 that, on some link, are subject to the neighbor discovery protocol 124 [ND], but only for these. As 6rd+ addresses that don't have 64-bits 125 IIDs are only assigned to host interfaces on virtual links, where the 126 [ND] protocol is not used, the conflict doesn't exist. (Note that 127 the viability of virtual links having no [ND] has been abundantly 128 validated with [6to4], and that an independent proposal to partially 129 relax the 64-bits-IID rule is available in [IPv6 /127 prefix].) 131 At this stage, the 6rd+ design is so new that some fixes are likely 132 to be needed, in particular after running code has been developed. 133 This is the reason why it is proposed as experimental. But the 134 intent is to progress it to the standard track as soon as possible: 135 the urgency of IPv6 actual use continues to grow. 137 2. Terminology 139 IPv4+: The extended-address family whose addresses have 48 bits, 32 140 of unicast IPv4 addresses plus 16 of a port numbers. 142 Locator: Any routable address or prefix, in a specified address 143 space among IPv4, IPv6, and IPv4+. 145 IPv4+ datagram : An IPv4 datagram that contains a 6rd+ message, or 146 an IPv6 packet in which at least one address has been obtained 147 with 6rd+. The protocol above IPv4 is either UDP or the SAM 148 protocol whose ID has to be assigned by IANA (see Section 3.3. If 149 it is UDP, at least one of the two UDP ports is one of the two 150 6rd+ well-known ports, to be also assigned by IANA. 152 NAT: In this document, only IPv4-to-IPv4 network address 153 translations are considered (NAT44s). They typically translate 154 address plus ports couples, as described in [RFC2663]. 156 EIM, EDM: An EIM NAT is one that does endpoint-independent mappings 157 as specified in [RFC4787] (also known as a "full-cone" NAT). An 158 EDM NAT is one that does endpoint-dependent mappings (the opposite 159 of an EIM NAT). 161 6rd+C, 6rd+P: A 6rd+C is a 6rd+ "customer" function, and a 6rdP is a 162 6rd+ "provider" function. Each one has one lower-layer interface, 163 and two upper-layer interfaces. The lower-layer interface is that 164 of an IPv4 link layer. One of its upper-layer interfaces is a 165 replication of the lower-layer interface? the other is an IPv6 166 pseudo interface (as in [6to4]. Between two 6rd+Cs, or between a 167 6rd+C and a 6rd+P, IPv6 packets are encapsulated in IPv4+ 168 datagrams. 170 6rd+ domain: A network domain delimited by 6rd+Ps and 6rd+Cs of a 171 given ISP. 173 Local, Interior: The "local" address space of a 6rd+C is that 174 available at its lower-layer interface. Its interior address 175 space is that available after traversal of all NATs that may exist 176 between this 6rdC and 6rd+Ps. It is the same for all 6rd+Cs of 177 the domain. (A 6rd+C that has no NAT between itself and 6rd+Ps 178 has identical local an interior address spaces.) 180 Shortcut: An path, between two 6rd+Cs of the same 6rd+ domain, that 181 doesn't go via any domain 6rd+P. 183 3. The 6rd+ Protocol 185 3.1. Participating Entities and IPv6 Paths 187 In a 6rd+ domain, participating entities are the following 188 [Figure 1]: 190 o 6rd+Ps (6rd+ Provider functions) 192 o 6rd+Cs (6rd+ Customer functions) 194 o CPE NATs of two types 196 * EIM CPE NAT (doing endpoint-independent mapping) 198 * EDM CPE NAT (doing endpoint-dependent mapping) 200 o ISP NATs 202 6rd+Ps are stateless. They can be duplicated in any number of nodes. 203 Their interior unicast address is then routed like any other anycast 204 address. 206 6rd+C functions are also stateless. However, if there are NATs 207 between them and 6rd+Ps, their operation depends on states that are 208 maintained in these NATs. In this case, they cannot be duplicated in 209 several nodes. 211 <================= 6rd+ domain =================> 212 local address spaces interior address space 213 IPv6 214 +-----+Private IPv4 +-----+ Public or private IPv4 215 | |------->O------| |------------.----. 216 +-----+ / +-----+ \ \ 217 6rd+C <--' EIM CPE NAT : : 218 : : 219 IPv6 : : 220 +-----+Private IPv4 +-----+ : : 221 | |------->O------| |-----------------. | 222 +-----+ / +-----+ : \: 223 6rd+C <--' EDM CPE NAT ^ : ' IPv6 224 \ : : +-----+ 225 \: : +-----+| 226 O \ | || 227 /: :---->O |---- 228 / : / /| |+ 229 v : : <--' +-----+ 230 possibly : : 6rd+Ps 231 IPv6 other . . 232 +-----+Private IPv4 NATs +-----+ /: /: 233 | |-------- - - - - - ---->O |---'----' : 234 +-----+ /+-----+ : : 235 6rd+C <--' ISP NAT : : 236 : : 237 IPv6 . . 238 +-------+Public or private IPv4 No NAT / / 239 | 6rd+C |--------------------------------'----' 240 +-------+ 242 6rd+ PARTICIPATING ENTITIES AND IPv6 PATHS 244 Figure 1 246 The distinction between EIM and EDM NATs is key, like in [STUN] and 247 in [Teredo], to find some shortcuts that are possible only with EIM 248 NATs. CPE NATs, being in legacy devices of unknown types, may be 249 either EIM or EDM. ISP NATs are assumed to be EIM and to support 250 hairpinning, as specified in [RFC4787]. 252 Paths that can be followed by IPv6 packets are illustrated in 253 Figure 1. Possible shortcuts are the following: 255 Intra-site shortcut: This shortcut concerns two 6rd+Cs that are on 256 the same LAN behind a common CPE NAT (EIM CPE NAT or EDM CPE NAT). 257 IPv6 packets are exchanged via the LAN, without going to the CPE. 259 Intra-ISP shortcut: This shortcut concerns 6rd+Cs that are behind 260 EIM CPE NATs, or ISP NATs, or no NAT. IPv6 packets between them, 261 unless intra-site shortcuts which are shorter are possible, 262 traverse the IPv4 routing infrastructure of the domain without 263 going to any of its 6rd+Ps. 265 ISP-NAT hairpin shortcut: If two 6rd+Cs are behind the same ISP NAT, 266 IPv6 packets they exchange follow an hairpin path whose turning 267 point is in this ISP NAT. 269 3.2. 6rd+C Locator Formats 271 Formats of IPv6 locators that 6rd+Cs obtain depend on the types of 272 NATs that exist between themselves and 6rd+Ps of the domain. Each 273 such IPv6 locator is chosen to contain all addressing information 274 that is needed to reach it via with or without shortcut, and nothing 275 more. The different formats that result from this principle are 276 detailed in Figure 2 (where the dot is used as concatenation 277 operator). 279 The three NAT-type codes, C, C' and C", because they must be 280 distinguishable in a prefix-match search, have to be be disjoint 281 prefixes (no one starting with another). Besides that, they may have 282 different lengths: 284 o NAT-type code C", which is that of 6rd+Cs that have no NAT to 285 traverse, should typically be short so that IPv6 locators E=D.C".X 286 remain within a 64-bits limit. These locators can thus be used as 287 link prefix on ordinary IPv6 links (subject to [ND]). 289 o NAT-type codes C and C', which are those of 6rd+Cs behind NATs, 290 appear in IPv6 locators E=D.C.X.Z, E=D.C.X.Z.Y, and E=D.C'.X.Z.Y, 291 which contain too much information to have a chance to fit in 64- 292 bits. In order to limit the amount of ISP IPv6 address space 293 devoted to 6rd+, C and C' may therefore be chosen significantly 294 longer than C". These locators, which are too long to be used as 295 link prefixes on ordinary IPv6 links, can be used to obtain 296 native-IPv6 host addresses (duly completed with trailing 0s if 297 needed to reach 128 bits). Other possible uses of these locators 298 are beyond the scope of this draft. 300 E=D.C.X.Z.Y A=Q.Y +-----+ 301 +-------+ L=A:W | EIM | N=P.X 302 | 6rd+C |----->O-------| CPE |------------.----. 303 +-------+ / | NAT | \ \ 304 <--' +-----+ : : 305 L<->I=P.X:Z : : 306 : : 307 E=D.C'.X.Z.Y A=Q.Y +-----+ : : 308 +-------+ L=A:W | EDM | N=P.X : : 309 | 6rd+C |----->O-------| CPE |-----------------. | 310 +-------+ / | NAT | : \: 311 <--' +-----+ ^ : ' 312 L<->I=N:Z | : : B.W +-----+ 313 \ : \ B'.W'|6rd+P| D 314 :--O :-----|-->O-|---- 315 / : / | | 316 | : : +-----+ 317 v : : 6rd+P PARAMETERS: 318 E=D.C.X.Z A possibly +-----+ . . D,P,C,C',C" 319 +-------+ L=A:W other NATs | ISP | /: /: ISP-NAT locators 320 | 6rd+C |-------- - - - - - --->|O----|---'----' : 321 +-------+ L<->x /| NAT | : : 322 / +-----+ : : 323 <--' x<->I=P.X:Z : : 324 : : 325 E=D.C".X A=P.X . . 326 +-------+ L=A:W No NAT / / 327 | 6rd+C |---------------------------------'----' 328 +-------+ I=L 330 E : 6rd+C IPv6 locator 331 D : ISP prefix assigned to 6rd+ 332 C,C',C" : NAT-type code (resp. EIN or ISP, EDM, NoNAT) 333 X : complement of P in N 334 Z : complement to N in I (port number) 335 Y : complement to Q in L 336 A : 6rd+C local IPv4 address (= Q.Y) 337 W,W' : 6rd+ well-known UDP ports (to be assigned by IANA) 338 Q : prefix of RFC 1918 in A (10/8, 172.16/12, or 192.168/16) 339 L : 6rd+C local locator (= A.W) 340 I : 6rd+C interior locator (IPv4+) 341 N : IPv4 part of the interior locator I 342 P : common prefix of the interior address space (possibly /0) 343 B,B' : 6rd+ well-known IPv4 public addresses (to be assigned by IANA) 345 6RD+ LOCATOR FORMATS 347 Figure 2 349 3.3. 6rd+ Datagram Formats 351 6rd+Cs and 6rd+Ps encapsulate IPv6 packets they have to forward 352 across their 6rd+ domain. For this they have to derive the interior 353 destination address of each encapsulating packet from addresses 354 contained in the IPv6 packet it encapsulates. If this interior 355 destination has 32bits, encapsulation is in an IPv4 datagram, with 356 the protocol field set to 41 (IP in IP). If it has 48 bits, 357 encapsulation is in a UDP datagram. Its destination port is copied 358 from the last 16 bits of the interior destination, and its source 359 port is the 6rd+ well-known prefix W. Formats of IPv4+ datagrams are 360 shown on Figure 3 and Figure 4. 362 0 1 2 3 363 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 2 364 +=======+=======================================================+---- 365 |Vrsn=4 | | 366 +-------+ + 367 | | 368 + +---------------+ + 369 | | Prot.=17 (UDP)| |IPv4 370 +---------------+---------------+-------------------------------+ 371 | IPv4 Source Address | 372 +---------------------------------------------------------------+ 373 | IPv4 Destination Address | 374 +=======+=======================+===============================+---- 375 | Source Port (*) | Destination port (*) | 376 +-------------------------------+-------------------------------| UDP 377 | | 378 +===============================================================+---- 379 . . 380 . IPv6 packet OR 6rd+ message . 381 . . 382 + + ---------------------------------------+ 383 | | 384 +=========//===========+ 386 (*) At least one of the two ports is one of the two 387 6rd+ well-known prefixes W and W'. 389 FORMATS OF 6RD+ DATAGRAMS FOR IPV4+ INTERIOR DESTINATIONS 391 Figure 3 393 +=======+=======================================================+---- 394 |Vrsn=4 | | 395 +-------+ + 396 | | 397 + +---------------+ + 398 | |Prot=41 (IP/IP)| |IPv4 399 +---------------+---------------+-------------------------------+ 400 | IPv4 Source Address | 401 +---------------------------------------------------------------+ 402 | IPv4 Destination Address | 403 +===============================================================+---- 404 . . 405 . IPv6 packet . 406 . . 407 + + ---------------------------------------+ 408 | | 409 +=========//===========+ 411 +=======+=======================================================+---- 412 |Vrsn=4 | | 413 +-------+ + 414 | | 415 + +---------------+ + 416 | |Prot=SAM (TBD)| |IPv4 417 +---------------+---------------+-------------------------------+ 418 | IPv4 Source Address | 419 +---------------------------------------------------------------+ 420 | IPv4 Destination Address | 421 +===============================================================+---- 422 . . 423 . 6rd+ message . 424 . . 425 + + ---------------------------------------+ 426 | | 427 +=========//===========+ 429 FORMATS OF 6RD+ DATAGRAMS FOR IPV4 INTERIOR DESTINATIONS 431 Figure 4 433 Recommendations of [RFC4213] that concern these encapsulations have 434 to be followed. 436 Since IPv6 packets are encapsulated in IPv4 datagrams which may be 437 fragmented on their way, a large IPv6 packet can in general be 438 encapsulated in a single IPv4 datagram, independently of path MTUs of 439 the traversed domain. However, reassembly of multi-fragment 440 datagrams tends to consume processing power and can bring some 441 buffer-size problems. It is therefore advisable to limit the size of 442 accepted IPv6 packets (and to return ICMPv6 packet-too-big error 443 messages when received IPv6 packets are too big to be forwarded). 444 Forwarding only IPv6 packets that don't exceed the 1280 octets, the 445 size that [RFC2460] requests every link to support, is the choice 446 that minimizes the risk of such reassembly problems. Yet, accepting 447 somewhat larger sizes may be preferred to obtain a different trade- 448 off between reassembly avoidance and accepted IPv6 packet sizes. 450 The protocol ID to be used for 6rd+ messages exchanged directly in 451 IPv4 datagrams is that of the more general [SAM] protocol, of which 452 the 6rd+ protocol is a subset. 454 3.4. Mapping Rules of 6rd+Cs and 6rd+Ps 456 Mapping rules that, in 6rd+Cs, determine interior destinations iDSTs 457 are detailed in Table 1. For each NAT type, the listed rules have to 458 be tested in the indicated order, until one is found to apply. If 459 none applies, the IPv6 packet is invalid, and silently discarded. 461 The logic of these mapping rules directly results from shortcuts that 462 have to be supported, and from IPv6 locator formats of Section 3.2. 464 In Table 1: 466 o Lower-case letters represent lengths of fields whose symbols are 467 upper-case letters (e.g. d is the number of bits of D). 469 o Column 1 indicates the NAT type of the 6rd+C (EIM CPE NAT, EDM CPE 470 NAT, ISP NAT, No NAT). 472 o In column 2, a prefix indicates that the rule applies only if the 473 IPv6 destination address eDST starts with this prefix. 475 o In column 3, a number of bits n indicates that the rule applies 476 only if both the IPv6 destination address and the 6rd+C IPv6 477 locator start with the same n bits. 479 o In column 4, a prefix indicates that the rule applies if the IPv6 480 source address eSRC starts with this prefix. A rule has contents 481 in one and only one of the first three columns. 483 o In column 5, a prefix indicates that, if the rule applies, this 484 prefix has to be included the interior destination iDST. 486 o In column 6, a number of bits n indicates that, if the rule 487 applies, n bits in the IPv6 destination address eDST have to be 488 skipped, after those that may have already been matched if any. 490 +------+------+-------------+-------+------+-------+---------+------+ 491 | -1- | -2- | -3- | - 4 - | -5- | -6- | -7- | -8- | 492 | ---- | ---- | --------- | ---- | ---- | ---- | ----- | ---- | 493 | NAT | eDST | length of | eSRC | iDST | Skip | Add to | iDST | 494 | Tpe | prfx | common | prfx | prfx | in | iDST | sffx | 495 | | | prefix of | | | eDST | from | | 496 | | | eDST & | | | | eDST | | 497 | | | IPv6-lctr | | | | | | 498 +------+------+-------------+-------+------+-------+---------+------+ 499 | EIM | | d+c+32-p | | Q | 16 | 32-q | | 500 | CPE | | | | | | | | 501 | NAT | | | | | | | | 502 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 503 | " | D.C | | | P | | 48-p | | 504 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 505 | " | D.C" | | | P | | 32-p | W | 506 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 507 | " | | | D | B:W | | | | 508 | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | 509 | EDM | | d+c'+32-p | | Q | 16 | 32-q | | 510 | CPE | | | | | | | | 511 | NAT | | | | | | | | 512 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 513 | " | | | D | B:W | | | | 514 | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | 515 | ISP | D.C | | | P | | 48-p | | 516 | NAT | | | | | | | | 517 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 518 | " | D.C" | | | P | | 32-p | W | 519 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 520 | " | | | D | B:W | | | | 521 | ==== | ==== | ========= | ==== | ==== | ==== | ==== | ==== | 522 | No | D.C | | | P | | 48-p | | 523 | NAT | | | | | | | | 524 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 525 | " | D.C" | | | P | | 32-p | W | 526 | ---- | ---- | --------- | ---- | ---- | ---- | ---- | ---- | 527 | " | | | D | B | | | | 528 +------+------+-------------+-------+------+-------+---------+------+ 530 6rd+C MAPPING RULES 532 Table 1 534 o In column 7, a number of bits n indicates that, if the rule 535 applies, n bits of the IPv6 destination eDST, after those that may 536 have already been matched and/or skipped, have to be included in 537 the interior destination iDST, after any bits it may have already 538 been included. 540 o A column-8 square may contain a suffix. If the rule applies, it 541 is included in the interior destination iDST, after any bits it 542 may already contain. 544 6rd+P mapping rules are straightforward, as no possible shortcuts 545 have to be considered. Using the same notation as in Table 1, they 546 are detailed in Table 2 (without any implication on how they can be 547 implemented). 549 As shown, packets exchanged between 6rd+Ps and 6rd+cs of the "No NAT" 550 type are encapsulated in UDP/IP rather than directly in IPv4 as it 551 would have been possible. This adds a little overhead to these 552 packets, but has two advantages: hairpinning in 6rd+Ps for 6rd+Cs of 553 the "No NAT" that exchange packets with 6rd+Cs of the EDM CPE NAT" 554 type is facilitated, as received and transmitted datagram headers 555 have the same length; routing loops with other tunneling mechanisms 556 such as [6to4], [6rd], and [ISATAP], are made impossible (these three 557 mechanisms encapsulate IPv6 in IPv4 while 6rd+Ps only encapsulate 558 IPv6 in IPv4+ (see also Section 3.6. 560 +----------------------+---------------------+----------------------+ 561 | eDST prefix | iDST prefix | Add to iDST from | 562 | | | eDST | 563 +----------------------+---------------------+----------------------+ 564 | d+c | P | 48-p | 565 | -------------------- | ------------------- | -------------------- | 566 | d+c' | P | 48-p | 567 | -------------------- | ------------------- | -------------------- | 568 | d+c" | P | 48-p | 569 +----------------------+---------------------+----------------------+ 571 6rd+P MAPPING RULES 573 Table 2 575 3.5. Acquisition of 6rd+ parameters by 6rd+Cs 577 This 6rd+ protocol is a particular instance of the more general 578 "stateless address mapping" protocol proposed in [SAM], where the 579 exterior address family is IPv6 and the interior address family is 580 IPv4+. Rules of the 6rd+ protocol, partially illustrated in 581 Figure 5, are the following: 583 R1: If a 6rd+C that has an IPv4 address but no IPv6 address or 584 prefix, it tries to obtain its parameters from a 6rd+P (its IPv6 585 locator an its mapping rules). For this, it sends two SAM 586 messages containing a "Parameter Request" indication. The first 587 one is sent to IPv4 address B. The second one is sent IPv4+ 588 address B:W, with the local IPv4 address A as parameter. These 589 two requests are also retransmitted from time to time to check 590 whether newly received answers differ from previous ones, and 591 for the second one to maintain mappings in all NATs that may 592 exist between the 6rd+C and 6rd+Ps. 594 6rd+C 6rd+P 595 v ----- ----- 596 : 597 :\ A -> B SamMsg("ParamReq") A -> B 598 : '->------------------------>--------------- - ??? - -------->-. 599 : \ 600 : : 601 : A <- B SamMsg(ParamSetforNoNat) A <- B / 602 : <------------------------<--------------------------------<-' 603 : 604 \ A.W -> B.W SamMsg("ParamReq", A) I -> B.W 605 '->------------------------<-------------------------------->-. 606 \ 607 if I belongs : 608 to an ISP NAT : 609 A.W <- B.W SamMsg(ParamSetForIspNat) I <- B.W /: 610 <------------------------->-------------------------------<-' : 611 : 612 otherwise : 613 : 614 A.W <- B.W SamMsg(ParamSetForEdm) I <- B.W : 615 <------------------------->-------------------------------<-. : 616 \. 617 A.W <- B':W' SamMsg(ParamSetForEim) I <- B'.W' / 618 <------- - ??? - ---------<-------------------------------<-' 619 6rd+ PROTOCOL 621 Figure 5 623 R2: If a 6rd+P receives a SAM message at its IPv4 address B without 624 a UDP header, it knows that this message crossed no NAT on its 625 way. If the message contains a parameter request, it returns a 626 SAM message containing parameters suitable for this 6rd+C, known 627 to be of the "No NAT" type. 629 R3: If a 6rd+P receives a SAM message at its IPv4+ address B:W, it 630 first tests whether its IPv4 source address starts with the IPv4 631 prefix of one ISP NATs of the domain. if yes, it returns an 632 answer containing parameters suitable for this 6rd+C, known to 633 be of the "ISP-NAT" type. Otherwise, it returns two answers. 634 The first answer is sent from the B:W IPv4+ address so that it 635 can reach its destination with on its way NATs of any types. It 636 contains parameters suitable for this 6rd+C if it is of "EDM CPE 637 NAT" type. The second answer is sent from the B':W' IPv4+ 638 address so that it can reach its destination only if either 639 there is no NAT on its way, or if the first traversed NAT is 640 EIM. It contains parameters suitable for this 6rd+C if it is of 641 the "EIM CPE NAT' type. 643 R4: If a 6rd+C receives an answer, it first checks that its source 644 address is valid (is B, B:W, or B':W'). If the received 645 parameters are better than those of its current parameter set or 646 if it has no current parameter set, it takes them as the new 647 current parameter set. The decreasing order of best parameter 648 sets is: (1) received from B (No NAT); (2) received from B':W' 649 (EIM CPE NAT or ISP NAT); (3) received from B:W (EDM CPE NAT). 650 If the received parameter set is less good as the current one, 651 but has a lifetime longer than the the remaining lifetime of the 652 current one, it should be memorized to possibly become current 653 one if the current one becomes obsolete. 655 R5: If a 6rd+C receives at its IPv4 address Q.Y a 6rd+ datagram 656 without UDP header, in which the IPv6 destination doesn't match 657 its IPv6 locator D.X.Z.Y, it infers that an intra-site shortcut 658 must have been attempted which cannot be taken. This may happen 659 in the very specific case where: there is at least one NAT, 660 internal to the site, between the source 6rd+C and the intended- 661 destination 6rd+C; there is no NAT between the source 6rd+C and 662 the receiving 6rd+C; the receiving 6rd+C has the same private 663 IPv4 local address as the intended-destination 6rd+C. A SAM 664 message is then returned to the IPv4 address of the source 6rd+C 665 with a "SAM unreachability" indication, and the receiving 6rd+C 666 disables its intra-site-shortcut mapping rule if it still has 667 one (a rule leading to a 32-bits iDST). 669 R6: If a 6rd+C receives at its IPv4 address a SAM message containing 670 a "SAM unreachability" indication, it disables its intra-site- 671 shortcut mapping rule if it has one. With this rule ad the 672 previous one, IPv6 connectivity between 6rd+C IPv6 locators is 673 always ensured even in complex intra-site configuration with 674 internal NATs, with IPv6 packets having in this case to go via 675 the CPE. 677 Detailed formats of SAM messages used for 6rd+ are beyond the scope 678 of this document. They should be specified in the wider context of 679 [SAM]. 681 3.6. Anti-Spoofing and Anti-Routing-Loop Protections 683 Anti-spoofing protection can be ensured by applying the general 684 ingress-filtering principle: a packet received at an interface is 685 valid only if the same packet with inverses source and destination 686 may be transmitted at that same interface: 688 o An IPv6 packet received by a 6rd+C or by a 6rd+P in an IPv4+ 689 datagram must be silently discarded if the source address of the 690 datagram (IPv4 or IPv4+) is not that which mapping rules obtain as 691 iDST if applied to a an IPv6 destination eDST equal to the IPv6 692 source address of the datagram. 694 o Routing-loop protection is necessary if an ISP operates two point- 695 to-multipoint tunneling mechanisms on the same domain with the 696 same exterior and interior address families. (Example with 697 [ISATAP] and [6to4] are analyzed in [RoutingLoops].) 699 o As long as 6rd+ as specified here is the only point-to-multipoint 700 tunneling mechanism used with IPv6 as exterior address space and 701 IPv4+ as interior address space, no particular protection against 702 routing loops is needed for IPv4+ tunnels. 704 4. Security considerations 706 With precautions taken in previous sections, no new security issue 707 has been identified so far. More work on this specification is 708 however desirable to improve confidence in this respect. 710 5. IANA Considerations 712 For plug-and-play operation of 6rd+, the following assignments have 713 to be made by IANA: 715 o The two well-known IPv4 addresses B and B' and the two well-known 716 UDP ports W and W' of Section 3.2; 718 o The SAM protocol ID of Section 3.3 (to be shared with [SAM] 720 6. Acknowledgments 722 A very early version of this proposal has been informally submitted 723 to a number of delegates at IETF 77. Thanks are due to Dan Wing and 724 Pascal Thubert for their encouragements to pursue in this direction, 725 and also to Brian Carpenter for his strong support that the objective 726 of 6rd+: native IPv6 across legacy CPEs. 728 7. References 730 7.1. Normative References 732 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 733 (IPv6) Specification", RFC 2460, December 1998. 735 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 736 for IPv6 Hosts and Routers", RFC 4213, October 2005. 738 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 739 Architecture", RFC 4291, February 2006. 741 7.2. Informative References 743 [6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider 744 Networks - draft-ietf-softwire-ipv6-6rd-10", 745 February 2010. 747 [6rd UDP] Lee, Y. and P. Kapoor, "UDP Encapsulation of 6rd - 748 draft-lee-softwire-6rd-udp-01", May 2010. 750 [6to4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 751 via IPv4 Clouds", February 2001. 753 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol -- 754 or -- Converting Network Protocol Addresses 755 to 48.bit Ethernet Address for Transmission on Ethernet 756 Hardware", RFC 826, November 1992. 758 [IPv6 /127 prefix] 759 Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L. 760 Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router 761 Links - draft-kohno-ipv6-prefixlen-p2p-01", March 2010. 763 [ISATAP] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 764 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 765 March 2008. 767 [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 768 Discovery for IP Version 6 (IPv6)", RFC 2461, 769 December 1998. 771 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 772 E. Lear, "Address Allocation for Private Internets", 773 BCP 5, RFC 1918, February 1996. 775 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 776 Translator (NAT) Terminology and Considerations", 777 RFC 2663, August 1999. 779 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 780 Tunnel Broker", RFC 3053, January 2001. 782 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 783 "STUN - Simple Traversal of User Datagram Protocol (UDP) 784 Through Network Address Translators (NATs)", RFC 3489, 785 March 2003. 787 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 788 Networks", BCP 84, RFC 3704, March 2004. 790 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 791 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 792 RFC 4787, January 2007. 794 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 795 Framework", RFC 5565, June 2009. 797 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 798 infrastructures (6rd)", January 2010. 800 [RoutingLoops] 801 Nakibly, G. and F. Templin, "Routing Loop Attack using 802 IPv6 Automatic Tunnels: Problem Statement and Proposed 803 Mitigations - draft-nakibly-v6ops-tunnel-loops-02", 804 May 2010. 806 [SAM] Despres, R., "Stateless Address Mapping (SAM) for 807 Softwire-Lite Solutions (NOTE: only the revised 808 draft-despres-softwire-sam-01 will be consistent with this 809 draft. It should be posted before the deadline for IETF 810 78)", July 2010. 812 [SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for 813 IPv6: Simple Address Mapping for Premises - Legacy 814 Equipment (SAMPLE) - draft-carpenter-softwire-sample-00", 815 June 2010. 817 [STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 818 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 819 October 2008. 821 [Teredo] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 822 Network Address Translations (NATs)", RFC 4380, 823 February 2006. 825 [Tunnel Broker] 826 Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 827 Tunnel Broker", RFC 3053, January 2001. 829 Author's Address 831 Remi Despres 832 RD-IPtech 833 3 rue du President Wilson 834 Levallois, 835 France 837 Email: remi.despres@free.fr