idnits 2.17.1 draft-ietf-softwire-4rd-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 23 characters in excess of 72. ** The abstract seems to contain references ([RFC6145]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 16, 2012) is 4362 days in the past. Is this intentional? 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: 'PSID' is mentioned on line 1460, but not defined == Unused Reference: 'RFC2003' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 1290, but no explicit reference was found in the text == Unused Reference: 'RFC6147' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'RFC6219' is defined on line 1325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-19 == Outdated reference: A later version (-05) exists of draft-ietf-softwire-stateless-4v6-motivation-00 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-04 -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Despres, Ed. 3 Internet-Draft RD-IPtech 4 Expires: November 17, 2012 R. Penno 5 Cisco Systems, Inc. 6 Y. Lee 7 Comcast 8 G. Chen 9 China Mobile 10 S. Jiang 11 Huawei Technologies Co., Ltd 12 May 16, 2012 14 IPv4 Residual Deployment via IPv6 - a unified Stateless Solution (4rd) 15 draft-ietf-softwire-4rd-00 17 Abstract 19 The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment 20 possible via IPv6 networks without maintaining for this per-customer 21 states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 22 6rd). To cope with the IPv4 address shortage, customers can be 23 assigned IPv4 addresses with restricted port sets. In some 24 scenarios, 4rd-capable customer nodes can exchange packets of their 25 IPv4-only applications via stateful NAT64s that are upgraded to 26 support 4rd tunnels (in addition to their IP/ICMP translation of 27 [RFC6145]). 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 17, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. The 4rd Model . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Mapping rules and other Domain parameters . . . . . . . . 7 68 4.2. Reversible Packet Translations at Domain entries and 69 exits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. From CE IPv6 Prefixes to 4rd IPv4 prefixes . . . . . . . . 13 71 4.4. From 4rd IPv4 addresses to 4rd IPv6 Addresses . . . . . . 15 72 4.5. Fragmentation Considerations . . . . . . . . . . . . . . . 19 73 4.5.1. Fragmentation at Domain Entry . . . . . . . . . . . . 19 74 4.5.2. Ports of Fragments addressed to Shared-Address CEs . . 20 75 4.5.3. Packet Identifications from Shared-Address CEs . . . . 21 76 4.6. TOS and Traffic-Class Considerations . . . . . . . . . . . 22 77 4.7. Tunnel-Generated ICMPv6 Error Messages . . . . . . . . . . 22 78 4.8. Provisioning 4rd Parameters to CEs . . . . . . . . . . . . 23 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 81 7. Relationship with Previous Works . . . . . . . . . . . . . . . 26 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 86 Appendix A. Textual representation of Mapping rules . . . . . . . 32 87 Appendix B. Configuring multiple Mapping Rules . . . . . . . . . 33 88 Appendix C. ADDING SHARED IPv4 ADDRESSES TO AN IPv6 NETWORK . . . 35 89 C.1. With CEs within CPEs . . . . . . . . . . . . . . . . . . . 35 90 C.2. With some CEs behind Third-party Router CPEs . . . . . . . 36 91 Appendix D. REPLACING DUAL-STACK ROUTING BY IPv6-ONLY ROUTING . . 38 92 Appendix E. ADDING IPv6 AND 4rd SERVICE TO A NET-10 NETWORK . . . 39 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 95 1. Introduction 97 For deployments of residual IPv4 service via IPv6 networks, the need 98 for a stateless solution, i.e. one where no per-customer state is 99 needed in IPv4-IPv6 gateway nodes of the provider, is expressed in 100 [I-D.ietf-softwire-stateless-4v6-motivation] . This document 101 specifies such a solution, named "4rd" for IPv4 Residual Deployment. 102 With it, IPv4 packets are transparently tunneled across IPv6 networks 103 (reverse of 6rd [RFC5969] in which IPv6 packets are statelessly 104 tunneled across IPv4 networks). While IPv6 headers are too long to 105 be mapped into IPv4 headers, so that 6rd requires encapsulation of 106 full IPv6 packets in IPv4 packets, IPv4 headers can be reversibly 107 translated into IPv6 headers in such a way that, during IPv6 domain 108 traversal, tunneled TCP and UDP packets are valid IPv6 packets. 109 Thus, IPv6-only middle boxes that perform deep-packet-inspection can 110 operate on them. 112 In order to deal with the IPv4-address shortage, customers can be 113 assigned shared IPv4 addresses, with statically assigned restricted 114 port sets. As such, it is a particular application of the A+P 115 approach of [RFC6346]. 117 The design of 4rd builds on a number of previous proposals made for 118 IPv4-via-IPv6 transition technologies listed in Section 8. 120 In some use cases, IPv4-only applications of 4rd-capable customer 121 nodes can also work with stateful NAT64s of [RFC6146], provided these 122 are upgraded to support 4rd tunnels in addition their IP/ICMP 123 translation of [RFC6145]. The advantage is then a more complete IPv4 124 transparency than with double translation. 126 Terminology is defined in Section 2. How the 4rd model fits in the 127 Internet architecture is summarized in Section 3. The protocol 128 specification is detailed in Section 4. Section 5 and Section 6 129 respectively deal with security and IANA considerations. Previous 130 proposals that influenced this specification are listed in Section 8. 131 A few typical 4rd use cases are presented in Appendices. 133 The key words "MUST", "SHOULD", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Terminology 138 ISP: Internet-Service Provider. In this document, the service it 139 offers can be DSL, fiber-optics, cable, or mobile. The ISP can 140 also be a private-network operator. 142 4rd (IPv4 Residual Deployment): An extension of the IPv4 service 143 where public-IPv4 addresses can be statically shared with 144 restricted port sets assigned to customers. 146 4rd domain (or Domain): An ISP-operated IPv6 network across which 147 4rd is supported according to the present specification. 149 Tunnel packet: An IPv6 packet that transparently conveys an IPv4 150 packet across a 4rd domain. Its header has enough information 151 to reconstitute the IPv4 header at Domain exit. Its payload is 152 the original IPv4 payload. 154 CE (Customer Edge): A customer-side tunnel endpoint. It can be in a 155 node that is a host, a router, or both. 157 BR (Border Relay): An ISP-side tunnel-endpoint. Because its 158 operation is stateless (neither per CE nor per session state) it 159 can be replicated in as many nodes as needed for scalability. 161 4rd IPv6 address: IPv6 address used as destination of a Tunnel 162 packet sent to a CE or a BR. 164 NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd 165 tunneling when IPv6 addresses it deals with are 4rd IPv6 166 addresses. 168 4rd IPv4 address: A public IPv4 address or, in case of a shared IPv4 169 address, a public transport address (public IPv4 address plus 170 port number). 172 PSID (Port-Set Identifier): A flexible-length field that 173 algorithmically identifies a port set. 175 4rd IPv4 prefix: A flexible-length prefix that may be a a public 176 IPv4 prefix, a public IPv4 address, or a public IPv4 address 177 followed by a PSID. 179 Mapping rule: A set of parameters that BRs and CEs use to derive 4rd 180 IPv6 addresses from 4rd IPv4 addresses. Mapping rules are also 181 used by each CE to derive a 4rd IPv4 prefix from an IPv6 prefix 182 it has been delegated. 184 EA bits (Embedded Address bits): Bits that are the same in a 4rd 185 IPv4 address and in the 4rd IPv6 address derived from it. 187 BR mapping rule: The mapping rule applicable to off-domain IPv4 188 addresses reachable via BRs. It can also apply to some or all 189 of CE-assigned IPv4 addresses. 191 CE mapping rule: A mapping rule that is applicable only to CE- 192 assigned public IPv4 addresses (shared or not). 194 NAT64+ mapping rule: The mapping rule applicable to IPv4 addresses 195 reachable via the NAT64+ (if there is one). 197 CNP (Checksum Neutrality preserver): A field of 4rd IPv6 addresses 198 that ensures that TCP-like checksums do not change when IPv4 199 addresses are replaced by 4rd IPv6 addresses. 201 V octet: An octet whose value permits, within 4rd domains, to 202 distinguish 4rd IPv6 addresses from other IPv6 addresses. 204 3. The 4rd Model 206 4rd DOMAIN 207 +-----------------------------+ 208 | IPv6 routing | 209 | Enforced ingress filtering | +---------- 210 ... | | | 211 | +------+ 212 Customer site | IPv6 prefix --> |BR(s) | IPv4 213 +------------+ | |and/or| Internet 214 | dual-stack | | IPv6 prefix --> |N4T64+| 215 | +--+ | +------+ 216 | |CE+-+ <-- IPv6 prefix | | 217 | +--+ | | +---------- 218 | | | | 219 +------------+ | <--IPv4 tunnels--> +------------ 220 | (Mesh or hub-and-spoke | 221 ... | topologies) | IPv6 222 | | Internet 223 | | 224 | +------------ 225 +-----------------------------+ 226 <== one or several Mapping rules 227 (e.g. announced to CEs in stateless DHCPv6 ) 229 Figure 1 231 How the 4rd model fits in the Internet architecture is represented in 232 Figure 1. 234 IPv4 packets are kept unchanged by Domain traversal except that: 236 o The IPv4 Time to live (TTL), unless it is 1 or 255 at Domain 237 entry, decreases during Domain traversal by the number of 238 traversed routers. This is acceptable because it is undetectable 239 end to end, and because TTL values that can be used with some 240 protocols to test adjacency of communicating routers are preserved 241 ([RFC4271], [RFC5082] ). 243 o IPv4 packets whose lengths are =< 68 octets always have their 244 Don't fragment flags DF=1 at Domain exit even if they had DF=0 at 245 Domain entry. This is acceptable because these packets are too 246 short to be fragmented [RFC0791] so that their DF bits have no 247 meaning. Besides, both [RFC1191] and [RFC4271] recommend that 248 sources always set DF=1. 250 o Unless the Tunnel-traffic-class option applies to a Domain 251 (Section 4.1), IPv4 packets may an have explicit congestion 252 notifications added to their TOS fields after Domain traversal 253 (ECN of [RFC3168]). This is normal ECN functionality, and can be 254 disabled by ISPs if they so desire. 256 One or several Mapping rules are announced to CEs so that each one 257 can derive its assigned 4rd IPv4 prefix from its delegated IPv6 258 prefix, or from one of them if there are several. If none is 259 derived, but the Domain has a NAT64+, a 4rd tunnel can be used 260 between the CE and the NAT64+. 262 R-1: A node whose CE is assigned a shared IPv4 address MUST include 263 a NAT44 [RFC1631]. This NAT44 MUST only use external ports 264 that are in the CE assigned port set. 266 NOTE: This specification only concerns IPv4 communication between 267 IPv4-capable endpoints. For communication between IPv4-only 268 endpoints and IPv6 only remote endpoints, the BIH specification of 269 [RFC6535] can be used. It can coexist in a node with the CE 270 function, including if the IPv4-only function is a NAT44 [RFC1631]. 272 4. Protocol Specification 274 4.1. Mapping rules and other Domain parameters 276 R-2: CEs and BRs MUST be configured with the following Domain 277 parameters: 279 A. One or several Mapping rules, each one comprising: 281 1. Rule IPv4 prefix 283 2. EA-bits length 285 3. Rule IPv6 prefix 287 4. WKPs authorized (OPTIONAL) 289 5. Rule IPv6 suffix (OPTIONAL) 291 B. Domain PMTU 293 C. Hub&spoke topology (Yes or No) 295 D. Tunnel traffic class (OPTIONAL) 297 "Rule IPv4 prefix" is used to find, by a longest match, which Mapping 298 rule applies to a 4rd IPv4 address (Section 4.4). A Mapping rule 299 whose Rule IPv4 prefix is longer than /0 is a CE mapping rule. BR 300 and NAT64+ mapping rules, which must apply to all off-domain IPv4 301 addresses, have /0 as their Rule IPv4 prefixes. 303 "EA-bits length" is the number of bits that are common to 4rd IPv4 304 addresses and 4rd IPv6 addresses derived from them. In a CE mapping 305 rule, it is also the number of bits that are common to a CE delegated 306 IPv6 prefix and the 4rd IPv4 prefix derived from it. BR and NAT64+ 307 mapping rules have EA-bits lengths equal to 32. 309 "Rule IPv6 prefix" is the prefix that is substituted to the Rule IPv4 310 prefix when a 4rd IPv6 address is derived from a 4rd IPv4 address 311 (Section 4.4). In a BR mapping rule, it MUST be a /80 whose 9th 312 octet is the V octet. In a NAT64+ mapping rule it MUST be a /80 313 whose 9th octet is the "u" octet of [RFC6052]. 315 "WKPs authorized" may be set for mapping rules that assign shared 316 IPv4 addresses to CEs. (These rules are those whose length of the 317 Rule IPv4 prefix plus the EA-bits length exceeds 32.) If set, well- 318 known ports may be assigned to some CEs having particular IPv6 319 prefixes. If not set, fairness is privileged: all IPv6 prefixes 320 concerned with the Mapping rule have ports sets having identical 321 values (no port set includes any of the well known ports). 323 "Rule IPv6 suffix", if provided, is a field to be added after EA bits 324 of a 4rd IPv6 address after its EA bits. It is only used in Domains 325 where CEs can be placed in customer sites behind third-party CPEs, 326 and where these CPEs use some address bits to route packets among 327 their physical ports. A use case where it applies is presented in 328 Appendix C.2. 330 "Domain PMTU" is the IPv6 path MTU that the ISP can guarantee for all 331 its IPv6 paths between CEs and between BRs and CEs. It MUST be at 332 least 1280 [RFC2460]. 334 "Hub&spoke topology", if set to Yes, requires CEs to tunnel all IPv4 335 packets via BRs. If set to No, CE-to-CE packets take the same routes 336 as native IPv6 packets between the same CEs (mesh topology). 338 "Tunnel traffic class", if provided, is the IPv6 traffic class that 339 BRs and CEs MUST set in Tunnel packets. In this case, explicit 340 congestion notifications (ECNs of [RFC3168]) that may have been be 341 set in IPv6 during Domain traversal are not propagated to IPv4 342 packets that leave the Domain. 344 4.2. Reversible Packet Translations at Domain entries and exits 346 R-3: Domain-entry nodes that receive IPv4 packets with IPv4 options 347 MUST discard these packets, and return ICMPv4 error messages to 348 signal IPv4-option incompatibility (Type = 12, Code = 0, 349 Pointer = 20) [RFC0792]. This limitation is acceptable because 350 no IPv4 option is necessary for end-to-end IPv4 operation. 352 R-4: Domain-entry nodes that receive IPv4 packets without IPv4 353 options MUST convert them to Tunnel packets, with or without 354 IPv6 fragment headers depending on what is needed to ensure 355 IPv4 transparency (Figure 2). Domain-exit nodes MUST convert 356 them back to IPv4 packets. 358 An IPv6 fragmentation header MUST be included at tunnel entry 359 (Figure 2) if, and only if, one or several of the following 360 conditions hold: 362 * The Tunnel_traffic_class option applies to the Domain. 364 * TTL = 1 OR TTL = 255. 366 * The IPv4 packet is already fragmented, or may be fragmented 367 later on, i.e. if MF=1 OR Offset>0 OR (Total length > 68 AND 368 DF=0). 370 In order to optimize cases where fragmentation headers are 371 unnecessary, the NAT44 of a CE that has one SHOULD send packets 372 with TTL = 254. 374 R-5: In Domains whose chosen topology is Hub&spoke, BRs that receive 375 IPv6 packets whose destination IPv4 addresses match a CE 376 mapping rule MUST do the equivalent of reversibly translating 377 their headers to IPv4 and then reversibly translate them back 378 to IPv6 as though packets would be entering the Domain. 380 (A) Without IPv6 fragment header 381 IPv4 packet Tunnel packet 382 +--------------------+ : : +--------------------+ 383 20| IPv4 Header | : <==> : | IPv6 Header | 40 384 +--------------------+ : : +--------------------+ 385 | IP Payload | <==> | IP Payload | 386 | | layer 4 | | 387 +--------------------+ unchanged +--------------------+ 389 (B) With IPv6 fragment header 390 Tunnel packet 391 : +--------------------+ 392 IPv4 packet : | IPv6 Header | 40 393 +--------------------+ : : +--------------------+ 394 20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8 395 +--------------------+ : : +--------------------+ 396 | IP Payload | <==> | IP Payload | 397 | | layer 4 | | 398 +--------------------+ unchanged +--------------------+ 400 Reversible Packet Translation 402 Figure 2 404 R-6: Values to be set in IPv6-header fields at Domain entry are 405 detailed in Table 1 (no-fragment-header case) and Table 2 406 (fragment-header case). 408 Ad hoc fields needed that convey IPv4-header informations that 409 have no equivalent in IPv6, namely IPv4_DF, TTL_1, TTL_255, 410 IPv4_TOS, and IPv4_ID, are placed in Identification fields of 411 IPv6 fragment headers as detailed in Figure 3. 413 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |.|.|.| 0 | IPv4_TOS | IPv4_ID | 417 /-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 / \ TTL_255 419 IPv4_DF TTL_1 421 4rd Identification fields of IPv6 Fragment headers 423 Figure 3 425 +---------------------+---------------------------------+ 426 | IPv6 FIELD | VALUE (fields from IPv4 header) | 427 +---------------------+---------------------------------+ 428 | Version | 6 | 429 | Traffic class | TOS | 430 | Flow label | 0 | 431 | Payload length | Total length - 20 | 432 | Next header | Protocol | 433 | Hop limit | Time to live | 434 | Source address | See Section 4.4 | 435 | Destination address | See Section 4.4 | 436 +---------------------+---------------------------------+ 438 IPv4-to-IPv6 Reversible Header Translation (without Fragment 439 header) 441 Table 1 443 R-7: Values to be set in IPv4 header fields at Domain exit are 444 detailed in Table 3 and Table 4. 446 +---------------------+-------------------------------------------+ 447 | IPv6 FIELD | VALUE (fields from IPv4 header) | 448 +---------------------+-------------------------------------------+ 449 | Version | 6 | 450 | Traffic class | TOS OR Tunnel_traffic_class (Section 4.6) | 451 | Flow label | 0 | 452 | Payload length | Total length - 12 | 453 | Next header | 44 (Fragment header) | 454 | Hop limit | IF Time to live = 1 | 455 | | OR Time to live = 255 THEN 254 | 456 | | ELSE Time to live | 457 | Source address | See Section 4.4 | 458 | Destination address | See Section 4.4 | 459 | 2nd next header | Protocol | 460 | Fragment offset | IPv4 Fragment offset | 461 | M | More-fragments flag (MF) | 462 | IPv4_DF | Don't-fragment flag (DF) | 463 | TTL_1 | IF Time to live = 1 THEN 1 ELSE 0 | 464 | TTL_255 | IF Time to live = 255 THEN 1 ELSE 0 | 465 | IPv4_TOS | Type of service (TOS) | 466 | IPv4_ID | Identification | 467 +---------------------+-------------------------------------------+ 469 IPv4-to-IPv6 Reversible Header Translation (with Fragment header) 471 Table 2 473 +---------------------+-----------------------------------+ 474 | IPv4 FIELD | VALUE (fields from IPv6 header) | 475 +---------------------+-----------------------------------+ 476 | Version | 4 | 477 | Header length | 5 | 478 | TOS | Traffic class | 479 | Total Length | Payload length + 20 (*) | 480 | Identification | 0 | 481 | DF | 1 | 482 | MF | 0 | 483 | Fragment offset | 0 | 484 | Time to live | Hop count | 485 | Protocol | Next header | 486 | Header checksum | Computed as per [RFC0791] | 487 | Source address | Bits 80-11 of source address (**) | 488 | Destination address | Bits 80-11 of source address (**) | 489 +---------------------+-----------------------------------+ 491 IPv6-to-IPv4 Reversible Header Translation (without Fragment header) 493 Table 3 495 +---------------------+--------------------------------------------+ 496 | IPv4 FIELD | VALUE (fields from IPv6 header) | 497 +---------------------+--------------------------------------------+ 498 | Version | 4 | 499 | Header length | 5 | 500 | TOS | Traffic class OR IPv4_TOS (Section 4.6) | 501 | Total Length | Payload length + 12 (*) | 502 | Identification | IPv4_ID | 503 | DF | IPv4_DF | 504 | MF | M | 505 | Fragment offset | Fragment offset | 506 | Time to live | IF TTL_1 = 1 THEN 1 | 507 | | ELSEIF TTL_255 = 1 THEN 255 ELSE Hop count | 508 | Protocol | 2nd Next header | 509 | Header checksum | Computed as per [RFC0791] | 510 | Source address | Bits 80-11 of source address (**) | 511 | Destination address | Bits 80-11 of destination address (**) | 512 +---------------------+--------------------------------------------+ 514 IPv6 to IPv4 Reversible Header Translation (with Fragment header) 516 Table 4 518 (*) Provided link-layer and IP-layer lengths are consistent. 519 (Otherwise the packet MUST be discarded.) 520 (**) Provided source and destination IPv6 addresses are exactly those 521 that, according to Section 4.4, are derived from the 4rd IPv4 522 addresses of the restored IPv4 packet. (Otherwise the packet MUST be 523 discarded.) 525 4.3. From CE IPv6 Prefixes to 4rd IPv4 prefixes 527 +--------------------------------------------+ 528 | CE IPv6 prefix | 529 +--------------------------+-----------------+ 530 : Longest match : : 531 : with a Rule IPv6 prefix : : 532 : || : : 533 : \/ : EA-bits length : 534 +--------------------------+ | : 535 | Rule IPv6 prefix |<----'---->:<-.->: 536 +--------------------------+ : \ 537 || : : Length of the 538 \/ : : Rule IPv6 suffix 539 +-----------------+-----------+(if the rule has one) 540 |Rule IPv4 prefix | EA bits | 541 +-----------------+-----------+ 542 : : 543 +-----------------------------+ 544 | CE 4rd IPv4 prefix | 545 +-----------------------------+ 546 ________/ \_________ : 547 / \ : 548 : ____:________________/ \__ 549 : / : \ 550 : =< 32 : : > 32 : 551 +----------------+ +-----------------+----+ 552 |IPv4 prfx or add| OR | IPv4 address |PSID| 553 +----------------+ +-----------------+----+ 554 : 32 : || : 555 \/ 557 (by default) (If WKPs authorized) 558 : : : : 559 +---+----+---------+ +----+-------------+ 560 Ports in |> 0|PSID|any value| OR |PSID| any value | 561 the CE port set +---+----+---------+ +----+-------------+ 562 : 4 : 12 : : 16 : 564 From CE IPv6 prefix to 4rd IPv4 address and Port set 565 Figure 4 567 R-8: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix 568 of one or several Mapping rules MUST select the CE mapping rule 569 for which the match is the longest. It then derives its 4rd 570 IPv4 prefix as shown in Figure 4: (1) the CE replaces the Rule 571 IPv6 prefix by the Rule IPv4 prefix and, if the found Mapping 572 rule has a Domain IPv6 suffix, deletes its last S bits, where S 573 is the Rule-IPv6-suffix length. The result is the CE 4rd IPv4 574 prefix. (2) If this CE 4rd IPv4 prefix has less than 32 bits, 575 the CE takes it as its assigned IPv4 prefix. If it has exactly 576 32 bits, the CE takes it as its IPv4 address. If it has more 577 than 32 bits, the CE MUST takes the first 32 bits as its shared 578 IPv4 address, and bits beyond the first 32 as its Port-set 579 identifier (PSID). Ports of its restricted port set are by 580 default those that have any non-zero value in their first 4 581 bits (the PSID offset), followed by the PSID, and followed by 582 any values in remaining bits. If the WKP authorized option 583 applies to the Mapping rule, there is no 4-bit offset before 584 the PSID so that all ports can be assigned. 586 NOTE: The choice of the default PSID position in Port fields 587 has been guided by the following objectives: (1) for fairness, 588 avoid having any of the well-known ports 0-1023 in the port set 589 specified by any PSID value; (2) for compatibility RTP/RTCP 590 [RFC4961], include in each port set pairs of consecutive ports; 591 (3) in order to facilitate operation and training, have the 592 PSID at a fixed position in port fields; (4) in order to 593 facilitate documentation in hexadecimal notation, and to 594 facilitate maintenance, have this position nibble aligned. 595 Ports that are excluded from assignment to CEs are 0-4095 596 instead of just 0-1023 in a trade-off to favor nibble alignment 597 of PSIDs and overall simplicity. 599 R-9: A CE whose delegated IPv6 prefix has its longest match with the 600 Rule IPv6 prefix of the BR mapping rule MUST take as IPv4 601 address the 32 bit that, in the delegated IPv6 prefix, follow 602 this Rule IPv6 prefix. If this is the case while the Hub&spoke 603 option applies to the Domain, or if the Rule IPv6 prefix is not 604 a /80, there is a configuration error in the Domain. An 605 implementation-dependent administrative action MAY be taken. 607 A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix 608 of neither any CE Mapping rule nor the BR mapping rule, and is 609 in a Domain that has a NAT64+ mapping rule, MUST take as its 610 IPv4 address the unspecified IPv4 address 0.0.0.0. 612 4.4. From 4rd IPv4 addresses to 4rd IPv6 Addresses 614 : 32 : : 16 : \ 615 +----------------------------+ +---------------+ | 616 | IPv4 address | |Port_or_ICMP_ID| | Shared-address 617 +----------------------------+ +---+------+----+ | case 618 : Longest match : : 4 : PSID : | (PSID length 619 : with a Rule IPv4 prefix : :length: | of the rule > 0) 620 : || : : : | with WKPs 621 : \/ : : : | not authorized 622 +----------------+-----------+ +------+ | (PSID offset = 4) 623 |Rule IPv4 prefix|IPv4 suffix| | PSID | | 624 +----------------+-----------+ +------+ | 625 : || \_______ \____ | _/ | 626 : \/ \ \| / | 627 +--------------------------+--------+--+---+ / 628 | Rule IPv6 prefix | EA bits | . | 629 +--------------------------+-----------+--\+ 630 : \ 631 : :\_ Domain IPv6 suffix 632 +------------------------------------------+ (if the rule has one) 633 | IPv6 prefix | 634 +------------------------------------------+ 635 :\_______________________________ / \ 636 : ___________________\_______/ \______________ 637 : / \ \ 638 : / (CE mapping rule) \ (BR mapping rule) \ 639 : =<64 : : 112 : 640 +----------+---+-+-+------+---+ +--------------+-+-+------+---+ 641 |CE v6 prfx| 0 |V|0|v4 add|CNP| |BR IPv6 prefix|V|0|v4 add|CNP| 642 +----------+-|-+-+-|+-----+---+ +--------------+-+-+------+---+ 643 : =<64 : | :8:8: 32 :16 : : 64 :8:8: 32 :16 : 644 | 645 Padding to /64 647 From 4rd IPv4 address to 4rd IPv6 address 649 Figure 5 651 R-10: BRs, and CEs that are assigned public IPv4 addresses, shared 652 or not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses 653 by the steps below or their functional equivalent (Figure 5 654 details the shared address case): 656 (1) If Hub&spoke topology does not apply to the Domain, or if 657 it applies but the IPv6 address to be derived is a source 658 address from a CE or a destination address from a BR, 659 find the CE mapping rule whose Rule IPv4 prefix has the 660 longest match with the IPv4 address. 662 If no Mapping rule is thus obtained, take the BR mapping 663 rule. 665 If the obtained Mapping rule assigns IPv4 prefixes to 666 CEs, i.e. if length of the Rule IPv4 prefix plus EA-bits 667 length is 32 - k, with >= 0, delete the last k bits of 668 the IPv4 address. 670 Otherwise, i.e. if length of the Rule IPv4 prefix plus 671 EA-bits length is 32 + k, with k > 0, take k as PSID 672 length, and append to the IPv4 address the PSID copied 673 from bits p to p+3 of the Port_or_ICMP_ID field where: 674 (1) p, the PSID offset, is 4 by default, and 0 if the 675 WKPs authorized option applies to the rule; (2) The 676 Port_or_ICMP_ID field is in bits of the IP payload that 677 depend on whether the address is source or destination, 678 on whether the packet is ICMP or not, and, if it is ICMP, 679 whether it is an error message or an echo message. This 680 field is: 682 a. If the packet Protocol is not ICMP, the port field 683 associated with the address (bits 0-15 for a source 684 address, and bits 16-31 for a destination address). 686 b. If the packet is an ICMPv4 echo or echo-reply 687 message, the ICMPv4 Identification field (bits 32-47 688 ). 690 c. If the packet is an ICMPv4 error message, the port 691 field associated with the address in the returned 692 packet header (bits 240-255 for a source address, 693 bits 224-239 for a destination address). 695 NOTE 1: Using Identification fields of ICMP messages as 696 port fields permits to exchange Echo requests and Echo 697 replies between shared-address CEs and and IPv4 hosts 698 having exclusive IPv4 addresses. Echo exchanges between 699 two shared-address CEs remain impossible, but this is a 700 limitation inherent to address sharing (one reason among 701 many to use IPv6). 703 NOTE 2: When the PSID is taken in the port field of the 704 IPv4 payload, it is, to avoid dependency on any 705 particular layer-4 protocol having port fields, without 706 checking that the protocol is indeed one that has a port 707 field . A packet may consequently go, in case of source 708 mistake, from a BR to a shared-address CE with a protocol 709 that is not supported by this CE. In this case, the CE 710 NAT44 returns an ICMPv4 "protocol unreachable" error 711 message. The IPv4 source is thus appropriately informed 712 of its mistake. 714 (2) Replace in the result the Rule IPv4 prefix by the Rule 715 IPv6 prefix. 717 (3) If the Mapping rule has a Domain IPv6 suffix, append it 718 to the result. 720 (4) If the result is shorter than a /64, append to it a null 721 padding up to 64 bits, followed by a V octet (0x03), 722 followed by a null octet, and followed by the IPv4 723 address. 725 NOTE: The V octet is a 4rd-specific mark. Its function 726 is to ensure that 4rd IPv6 addresses are recognizable by 727 CEs without any interference with the choice of subnet 728 prefixes in CE sites. (These choices may have been done 729 before 4rd is enabled.) 731 For this, the V octet has its "u" and "g" bits of 732 [RFC4291] both set to 1, so that they differ from "u" = 733 0, reserved for Interface IDs that have local-scope, and 734 also differs from "u" = 1 and "g"= 0, reserved for 735 unicast Interface IDs using the EUI-64 format. Bits 736 other than "u" and "g", are proposed to be 0, giving V = 737 0x03. 4rd is thus the first "future technology that can 738 take advantage of interface identifiers with universal 739 scope" [RFC4291]. As such, it needs to be endorsed by 740 the 6man working group and IANA (Section 6). 742 With the V octet, IPv6 packets can be routed to the 4rd 743 function within a CE node based on a /80 prefix that no 744 native-IPv6 address can contain. 746 The V octet can also facilitate maintenance by the 747 parameterless distinction it introduces between Tunnel 748 packets and native-IPv6 packets: a Tunnel packet has the 749 V octet in at least one of its IPv6 addresses (only in 750 the CE address in case of tunnel between CE and NAT64+, 751 in both addresses in case of tunnel between CE and BR or 752 between two CEs). 754 (5) Add to the result a Checksum-neutrality preserver (CNP). 755 Its value, in one's complement arithmetic, is the 756 opposite of the sum of 16-bit fields of the IPv6 address 757 other than the IPv4 address and the CNP themselves (i.e. 758 5 consecutive fields in address-bits 0-79). 760 NOTE: CNP guarantees that Tunnel packets are valid IPv6 761 packets for all layer-4 protocols that use the same 762 checksum algorithm as TCP. This guarantee does not 763 depend on where checksum fields of these protocols are 764 placed in IP payloads. (Today, such protocols are UDP 765 [RFC0768], TCP [RFC0793], UDP-Lite [RFC3828], and DCCP 766 [RFC5595]. Should new ones be specified, BRs will 767 support them without needing an update.) 769 Some IPv4-specific protocols such as ICMPv4, and UDP if 770 used with a null checksum, rely on the IP-header checksum 771 of IPv4 to ensure that IP addresses are not corrupted end 772 to end. For these, CNP acts as a substitute to the IP- 773 header checksum by the fact that integrity of each 4rd 774 IPv6 address can be individually checked: the 16-bit sum 775 of bits 0-95 and 112-127 of the IPv6 address MUST be 0 in 776 ones' complement arithmetic. 778 R-11: CEs that are assigned the unspecified IPv4 address 0.0.0.0 779 (see Section 4.3) MUST use, for tunnels between CEs and 780 NAT64+, addresses as detailed in Figure 6, (a) as source 781 addresses and (b) as destination addresses. A NAT64+ uses 782 address (b) as source address. Its destination addresses, 783 found in its binding information base, have format (a). They 784 contain the recognizable V octet. 786 +---------------------+---------+---+-----------------+------+ 787 (a) | CE IPv6 prefix | 0 | V | 0 | CNP | 788 +---------------------+---------+---+-----------------+------+ 789 : =< 64 : >= 0 : 8 : 40 : 16 : 790 4rd IPv6 address of a CE having no public IPv4 address 792 <----------- Rule IPv6 prefix --------->: 793 +-------------------------------+---+---+-------------+------+ 794 (b) | NAT64+ IPv6 prefix |"u"| 0 |IPv4 address | CNP | 795 +-------------------------------+---+---+-------------+------+ 796 : 64 : 8 : 8 : 32 : 16 : 797 4rd IPv6 address of a host reachable via a NAT64+ 799 Figure 6 801 R-12: For anti-spoofing protection, CEs and BRs MUST check that the 802 source address of each received Tunnel packet is that which, 803 according to Section 4.4, is derived from the source 4rd IPv4 804 address. For this, the IPv4 address used to obtain the source 805 4rd IPv4 address is that embedded in the IPv6 source address 806 (in its bits 80-111). (This verification is needed because 807 IPv6 ingress filtering [RFC3704] applies only to IPv6 808 prefixes, without guarantee that Tunnel packets are built as 809 specified in Section 4.4.) 811 R-13: For additional protection against packet corruption at a link 812 layer that might be undetected at this layer during Domain 813 traversal, CEs and BRs SHOULD verify that source and 814 destination IPv6 addresses have not been modified. This can 815 be done by checking that they remain checksum neutral (see the 816 Note on CNP above). 818 4.5. Fragmentation Considerations 820 4.5.1. Fragmentation at Domain Entry 822 R-14: If an IPv4 packet enters a CE or BR with a size such that the 823 derived Tunnel packet would be longer than the Domain PMTU, 824 the packet has to be either discarded or fragmented. The 825 Domain-entry node MUST discard if it the packet has DF=1, with 826 an ICMP error message returned to the source. It MUST 827 fragment it otherwise, with the payload of each fragment not 828 exceeding PMTU - 48. The first fragment has its offset equal 829 to the received offset. Following fragments have offsets 830 increased by lengths of previous-fragments payloads. 831 Functionally, fragmentation is supposed to be done in IPv4 832 before applying to each fragment the reversible header 833 translation of Section 4.2. 835 4.5.2. Ports of Fragments addressed to Shared-Address CEs 837 Because ports are available only in first fragments of IPv4 838 fragmented packets, a BR needs a mechanism to send to the right 839 shared-address CEs all fragments of fragmented packets. 841 For this, a BR MAY systematically reassemble fragmented IPv4 packets 842 before tunneling them. But this consumes large memory space, opens 843 denial-of-service-attack opportunities, and can significantly 844 increase forwarding delays. This is the reason for the following 845 requirement: 847 R-15: BRs SHOULD support an algorithm whereby received IPv4 packets 848 can be forwarded on the fly. The following is an example of 849 such algorithm: 851 (1) At BR initialization, if at least one CE mapping rule 852 concerns shared IPV4 addresses (length of Rule IPv4 853 prefix + EA-bits length > 32), the BR initializes an 854 empty "IPv4-packet table" whose entries have the 855 following items: 857 - IPv4 source 859 - IPv4 destination 861 - IPv4 identification. 863 - Destination port. 865 (2) When the BR receives an IPv4 packet whose matching 866 Mapping rule is one of shared addresses (length of Rule 867 IPv4 prefix + EA-bits length > 32), the the BR searches 868 the table for an entry whose IPv4 source, IPv4 869 destination, and IPv4 Identification, are those of the 870 received packet. The BR then performs actions detailed 871 in Table 5 depending on which conditions hold. 873 +---------------------------+---+---+---+---+---+---+---+---+ 874 | - CONDITIONS - | | | | | | | | | 875 | First Fragment (offset=0) | Y | Y | Y | Y | N | N | N | N | 876 | Last fragment (MF=0) | Y | Y | N | N | Y | Y | N | N | 877 | An entry has been found | Y | N | Y | N | Y | N | Y | N | 878 | ------------------------- | | | | | | | | | 879 | - RESULTING ACTIONS - | | | | | | | | | 880 | Create a new entry | - | - | - | X | - | - | - | - | 881 | Use port of the entry | - | - | - | - | X | - | X | - | 882 | Update port of the entry | - | - | X | - | - | - | - | - | 883 | Delete the entry | X | - | - | - | X | - | - | - | 884 | Forward the packet | X | X | X | X | X | - | X | - | 885 +---------------------------+---+---+---+---+---+---+---+---+ 887 Table 5 889 (3) The BR performs garbage collection for table entries that 890 remain unchanged for longer than some limit. This limit, 891 normally longer that the maximum time normally needed to 892 reassemble a packet is not critical. It should however 893 not be longer than 15 seconds [RFC0791]. 895 R-16: For the above algorithm to be effective, CEs that are assigned 896 shared IPv4 addresses MUST NOT interleave fragments of several 897 fragmented packets. 899 R-17: CEs that are assigned IPv4 prefixes, and are in nodes that 900 route public IPv4 addresses rather than only using NAT44s, 901 MUST have the same behavior as described just above for BRs. 903 4.5.3. Packet Identifications from Shared-Address CEs 905 When packets go from CEs that share the same IPv4 address to a common 906 destination, a precaution is needed to guarantee that packet 907 Identifications set by sources are different. Otherwise, packet 908 reassembly at destination could otherwise be confused because it is 909 based only on source IPv4 address and Identification. Probability of 910 such confusions may in theory be very low but, in order to avoid 911 creating new attack opportunities, a safe solution is needed. 913 R-18: A CE that is assigned a shared IPv4 address MUST only use 914 packet Identifications that have the CE PSID in their bits 0 915 to PSID length - 1. 917 R-19: A BR or a CE that receives a packet from a shared-address CE 918 MUST check that bits 0 to PSID length - 1 of their packet 919 Identifications are equal to the PSID found in source 4rd IPv4 920 address. 922 4.6. TOS and Traffic-Class Considerations 924 In networks that support Explicit congestion notification (ECN), the 925 TOS of IPv4 headers and the Traffic class of IPv6 headers have the 926 same meanings [RFC3168]. Their first 6 bits are a Differentiated 927 Services CodePoint (DSCP), and their two last bits are an Explicit 928 Congestion Notification (ECN). [RFC6040] details how the ECN MAY 929 evolve if a packet traverses a router that signals congestion 930 condition before packets are dropped. 932 R-20: 4rd domains in which the Tunnel traffic class option does not 933 apply MUST support the ECN normal mode of [RFC6040]. Their 934 BRs and CEs MUST copy the IPv4 TOS into the IPv6 Traffic class 935 at Domain entry, and copy back the IPv6 Traffic class (which 936 may have a changed ECN value), into the IPv4 TOS at Domain 937 exit. 939 R-21: In 4rd domains in which the Tunnel traffic class option 940 applies, BRs and CEs MUST, at Domain entry, copy the specified 941 Tunnel traffic class into the Traffic class, and copy the IPv4 942 TOS into the IPv4_TOS of the fragment header (Figure 3). At 943 Domain exit, they MUST copy back the IPv4_TOS-field into the 944 IPv4 TOS. 946 4.7. Tunnel-Generated ICMPv6 Error Messages 948 If an Tunnel packet is discarded on its way across a 4rd domain 949 because of an unreachable destination, an ICMPv6 error message is 950 returned to the IPv6 source. For the IPv4 source of the discarded 951 packet to be informed of packet loss, the ICMPv6 message has to be 952 converted into an ICMPv4 message. 954 R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it 955 MUST synthesize an ICMPv4 error packet [RFC0792]. This packet 956 MUST contain the first 8 octets of the discarded-packet IP 957 payload. If the CE or BR has a global IPv4 address, this 958 address MUST be used as source of this packet. Otherwise, 959 192.70.192.254 SHOULD be used as this source. (This address 960 is taken in the /24 range proposed for such a purpose in 961 draft-xli-behave-icmp-address-04. It is subject to IANA 962 confirmation). 964 Like in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination 965 unreachable, No route to destination") MUST be translated into 966 ICMPv4 Type = 3 and Code = 0 (Destination unreachable, Net 967 unreachable), and ICMPv6 Type = 3 and Code = 0 (Time exceeded, 968 Hop limit exceeded in transit) MUST be translated into ICMPv4 969 Type = 11 and Code = 0 (Destination unreachable, Net 970 unreachable). 972 4.8. Provisioning 4rd Parameters to CEs 974 Domain parameters listed in Section 4.1 are subject to the following 975 constraints: 977 R-23: Each Domain MUST have a BR mapping rule and/or a NAT64+ 978 mapping rule. (The BR mapping rule is only used by CEs that 979 are assigned public IPv4 addresses, shared or not. The NAT64+ 980 mapping rule is only used by CEs that are assigned the 981 unspecified IPv4 address (Section 4.3), and therefore need an 982 ISP NAT64 to reach IPv4 destinations. 984 R-24: Each CE and each BR MUST support up to 32 Mapping rules. 986 This number of is to ensure that independently acquired CEs an 987 BR nodes can always interwork. (Its value, which is not 988 critical, can easily be changed if another value would be 989 found more desirable by the WG.) 991 ISPs that need Mapping rules for more IPv4 prefixes than this 992 number SHOULD split their networks into multiple Domains. 993 Communication between these domains can be done in IPv4, or by 994 some implementation-dependent but equivalent other means. 996 R-25: For mesh topologies, where CE-CE paths don't go via BRs, all 997 mapping rules of the Domain MUST be sent to all CEs. For hub- 998 and-spoke topologies, where all CE-CE paths go via BRs, each 999 CE MAY be sent only the BR mapping rule of the Domain plus, if 1000 different, the CE mapping rule that applies to its CE IPv6 1001 prefix. 1003 R-26: In a Domain where the chosen topology is Hub&spoke, all CEs 1004 MUST have IPv6 prefixes that match a CE mapping rule. 1005 (Otherwise, packets sent to CEs whose IPv6 prefixes would 1006 match only the BR mapping rule would, with longest-match 1007 selected routes, be routed directly to these CEs. This would 1008 be contrary to the Hub&spoke requirement). 1010 R-27: CEs MUST be able to acquire parameters of 4rd domains 1011 (Section 4.1) in DHCPv6 (ref. [RFC2131]). Formats of DHCPv6 1012 options to be used are detailed in Figure 7 and Figure 8, with 1013 field values specified after each Figure. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | option-code = OPTION_4RD_RULE | option-length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | prefix4-len | prefix6-len | ea-len |sfx-len| sfx | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | rule-ipv4-prefix |W| 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | | 1025 + + 1026 | rule-ipv6-prefix | 1027 + + 1028 | | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 DHCPv6 option for Mapping-rule parameters 1033 Figure 7 1035 o option-code: OPTION_4RD_RULE (see Section 6) 1037 o option-length: 20 1039 o prefix4-len: number of bits of the Rule IPv4 prefix 1041 o prefix6-len: number of bits of the Rule IPv6 prefix 1043 o ea-len: EA-bits length 1045 o sfx-len: number of bits of the Rule IPv6 suffix 1047 o sfx: the Rule IPv6 suffix, left aligned 1049 o rule-ipv4-prefix: the Rule IPv4 prefix, left aligned 1051 o W: WKP authorized, = 1 if set 1053 o rule-ipv6-prefix: Rule IPv6 prefix, left aligned 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | option-code = OPTION_4RD | option-length | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 |H| 0 |T| traffic-class | domain-pmtu | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 DHCPv6 option for non-mapping-rule parameters of 4rd-domains 1064 Figure 8 1066 o option-code: OPTION_4RD (see Section 6) 1068 o option-length: 4 1070 o H: Hub&spoke topology (= 1 if Yes) 1072 o T: Traffic-class flag (= 1 if a Tunnel traffic class is provided) 1074 o traffic-class: Tunnel-traffic class 1076 o domain-pmtu: Domain PMTU (at least 1280) 1078 Other means than DHCPv6 that may prove useful to provide 4rd 1079 parameters to CEs are off-scope for this document. The same or 1080 similar parameter formats would however be recommended to facilitate 1081 training and operation. 1083 5. Security Considerations 1085 Spoofing attacks 1087 With IPv6 ingress filtering effective in the Domain [RFC3704], and 1088 with consistency checks between 4rd IPv4 and IPv6 addresses of 1089 Section 4.4, no spoofing opportunity in IPv4 is introduced by 4rd. 1091 Routing-loop attacks 1093 Routing-loop attacks that may exist in some automatic-tunneling 1094 scenarios are documented in [RFC6324]. No opportunity for 1095 routing-loop attacks has been identified with 4rd. 1097 Fragmentation-related attacks 1099 As discussed in Section 4.5, each BR of a Domain that assigns 1100 shared IPv4 should maintain a dynamic table for fragmented packets 1101 that go to these shared-address CEs. 1103 This opens a BNR vulnerability to a denial of service attack from 1104 hosts that would send very large numbers of first fragments and 1105 would never send last fragments having the same packet 1106 identifications. This vulnerability is inherent to IPv4 address 1107 sharing, be it static or dynamic. Compared to what it is with 1108 algorithms that reassemble IPv4 packets in BRs, it is however 1109 significantly mitigated by the algorithm of Section 4.5.2 which 1110 uses much less memory space. 1112 6. IANA Considerations 1114 IANA is requested to allocate the following: 1116 o Two DHCPv6 option codes TBD1 and TBD2 for OPTION_4RD_RULE and 1117 OPTION_4RD of Section 4.8 respectively (to be added to section 1118 24.3 of [RFC3315] 1120 o A reserved IPv4 address to be used as source of ICMPv4 messages 1121 due to ICMPv6 error messages. Its proposed value is 1122 192.70.192.254 (Section 4.7). 1124 o An IPv6 Interface-ID type reserved for 4rd (the V octet of 1125 Section 4.4). For this creation of new registry is suggested for 1126 Interface-ID types of unicast addresses that have neither local 1127 scope nor the universal scope of Modified EUI-64 format 1128 [RFC4291]). This registry is intended to be used for new 1129 Interface-ID types that may be useful in the future. 1131 7. Relationship with Previous Works 1133 The present specification has been influenced by many previous IETF 1134 drafts, in particular those accessible at 1135 http://tools.ietf.org/html/draft-xxxx where xxxx are the following 1136 (in order of their first versions): 1138 o bagnulo-behave-nat64 (2008-06-10) 1140 o xli-behave-ivi (2008-07-06) 1141 o despres-sam-scenarios (2008-09-28) 1143 o boucadair-port-range (2008-10-23) 1145 o ymbk-aplusp (2008-10-27) 1147 o xli-behave-divi (2009-10-19) 1149 o thaler-port-restricted-ip-issues (2010-02-28) 1151 o cui-softwire-host-4over6 (2010-05-05) 1153 o xli-behave-divi-pd (2011-07-02) 1155 o dec-stateless-4v6 (2011-03-05) 1157 o matsushima-v6ops-transition-experience (2011-03-07) 1159 o despres-intarea-4rd (2011-03-07) 1161 o deng-aplusp-experiment-results (2011-03-08) 1163 o murakami-softwire-4rd (2011-07-04) 1165 o operators-softwire-stateless-4v6-motivation (2011-05-05) 1167 o murakami-softwire-4v6-translation (2011-07-04) 1169 o despres-softwire-4rd-addmapping (2011-08-19) 1171 o boucadair-softwire-stateless-requirements (2011-09-08) 1173 o chen-softwire-4v6-add-format (2011-10-2) 1175 o mawatari-softwire-464xlat (2011-10-16) 1177 o mdt-softwire-map-dhcp-option (2011-10-24) 1179 o mdt-softwire-mapping-address-and-port (2011-11-25) 1181 o mdt-softwire-map-translation (2012-01-10) 1183 o mdt-softwire-map-encapsulation (2012-01-27) 1185 8. Acknowledgements 1187 This specification has benefited over several years from independent 1188 proposals, questions, comments, constructive suggestions, and useful 1189 criticisms, coming from numerous IETF contributors. 1191 Authors would like to express recognition to all these contributors, 1192 and more especially to the following, in alphabetical order of first 1193 names: Brian Carpenter, Behcet Sarikaya, Cameron Byrne, Congxiao Bao, 1194 Dan Wing, Erik Kline, Francis Dupont, Gabor Bajko, Gang Chen, Hui 1195 Deng, Jan Zorz, Jacni Quin (who has be an active co-author of some 1196 earlier versions of this specification), James Huang, Jaro Arkko, 1197 Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Mark Townsley, Maoke Chen 1198 (whose detailed reviews of previous versions have helped to improve 1199 the specification), Marcello Bagnulo, Mohamed Boucadair, Nejc 1200 Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong 1201 Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon 1202 Perreault, Stuart Cheshire, Teemu Savolainen, Tetsuya Murakami, 1203 Tomasz Mrugalski, Tina Tsou, Tomasz Mrugalski, Washam Fan, Wojciech 1204 Dec, Xiaohong Deng, Xing Li, 1206 9. References 1208 9.1. Normative References 1210 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1211 September 1981. 1213 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1214 RFC 792, September 1981. 1216 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1217 RFC 793, September 1981. 1219 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1220 October 1996. 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, March 1997. 1225 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1226 RFC 2131, March 1997. 1228 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1229 (IPv6) Specification", RFC 2460, December 1998. 1231 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1232 of Explicit Congestion Notification (ECN) to IP", 1233 RFC 3168, September 2001. 1235 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1236 and M. Carney, "Dynamic Host Configuration Protocol for 1237 IPv6 (DHCPv6)", RFC 3315, July 2003. 1239 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1240 Architecture", RFC 4291, February 2006. 1242 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1243 Message Protocol (ICMPv6) for the Internet Protocol 1244 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1246 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1247 Pignataro, "The Generalized TTL Security Mechanism 1248 (GTSM)", RFC 5082, October 2007. 1250 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1251 Notification", RFC 6040, November 2010. 1253 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1255 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1256 October 2010. 1258 9.2. Informative References 1260 [I-D.ietf-pcp-base] 1261 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1262 Selkirk, "Port Control Protocol (PCP)", 1263 draft-ietf-pcp-base-19 (work in progress), December 2011. 1265 [I-D.ietf-softwire-stateless-4v6-motivation] 1266 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 1267 Borges, I., and G. Chen, "Motivations for Stateless IPv4 1268 over IPv6 Migration Solutions", 1269 draft-ietf-softwire-stateless-4v6-motivation-00 (work in 1270 progress), September 2011. 1272 [I-D.shirasaki-nat444] 1273 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1274 and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work 1275 in progress), July 2011. 1277 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1278 August 1980. 1280 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1281 November 1990. 1283 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 1284 Translator (NAT)", RFC 1631, May 1994. 1286 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1287 E. Lear, "Address Allocation for Private Internets", 1288 BCP 5, RFC 1918, February 1996. 1290 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1291 IPv6 Specification", RFC 2473, December 1998. 1293 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1294 Networks", BCP 84, RFC 3704, March 2004. 1296 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1297 G. Fairhurst, "The Lightweight User Datagram Protocol 1298 (UDP-Lite)", RFC 3828, July 2004. 1300 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1301 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1303 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1304 BCP 131, RFC 4961, July 2007. 1306 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1307 (DCCP) Service Codes", RFC 5595, September 2009. 1309 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1310 Infrastructures (6rd) -- Protocol Specification", 1311 RFC 5969, August 2010. 1313 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1314 Algorithm", RFC 6145, April 2011. 1316 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1317 NAT64: Network Address and Protocol Translation from IPv6 1318 Clients to IPv4 Servers", RFC 6146, April 2011. 1320 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1321 Beijnum, "DNS64: DNS Extensions for Network Address 1322 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1323 April 2011. 1325 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1326 China Education and Research Network (CERNET) IVI 1327 Translation Design and Deployment for the IPv4/IPv6 1328 Coexistence and Transition", RFC 6219, May 2011. 1330 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1331 IPv6 Automatic Tunnels: Problem Statement and Proposed 1332 Mitigations", RFC 6324, August 2011. 1334 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1335 IPv4 Address Shortage", RFC 6346, August 2011. 1337 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1338 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 1340 Appendix A. Textual representation of Mapping rules 1342 In the next sections, each Mapping rule will be represented as 1343 follows, using 0bXXX to represent binary number XXX, and square 1344 brackets [ ] for what is optional: 1346 {Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix[, Rule IPv6 suffix] [, WKPs authorized]} 1348 EXAMPLES: 1349 {0.0.0.0/0, 32, 2001:db8:0:1:300::/80} 1350 a BR mapping rule 1351 {198.16.0.0/14, 22, 2001:db8:4000::/34} 1352 a CE mapping rule 1353 {0.0.0.0/0, 32, 2001:db8:0:1::/80} 1354 a NAT64+ mapping rule) 1355 {198.16.0.0/14, 22, 2001:db8:4000::/34, 0b0010, Yes} 1356 a CE mapping rule with a suffix 1357 and Hub&spoke Topology 1359 Appendix B. Configuring multiple Mapping Rules 1361 As far as mapping rules are concerned, the simplest deployment model 1362 is that in which the Domain has only one rule (the BR mapping rule). 1363 To assign an IPv4 address to a CE in this model, an IPv6 /112 is 1364 assigned to it comprising the BR /64 prefix, the V octet, a null 1365 octet, and the IPv4 address. This model has however the following 1366 limitations: (1) shared IPv4 addresses are not supported; (2) IPv6 1367 prefixes used for 4rd are too long to be used also for native IPv6 1368 addresses; (3) if the IPv4 address space of the ISP is split with 1369 many disjoint IPv4 prefixes, the IPv6 routing plan must be as complex 1370 as an IPv4 routing plan based on these prefixes. 1372 With more mapping rules, CE prefixes used for 4rd can be those used 1373 for native IPv6. How to choose CE mapping rules for a particular 1374 deployment needs not being standardized. 1376 The following is only a particular pragmatic approach that can be 1377 used for various deployment scenarios. It is used in some of the use 1378 cases that follow. 1380 (1) Select a "Common_IPv6_prefix" that will appear at the beginning 1381 of all 4rd CE IPv6 prefixes. 1383 (2) Choose all IPv4 prefixes to be used, and assign one of them to 1384 each CE mapping rule i. 1386 (3) For each CE mapping rule i, do the following: 1388 A. choose the length of its Rule IPv6 prefix (possibly the same 1389 for all CE mapping rules). 1391 B. Determine its PSID_length(i). A CE mapping rule that 1392 assigns shared addresses with a sharing ratio 2^Ki, has 1393 PSID_length = Ki. A CE mapping rule rule that assigns IPv4 1394 prefixes of length L < 32, is considered to have a negative 1395 PSID_length = L - 32. 1397 C. Derive EA-bits length (i) = 32 - L(Rule IPv4 prefix(i)) + 1398 PSID_length(i). 1400 D. Derive the length of Rule_code(i), the prefix to be appended 1401 to the Common prefix to get the Rule IPv6 prefix of rule i: 1403 L(Rule_code(i)) = L(CE IPv6 prefix(i)) 1404 - L(Common_IPv6_prefix] 1405 - (32 - L(Rule IPv4 prefix(i))) 1406 - PSID_length(i) 1408 E. Derive Rule_code(i) with the following constraints: (1) its 1409 length is L(Rule_code(i); it does not overlap with any of 1410 the previously obtained Rule codes (for instance, 010, and 1411 01011 do overlap, while 00, 011, and 010 do not); it has the 1412 lowest possible value as a fractional binary number (for 1413 instance, 0100 < 10 < 11011 < 111). Thus, rules whose 1414 Rule_code lengths are 4, 3 , 5, and 2, give Rule_codes 0000, 1415 001, 00010, and 01) 1417 F. Take Rule IPv6 prefix(i)= the Common_IPv6_prefix followed by 1418 Rule_code(i). 1420 :<--------------------- L(CE IPv6 prefix(i)) --------------------->: 1421 : : 1422 : 32 - L(Rule IPv4 prefix(i)) PSID_length(i): 1423 : \ | : 1424 : :<---------'--------><--'-->: 1425 : : || : 1426 : : \/ : 1427 : :<------->:<--- EA-bits length(i) --->: 1428 : L(Rule code(i)) 1429 : : : 1430 +----------------------------+---------+ 1431 | Common IPv6 prefix |Rule code| 1432 | | (i) | 1433 +----------------------------+---------+ 1434 :<------ L(Rule IPv6 prefix(i)) ------>: 1436 Figure 9 1438 Appendix C. ADDING SHARED IPv4 ADDRESSES TO AN IPv6 NETWORK 1440 C.1. With CEs within CPEs 1442 We consider an ISP that offers IPv6-only service to up to 2^20 1443 customers. Each customer is delegated a /56, starting with common 1444 prefix 2001:db8:0::/36. It wants to add public IPv4 service to 1445 customers that are 4rd-capable. It prefers to do it with stateless 1446 operation in its nodes, but has largely less IPv4 addresses than IPv6 1447 addresses so that a sharing ratio is necessary. 1449 The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16, 1450 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor 1451 aggregetable). This gives 2^(32-15) + 3*2^(32-16) IPv4 addresses, 1452 i.e. 2^18 + 2^16). For the 2^20 customers to have the same sharing 1453 ratio, the number of IPv4 addresses to be shared has to be a power of 1454 2. The ISP can therefore renounce to use one /16, say the last one. 1455 (Whether it could be motivated to return it to its Internet Registry 1456 is off-scope for this document.) The sharing ratio to apply is then 1457 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2. 1459 Applying principles of Appendix B with L[Common IPv6 prefix] = 36, 1460 L[PSID] = 2 for all rules, and L[CE IPv6 prefix(i)] = 56 for all 1461 rules, Rule codes and Rule IPv6 prefixes are: 1463 +--------------+--------+-----------+-----------+-------------------+ 1464 | CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 | 1465 | prefix | bits | length | (binary) | prefix | 1466 | | length | | | | 1467 +--------------+--------+-----------+-----------+-------------------+ 1468 | 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 | 1469 | 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 | 1470 | 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 | 1471 +--------------+--------+-----------+-----------+-------------------+ 1473 Mapping rules are then the following: 1475 {192.8.0.0/15, 19, 2001:0db8:0000::/37} 1476 {192.4.0.0/16, 18, 2001:0db8:0800::/38} 1477 {192.2.0.0/16, 18, 2001:0db8:0c00::/38} 1478 {0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80} 1480 The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56, 1481 derives its IPv4 address and its port set as follows (Section 4.3): 1483 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 1484 Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match) 1485 EA-bits length(i) : 18 1486 EA bits : 0b11 1011 1011 1011 1011 1487 Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16) 1488 IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110 1489 : 192.4.238.238 1490 PSID : 0b11 1491 Ports : 0bYYYY 11XX XXXX XXXX 1492 with YYYY > 0, and X...X any value 1494 An IPv4 packet sent to address 192.4.238.238 and port 7777 is 1495 tunneled to the IPv6 address obtained as follows (Section 4.4): 1497 IPv4 address : 192.4.238.238 (0xC004 EEEE) 1498 : 0b1100 0000 0000 0100 1110 1110 1110 1110 1499 Rule IPv4 prefix(i): 192.4.0.0/16 (longest match) 1500 : 0b1100 0000 0000 0100 1501 IPv4 suffix (i) : 0b1110 1110 1110 1110 1502 EA-bits length (i) : 18 1503 PSID length (i) : 2 (= 16 + 18 - 32) 1504 Port field : 0b 0001 1110 0110 0001 (7777) 1505 PSID : 0b11 1506 Rule IPv6 prefix(i): 2001:0db8:0800::/38 1507 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 1508 IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY 1509 with YYYY = the computed CNP 1511 C.2. With some CEs behind Third-party Router CPEs 1513 We now consider an ISP that has the same need as in the previous 1514 section except that, instead of using only its own IPv6 1515 infrastructure, it uses that of a third-party provider, and that some 1516 of its customers use CPEs of this provider to use specific services 1517 it offers. In these CPEs, a non-zero index is used to route IPv6 1518 packets to the physical port to which CEs are attached, say 0x2. 1519 Each such CPE delegates to the CE nodes the customer-site IPv6 prefix 1520 followed by this index. 1522 The ISP is supposed to have the same IPv4 prefixes as in the previous 1523 use case, 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16, and to use 1524 the same Common IPv6 prefix, 2001:db8:0::/36. 1526 We also assume that only a minority of customers use third-party 1527 CPEs, so that it is sufficient to use only one of the two /16s for 1528 them. 1530 Mapping rules, are then (see Appendix C.1): 1532 {192.8.0.0/15, 19, 2001:0db8:0000::/37} 1533 {192.4.0.0/16, 18, 2001:0db8:0800::/38, 0b0010} 1534 {192.2.0.0/16, 18, 2001:0db8:0c00::/38} 1535 {0.0.0.0/0, 32, 2001:0db8:0000:0001:3000::/80} 1537 CEs that are behind third-party CPEs derive their own IPv4 addresses 1538 and port sets as in Appendix C.1, except that, because the Mapping 1539 rule that applies to their IPv6 prefixes have a Rule IPv6 suffix, 1540 they delete this suffix from the end of their delegated IPv6 prefixes 1541 before deriving their 4rd IPv4 prefixes (Section 4.3). 1543 In a BR, and also in a CE if the topology is mesh, the IPv6 address 1544 that is derived from IPv4 address 192.4.238.238 and port 7777 is 1545 obtained as in the previous section, except for the two last steps 1546 which are modified: 1548 IPv4 address : 192.4.238.238 (0xC004 EEEE) 1549 : 0b1100 0000 0000 0100 1110 1110 1110 1110 1550 Rule IPv4 prefix(i): 192.4.0.0/16 (longest match) 1551 : 0b1100 0000 0000 0100 1552 IPv4 suffix (i) : 0b1110 1110 1110 1110 1553 EA-bits length (i) : 18 1554 PSID length (i) : 2 (= 16 + 18 - 32) 1555 Port field : 0b 0001 1110 0110 0001 (7777) 1556 PSID : 0b11 1557 Rule IPv6 prefix(i): 2001:0db8:0800::/38 1558 CE IPv6 prefix : 2001:0db8:0bbb:bb20::/60 (suffix 0x2 appended) 1559 IPv6 address : 2001:0db8:0bbb:bb20:3000:192.4.238.238:YYYY 1560 with YYYY = the computed CNP 1562 Appendix D. REPLACING DUAL-STACK ROUTING BY IPv6-ONLY ROUTING 1564 In this use case, we consider an ISP that offers IPv4 service with 1565 public addresses individually assigned to its customers. It also 1566 offers IPv6 service, having deployed for this dual-stack routing. 1567 Because it provides its own CPEs to customers, it can upgrade all its 1568 CPEs to support 4rd. It wishes to take advantage of this capability 1569 to replace dual-stack routing by IPv6-only routing without changing 1570 any IPv4 address or IPv6 prefix. 1572 For this, the ISP can use the single-rule model described at the 1573 beginning of Appendix B. If the prefix routed to BRs is chosen to 1574 start with 2001:db8:0:1::/64, this rule is: 1576 {0.0.0.0/0, 32, 2001:db8:0:1:3000::/80} 1578 All what is needed in the network before disabling IPv4 routing is 1579 the following: 1581 o In all routers, where there is an IPv4 route toward x.x.x.x/n, add 1582 a parallel route toward 2001:db8:0:1:3000:x.x.x.x::/(80+n) 1584 o Where IPv4 address x.x.x.x was assigned to a CPE, now delegate 1585 IPv6 prefix 2001:db8:0:1:3000:x.x.x.x::/112. 1587 NOTE: In parallel with this deployment, or after it, shared IPv4 1588 addresses can be assigned to IPv6 customers. It is sufficient that 1589 IPv4 prefixes used for this be different from those used for 1590 exclusive-address assignments. Under this constraint, Mapping rules 1591 can be set up according to the same principles as those of 1592 Appendix C. 1594 Appendix E. ADDING IPv6 AND 4rd SERVICE TO A NET-10 NETWORK 1596 In this use case, we consider an ISP that has only deployed IPv4, 1597 possibly because some of its network devices are not yet IPv6 1598 capable. Because it did not have enough IPv4 addresses, it has 1599 assigned private IPv4 addresses of [RFC1918] to customers, say 1600 10.x.x.x. It thus supports up to 2^24 customers (a "Net-10" network, 1601 using the NAT444 model of [I-D.shirasaki-nat444]). It wishes to 1602 offer IPv6 service without further delay, using for this 6rd 1603 [RFC5969]. It also wishes to offer incoming IPv4 connectivity to its 1604 customers with a simpler solution than that of PCP 1605 [I-D.ietf-pcp-base]. 1607 The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32, 1608 and the public IPv4 prefix to be used for shared addresses is 1609 supposed to be 192.16.0.0/16 (0xc610). The resulting sharing ratio 1610 is 2^24 / 2^(32-16) = 256, giving a PSID length of 8. 1612 The ISP installs one or several BRs, at its border to the public IPv4 1613 Internet. They support 6rd, and 4rd above it. The BR prefix /64 is 1614 supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e. 1615 2001:db8:0:100:/64). 1617 In accordance with [RFC5969], 6rd BRs are configured with the 1618 following parameters IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32; 1619 6rdBRIPv4Address = 192.168.0.1 (0xC0A80001). 1621 4rd Mapping rules are then the following: 1623 {192.16.0.0/16, 24, 2001:db8:0:0:3000::/80} 1624 {0.0.0.0/0, 32, 2001:db8:0:100:3000:/80,} 1626 Any customer device that supports 4rd in addition to 6rd can then use 1627 its assigned shared IPv4 address with 240 assigned ports. 1629 If its NAT44 supports port forwarding to provide incoming IPv4 1630 connectivity (statically, or dynamically with UPnP an/or NAT-PMP), it 1631 can use it with ports of the assigned port set (a possibility that 1632 does not exist in Net-10 networks without 4rd/6rd). 1634 Authors' Addresses 1636 Remi Despres (editor) 1637 RD-IPtech 1638 3 rue du President Wilson 1639 Levallois, 1640 France 1642 Email: despres.remi@laposte.net 1644 Reinaldo Penno 1645 Cisco Systems, Inc. 1646 170 West Tasman Drivee 1647 San Jose, California 95134 1648 USA 1650 Email: repenno@cisco.com 1652 Yiu Lee 1653 Comcast 1654 One Comcast Center 1655 Philadelphia, PA 1903 1656 USA 1658 Email: Yiu_Lee@Cable.Comcast.com 1660 Gang Chen 1661 China Mobile 1662 53A, Xibianmennei Ave. 1663 Xuanwu District, Beijing 100053 1664 China 1666 Email: phdgang@gmail.com 1668 Sheng Jiang 1669 Huawei Technologies Co., Ltd 1670 Q14, Huawei Campus - No.156 Beijing Road 1671 Hai-Dian District, Beijing, 100095 1672 P.R. China 1674 Email: shengjiang@huawei.com