idnits 2.17.1 draft-ietf-softwire-4rd-09.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 15 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 date (October 12, 2014) is 3476 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'PSID' is mentioned on line 1545, but not defined ** 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) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 S. Jiang, Ed. 5 Expires: April 15, 2015 Huawei Technologies Co., Ltd 6 R. Penno 7 Cisco Systems, Inc. 8 Y. Lee 9 Comcast 10 G. Chen 11 China Mobile 12 M. Chen 13 Freebit Co, Ltd. 14 October 12, 2014 16 IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd) 17 draft-ietf-softwire-4rd-09 19 Abstract 21 For service providers to progressively deploy IPv6-only network 22 domains while still offering IPv4 service to customers, this document 23 specifies a stateless solution. Its distinctive property is that 24 TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain 25 traversal, and that IPv4 fragmentation rules are fully preserved end- 26 to-end. Each customer can be assigned one public IPv4 address, or 27 several, or a shared address with a restricted port set. 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 April 15, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 Specifications . . . . . . . . . . . . . . . . . . . 8 67 4.1. NAT44 on CE . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Mapping rules and other Domain parameters . . . . . . . . 8 69 4.3. Reversible Packet Translations at Domain entries and 70 exits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4 72 prefixes . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.5. Address Mapping from 4rd IPv4 addresses to 4rd IPv6 74 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.6. Fragmentation Processing . . . . . . . . . . . . . . . . 21 76 4.6.1. Fragmentation at Domain Entry . . . . . . . . . . . . 21 77 4.6.2. Ports of Fragments addressed to Shared-Address CEs . 21 78 4.6.3. Packet Identifications from Shared-Address CEs . . . 22 79 4.7. TOS and Traffic-Class Processing . . . . . . . . . . . . 23 80 4.8. Tunnel-Generated ICMPv6 Error Messages . . . . . . . . . 23 81 4.9. Provisioning 4rd Parameters to CEs . . . . . . . . . . . 24 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 7. Relationship with Previous Works . . . . . . . . . . . . . . 28 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 88 9.2. Informative References . . . . . . . . . . . . . . . . . 31 89 Appendix A. Textual representation of Mapping rules . . . . . . 32 90 Appendix B. Configuring multiple Mapping Rules . . . . . . . . . 33 91 Appendix C. ADDING SHARED IPv4 ADDRESSES TO AN IPv6 NETWORK . . 35 92 C.1. With CEs within CPEs . . . . . . . . . . . . . . . . . . 35 93 C.2. With some CEs behind Third-party Router CPEs . . . . . . 36 95 Appendix D. REPLACING DUAL-STACK ROUTING BY IPv6-ONLY ROUTING . 37 96 Appendix E. ADDING IPv6 AND 4rd SERVICE TO A NET-10 NETWORK . . 38 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 99 1. Introduction 101 For service providers to progressively deploy IPv6-only network 102 domains while still offering IPv4 service to customers, the need for 103 a stateless solution, i.e. one where no per-customer state is needed 104 in IPv4-IPv6 gateway nodes of the provider, is expressed in 105 [I-D.ietf-softwire-stateless-4v6-motivation]. This document 106 specifies such a solution, named "4rd" for IPv4 Residual Deployment. 108 Using the solution, IPv4 packets are transparently tunneled across 109 IPv6 networks (reverse of 6rd [RFC5969] in which IPv6 packets are 110 statelessly tunneled across IPv4 networks). 112 While IPv6 headers are too long to be mapped into IPv4 headers (why 113 6rd requires encapsulation of full IPv6 packets in IPv4 packets), 114 IPv4 headers can be reversibly translated into IPv6 headers in such a 115 way that, during IPv6 domain traversal, UDP packets having checksums 116 and TCP packets are valid IPv6 packets. IPv6-only middle boxes that 117 perform deep-packet- inspection can operate on them, in particular 118 for port inspection and web caches. 120 In order to deal with the IPv4-address shortage, customers can be 121 assigned shared public IPv4 addresses, with statically assigned 122 restricted port sets. As such, it is a particular application of the 123 A+P approach of [RFC6346]. 125 Deploying 4rd in the networks that have enough public IPv4 address, 126 customer sites can also be assigned full public IPv4 addresses. 4rd 127 also supports the scenarios that a set of public IPv4 addresses are 128 assigned to customer sites. 130 The design of 4rd builds on a number of previous proposals made for 131 IPv4-via-IPv6 transition technologies listed in Section 8. 133 In some use cases, IPv4-only applications of 4rd-capable customer 134 nodes can also work with stateful NAT64s of [RFC6146], provided these 135 are upgraded to support 4rd tunnels in addition their IP/ICMP 136 translation of [RFC6145]. The advantage is then a more complete IPv4 137 transparency than with double translation. 139 How the 4rd model fits in the Internet architecture is summarized in 140 Section 3. The protocol specification is detailed in Section 4. 141 Section 5 and Section 6 respectively deal with security and IANA 142 considerations. Previous proposals that influenced this 143 specification are listed in Section 8. A few typical 4rd use cases 144 are presented in Appendices. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 ISP: Internet-Service Provider. In this document, the service it 153 offers can be DSL, fiber-optics, cable, or mobile. The ISP can 154 also be a private-network operator. 156 4rd (IPv4 Residual Deployment): An extension of the IPv4 service 157 where public IPv4 addresses can be statically shared among 158 several customer sites, each one being assigned an exclusive 159 port set. This service is supported across IPv6-routing 160 domains. 162 4rd domain (or Domain): An ISP-operated IPv6 network across which 163 4rd is supported according to the present specification. 165 Tunnel packet: An IPv6 packet that transparently conveys an IPv4 166 packet across a 4rd domain. Its header has enough information 167 to reconstitute the IPv4 header at Domain exit. Its payload is 168 the original IPv4 payload. 170 CE (Customer Edge): A customer-side tunnel endpoint. It can be in a 171 node that is a host, a router, or both. 173 BR (Border Relay): An ISP-side tunnel-endpoint. Because its 174 operation is stateless (neither per CE nor per session state) it 175 can be replicated in as many nodes as needed for scalability. 177 4rd IPv6 address: IPv6 address used as destination of a Tunnel 178 packet sent to a CE or a BR. 180 NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd 181 tunneling when IPv6 addresses it deals with are 4rd IPv6 182 addresses. 184 4rd IPv4 address: A public IPv4 address or, in case of a shared 185 public IPv4 address, a public transport address (public IPv4 186 address plus port number). 188 PSID (Port-Set Identifier): A flexible-length field that 189 algorithmically identifies a port set. 191 4rd IPv4 prefix: A flexible-length prefix that may be a a public 192 IPv4 prefix, a public IPv4 address, or a public IPv4 address 193 followed by a PSID. 195 Mapping rule: A set of parameters that are used by BRs and CEs to 196 derive 4rd IPv6 addresses from 4rd IPv4 addresses. Mapping 197 rules are also used by each CE to derive a 4rd IPv4 prefix from 198 an IPv6 prefix that it has been delegated. 200 EA bits (Embedded Address bits): Bits that are the same in a 4rd 201 IPv4 address and in the 4rd IPv6 address derived from it. 203 BR mapping rule: The mapping rule applicable to off-domain IPv4 204 addresses (addresses reachable via BRs). It can also apply to 205 some or all of CE-assigned IPv4 addresses. 207 CE mapping rule: A mapping rule that is applicable only to CE- 208 assigned IPv4 addresses (shared or not). 210 NAT64+ mapping rule: Mapping rule applicable to IPv4 addresses 211 reachable via a NAT64+. 213 CNP (Checksum Neutrality preserver): A field of 4rd IPv6 addresses 214 that ensures that TCP-like checksums do not change when IPv4 215 addresses are replaced by 4rd IPv6 addresses. 217 4rd Tag: A 16-bit tag whose value permits, in 4rd CEs, BRs, and 218 NAT64+s, to distinguish 4rd IPv6 addresses from other IPv6 219 addresses. 221 3. The 4rd Model 222 4rd DOMAIN 223 +-----------------------------+ 224 | IPv6 routing | 225 | Enforced ingress filtering | +---------- 226 ... | | | 227 | +------+ 228 Customer site | |BR(s) | IPv4 229 +------------+ | BR IPv6 prefix --> |and/or| Internet 230 | dual-stack | | |N4T64+| 231 | +--+ | +------+ 232 | |CE+-+ <-- a CE IPv6 prefix | | 233 | +--+ | | +---------- 234 | | | | 235 +------------+ | <--IPv4 tunnels--> +------------ 236 => Derived | (Mesh or hub-and-spoke | 237 4rd IPv4 prefix| topologies) | IPv6 238 | | Internet 239 ... | | 240 | +------------ 241 +-----------------------------+ 242 <== one or several Mapping rules 243 (e.g. announced to CEs in stateless DHCPv6 ) 245 Figure 1 247 How the 4rd model fits in the Internet architecture is represented in 248 Figure 1. 250 A 4rd domain is an IPv6 network that includes one or several 4rd BRs 251 or NAT64+s at its border with the public IPv4 Internet, and can 252 advertise its IPv4-IPv6 Mapping rule(s) to CEs according to 253 Section 4.9. 255 BRs of a 4rd Domain are all identical as far as 4rd is concerned. In 256 a 4rd CE, the IPv4 packets will be transformed (detailed in 257 Section 4.3) into IPv6 packets that have the same anycast IPv6 258 prefix, which is the 80-bit BR prefix, in their destination 259 addresses. They are then routed to any of the BRs. The 80-bit BR 260 IPv6 prefix is an arbitrarily chosen /64 prefix from the IPv6 address 261 space of the network operator and appended 0x0300 (16-bit 4rd Tag, 262 see R-9 in Section 4.5). 264 Using the Mapping rule that applies, each CE derives its 4rd IPv4 265 prefix from its delegated IPv6 prefix, or one of them if it has 266 several, details in Section 4.4. If the obtained IPv4 prefix has 267 more than 32 bits, the assigned IPv4 address is shared among several 268 CEs. Bits beyond the first 32 specify a set of ports whose use is 269 reserved for the CE. 271 IPv4 traffic is automatically tunnelled across the Domain, either in 272 mesh topology or in Hub&spoke topology [RFC4925]. By default, IPv4 273 traffic between two CEs follows a direct IPv6 route between them 274 (mesh topology). If the ISP configures the Hub&spoke option, each 275 IPv4 packet from a CE to another is routed via a BR. 277 During Domain traversal, each tunnelled TCP/UDP IPv4 packet looks 278 like a valid TCP/UDP IPv6 packet. Thus, TCP/UDP access-control lists 279 that apply to IPv6, and possibly some other functions using deep 280 packet inspections, also apply to IPv4. 282 For IPv4 anti-spoofing protection, as is in CEs and BRs, to remain 283 effective when combined with 4rd tunneling, ingress filtering has to 284 be effective in IPv6 (R-12 and Section 5). 286 If an ISP wishes to support dynamic IPv4 address sharing, in addition 287 or in place of 4rd stateless address sharing, it can do it by means 288 of a stateful NAT64. By upgrading this NAT to add 4rd-tunnels 289 support, which makes it a NAT64+, CEs that are assigned no static 290 IPv4 space can benefit from complete IPv4 transparency between CE and 291 NAT64. (Without this NAT64 upgrade, IPv4 traffic is translated to 292 IPv6 and back to IPv4, which looses the DF=MF=1 combination of IPv4, 293 that which is recommended for host fragmentation in Section 8 of 294 [RFC4821].) 296 IPv4 packets are kept unchanged by Domain traversal except that: 298 o The IPv4 Time to live (TTL), unless it is 1 or 255 at Domain 299 entry, decreases during Domain traversal by the number of 300 traversed routers. This is acceptable because it is undetectable 301 end to end, and because TTL values that can be used with some 302 protocols to test adjacency of communicating routers are preserved 303 ([RFC4271], [RFC5082] ). Effect on the traceroute utility, which 304 uses TTL expiry to discover routers of end-to-end paths, is noted 305 in Section 4.3. 307 o IPv4 packets whose lengths are =< 68 octets always have their 308 "Don't fragment flags" DF=1 at Domain exit even if they had DF=0 309 at Domain entry. This is acceptable because these packets are too 310 short to be fragmented [RFC0791] so that their DF bits have no 311 meaning. Besides, both [RFC1191] and [RFC4821] recommend that 312 sources always set DF=1. 314 o Unless the Tunnel-traffic-class option applies to a Domain 315 (Section 4.2), IPv4 packets may have their TOS fields modified 316 after Domain traversal (Section 4.7). 318 4. Protocol Specifications 320 This section describes detailed 4rd protocol specifications. They 321 are mainly organized by functions. As a brief summary, a 4rd CE MUST 322 follow R-1, R-2, R-3, R-4, R-6, R-7, R-8, R-9, R-10, R-11, R-12, 323 R-13, R-14, R-16, R-17, R-18, R-19, R-20, R-21, R-22, R-23, R-24, 324 R-25, R-26 and R-27; while a 4rd BR MUST follow R-2, R-3, R-4, R-5, 325 R-6, R-9, R-12, R-13, R-14, R-15, R-19, R-20, R-21, R-22 and R-24. 327 4.1. NAT44 on CE 329 R-1: A CE node that is assigned a shared public IPv4 address MUST 330 include a NAT44 [RFC3022]. This NAT44 MUST only use external 331 ports that are in the CE assigned port set. 333 NOTE: This specification only concerns IPv4 communication between 334 IPv4-capable endpoints. For communication between IPv4-only 335 endpoints and IPv6 only remote endpoints, the BIH specification of 336 [RFC6535] can be used. It can coexist in a node with the CE 337 function, including if the IPv4-only function is a NAT44 [RFC3022]. 339 4.2. Mapping rules and other Domain parameters 341 R-2: CEs and BRs MUST be configured with the following Domain 342 parameters: 344 A. One or several Mapping rules, each one comprising: 346 1. Rule IPv4 prefix 348 2. EA-bits length 350 3. Rule IPv6 prefix 352 4. WKPs authorized (OPTIONAL) 354 B. Domain PMTU 356 C. Hub&spoke topology (Yes or No) 358 D. Tunnel traffic class (OPTIONAL) 360 "Rule IPv4 prefix" is used to find, by a longest match, which Mapping 361 rule applies to a 4rd IPv4 address (Section 4.5). A Mapping rule 362 whose Rule IPv4 prefix is longer than /0 is a CE mapping rule. BR 363 and NAT64+ mapping rules, which must apply to all off-domain IPv4 364 addresses, have /0 as their Rule IPv4 prefixes. 366 "EA-bits length" is the number of bits that are common to 4rd IPv4 367 addresses and 4rd IPv6 addresses derived from them. In a CE mapping 368 rule, it is also the number of bits that are common to a CE delegated 369 IPv6 prefix and the 4rd IPv4 prefix derived from it. BR and NAT64+ 370 mapping rules have EA-bits lengths equal to 32. 372 "Rule IPv6 prefix" is the prefix that is substituted to the Rule IPv4 373 prefix when a 4rd IPv6 address is derived from a 4rd IPv4 address 374 (Section 4.5). In a BR mapping rule or a NAT64+ mapping rule, it 375 MUST be a /80 prefix whose 64~79 bits are the 4rd Tag. 377 "WKPs authorized" may be set for mapping rules that assign shared 378 IPv4 addresses to CEs. (These rules are those whose length of the 379 Rule IPv4 prefix plus the EA-bits length exceeds 32.) If set, well- 380 known ports may be assigned to some CEs having particular IPv6 381 prefixes. If not set, fairness is privileged: all IPv6 prefixes 382 concerned with the Mapping rule have ports sets having identical 383 values (no port set includes any of the well known ports). 385 "Domain PMTU" is the IPv6 path MTU that the ISP can guarantee for all 386 its IPv6 paths between CEs and between BRs and CEs. It MUST be at 387 least 1280 [RFC2460]. 389 "Hub&spoke topology", if set to Yes, requires CEs to tunnel all IPv4 390 packets via BRs. If set to No, CE-to-CE packets take the same routes 391 as native IPv6 packets between the same CEs (mesh topology). 393 "Tunnel traffic class", if provided, is the IPv6 traffic class that 394 BRs and CEs MUST set in Tunnel packets. In this case, evolutions of 395 the IPv6 traffic class that may occur during Domain traversal are not 396 reflected in TOS fields of IPv4 packets at Domain exit (Section 4.7). 398 4.3. Reversible Packet Translations at Domain entries and exits 400 R-3: Domain-entry nodes that receive IPv4 packets with IPv4 options 401 MUST discard these packets, and return ICMPv4 error messages to 402 signal IPv4-option incompatibility (Type = 12, Code = 0, 403 Pointer = 20) [RFC0792]. This limitation is acceptable because 404 there are a lot firewalls in current IPv4 Internet also filter 405 IPv4 packets with IPv4 options. 407 R-4: Domain-entry nodes that receive IPv4 packets without IPv4 408 options MUST convert them to Tunnel packets, with or without 409 IPv6 fragment headers depending on what is needed to ensure 410 IPv4 transparency (Figure 2). Domain-exit nodes MUST convert 411 them back to IPv4 packets. 413 An IPv6 fragmentation header MUST be included at tunnel entry 414 (Figure 2) if, and only if, one or several of the following 415 conditions hold: 417 * The Tunnel_traffic_class option applies to the Domain. 419 * TTL = 1 OR TTL = 255. 421 * The IPv4 packet is already fragmented, or may be fragmented 422 later on, i.e. if MF=1 OR Offset>0 OR (Total length > 68 AND 423 DF=0). 424 In order to optimize cases where fragmentation headers are 425 unnecessary, the NAT44 of a CE that has one SHOULD send packets 426 with TTL = 254. 428 R-5: In Domains whose chosen topology is Hub&spoke, BRs that receive 429 4rd IPv6 packets whose embedded destination IPv4 addresses 430 match a CE mapping rule MUST do the equivalent of reversibly 431 translating their headers to IPv4 and then reversibly translate 432 them back to IPv6 as though packets would be entering the 433 Domain. 435 (A) Without IPv6 fragment header 436 IPv4 packet Tunnel packet 437 +--------------------+ : : +--------------------+ 438 20| IPv4 Header | : <==> : | IPv6 Header | 40 439 +--------------------+ : : +--------------------+ 440 | IP Payload | <==> | IP Payload | 441 | | layer 4 | | 442 +--------------------+ unchanged +--------------------+ 444 (B) With IPv6 fragment header 445 Tunnel packet 446 : +--------------------+ 447 IPv4 packet : | IPv6 Header | 40 448 +--------------------+ : : +--------------------+ 449 20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8 450 +--------------------+ : : +--------------------+ 451 | IP Payload | <==> | IP Payload | 452 | | layer 4 | | 453 +--------------------+ unchanged +--------------------+ 455 Reversible Packet Translation 457 Figure 2 459 R-6: Values to be set in IPv6-header fields at Domain entry are 460 detailed in Table 1 (no-fragment-header case) and Table 2 461 (fragment-header case). Those to be set in IPv4 header fields 462 at Domain exit are detailed in Table 3 (no-fragment-header 463 case) and Table 4 (fragment-header case). 465 To convey IPv4-header informations that have no equivalent in 466 IPv6, some ad-hoc fields are placed in IPv6 flow labels and in 467 Identification fields of IPv6 fragment headers, as detailed in 468 Figure 3. 470 |0 |4 19| 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | 0 | Addr_Prot_Cksm | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 IPv6 FLOW LABEL 476 0 1 2 |8 |16 31| 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 |.|.|.| 0 | IPv4_TOS | IPv4_ID | 479 /-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 / \ TTL_255 IPv6 IDENTIFICATION FIELD 481 IPv4_DF TTL_1 (in Fragment header if needed) 483 4rd Identification fields of IPv6 Fragment headers 485 Figure 3 487 +---------------------+----------------------------------------+ 488 | IPv6 FIELD | VALUE (fields from IPv4 header) | 489 +---------------------+----------------------------------------+ 490 | Version | 6 | 491 | Traffic class | TOS | 492 | Addr_Prot_Cksm | Sum of Addresses and Protocol (Note 1) | 493 | Payload length | Total length - 20 | 494 | Next header | Protocol | 495 | Hop limit | Time to live | 496 | Source address | See Section 4.5 | 497 | Destination address | See Section 4.5 | 498 +---------------------+----------------------------------------+ 500 IPv4-to-IPv6 Reversible Header Translation (without Fragment header) 502 Table 1 504 +-----------------+----------------------------------------------+ 505 | IPv6 FIELD | VALUE (fields from IPv4 header) | 506 +-----------------+----------------------------------------------+ 507 | Version | 6 | 508 | Traffic class | TOS OR Tunnel_traffic_class (Section 4.7) | 509 | Addr_Prot_Cksm | Sum of Addresses and Protocol (Note 1) | 510 | Payload length | Total length - 12 | 511 | Next header | 44 (Fragment header) | 512 | Hop limit | IF Time to live = 1 or 255 THEN 254 | 513 | | ELSE Time to live (Note 2) | 514 | Source address | See Section 4.5 | 515 | Dest. address | See Section 4.5 | 516 | 2nd next header | Protocol | 517 | Fragment offset | IPv4 Fragment offset | 518 | M | More-fragments flag (MF) | 519 | IPv4_DF | Don't-fragment flag (DF) | 520 | TTL_1 | IF Time to live = 1 THEN 1 ELSE 0 (Note 2) | 521 | TTL_255 | IF Time to live = 255 THEN 1 ELSE 0 (Note 2) | 522 | IPv4_TOS | Type of service (TOS) | 523 | IPv4_ID | Identification | 524 +-----------------+----------------------------------------------+ 526 IPv4-to-IPv6 Reversible Header Translation (with Fragment header) 528 Table 2 530 +-----------------+------------------------------------+ 531 | IPv4 FIELD | VALUE (fields from IPv6 header) | 532 +-----------------+------------------------------------+ 533 | Version | 4 | 534 | Header length | 5 | 535 | TOS | Traffic class | 536 | Total Length | Payload length + 20 | 537 | Identification | 0 | 538 | DF | 1 | 539 | MF | 0 | 540 | Fragment offset | 0 | 541 | Time to live | Hop count | 542 | Protocol | Next header | 543 | Header checksum | Computed as per [RFC0791] (Note 3) | 544 | Source address | Bits 80-111 of source address | 545 | Dest. address | Bits 80-111 of source address | 546 +-----------------+------------------------------------+ 548 IPv6-to-IPv4 Reversible Header Translation (without Fragment header) 550 Table 3 552 +-----------------------+-----------------------------------------+ 553 | IPv4 FIELD | VALUE (fields from IPv6 headers) | 554 +-----------------------+-----------------------------------------+ 555 | Version | 4 | 556 | Header length | 5 | 557 | TOS | Traffic class OR IPv4_TOS (Section 4.7) | 558 | Total Length | Payload length + 12 | 559 | Identification | IPv4_ID | 560 | DF | IPv4_DF | 561 | MF | M | 562 | Fragment offset | Fragment offset | 563 | Time to live (Note 2) | IF TTL_255 = 1 THEN 255TTL_1 = 1 THEN 1 | 564 | | ELSEIF TTL_1 = 1 THEN 1 ELSE Hop count | 565 | Protocol | 2nd Next header | 566 | Header checksum | Computed as per [RFC0791] (Note 3) | 567 | Source address | Bits 80-111 of source address | 568 | Destination address | Bits 80-111 of destination address | 569 +-----------------------+-----------------------------------------+ 571 IPv6 to IPv4 Reversible Header Translation (with Fragment header) 573 Table 4 575 NOTE 1: The need to save in the IPv6 header a checksum of both IPv4 576 addresses and the IPv4 protocol field results from the following 577 facts: (1) Header checksums, present in IPv4 but not in IPv6, protect 578 addresses or protocol integrity; (2) In IPv4, ICMP messages and null- 579 checksum UDP datagram depend on this protection because, unlike other 580 datagrams, they have no other address-and-protocol integrity 581 protection. The sum MUST be performed in ordinary 2's complement 582 arithmetic. 584 IP-layer Packet length is another field covered by the IPv4 IP-header 585 checksum. It is not included in the saved checksum because: (1) 586 doing so would have conflicted with [RFC6437] (flow labels must be 587 the same in all packets of each flow); (2) ICMPv4 messages have good 588 enough protection with their own checksums; (3) the UDP length field 589 provides to null-checksum UDP datagrams the same level of protection 590 after Domain traversal as without Domain traversal (consistency 591 between IP-layer and UDP-layer lengths can be checked). 593 NOTE 2: TTL treatment has been chosen to permit adjacency tests 594 between two IPv4 nodes situated at both ends of a 4rd tunnel. TTL 595 values to be preserved for this are TTL=255 and TTL=1. For other 596 values, TTL decrease between to IPv4 nodes is the same as though 597 traversed IPv6 routers would be IPv4 routers. 599 Effect of this TTL treatment on IPv4 traceroute is specific: (1) the 600 number of routers of the end-to-end path includes traversed IPv6 601 routers; (2) IPv6 routers of a Domain are listed after IPv4 routers 602 of Domain entry and exit; (3) the IPv4 address shown for an IPv6 603 router is the IPv6-only dummy IPv4 address of Section 4.8; (4) the 604 response time indicated for an IPv6 router is that of the next 605 router. 607 NOTE 3: Provided the sum of obtained IPv4 addresses and protocol 608 matches Addr_Prot_Cksm. If not, the packet MUST be silently 609 discarded. 611 4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4 prefixes 612 +--------------------------------------+ 613 | CE IPv6 prefix | 614 +--------------------------+-----------+ 615 : Longest match : : 616 : with a Rule IPv6 prefix : : 617 : || : EA-bits : 618 : \/ : length : 619 +--------------------------+ | : 620 | Rule IPv6 prefix |<----'---->: 621 +--------------------------+ : 622 || : : 623 \/ : : 624 +-----------------+-----------+ 625 |Rule IPv4 prefix | EA bits | 626 +-----------------+-----------+ 627 : : 628 +-----------------------------+ 629 | CE 4rd IPv4 prefix | 630 +-----------------------------+ 631 ________/ \_________ : 632 / \ : 633 : ____:________________/ \__ 634 : / : \ 635 : =< 32 : : > 32 : 636 +----------------+ +-----------------+----+ 637 |IPv4 prfx or add| OR | IPv4 address |PSID| 638 +----------------+ +-----------------+----+ 639 : 32 : || : 640 \/ 641 (by default) (If WKPs authorized) 642 : : : : 643 +---+----+---------+ +----+-------------+ 644 Ports in |> 0|PSID|any value| OR |PSID| any value | 645 the CE port set +---+----+---------+ +----+-------------+ 646 : 4 : 12 : : 16 : 648 From CE IPv6 prefix to 4rd IPv4 address and Port set 650 Figure 4 652 R-7: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix 653 of one or several Mapping rules MUST select the CE mapping rule 654 for which the match is the longest. It then derives its 4rd 655 IPv4 prefix as shown in Figure 4: (1) the CE replaces the Rule 656 IPv6 prefix by the Rule IPv4 prefix. The result is the CE 4rd 657 IPv4 prefix. (2) If this CE 4rd IPv4 prefix has less than 32 658 bits, the CE takes it as its assigned IPv4 prefix. If it has 659 exactly 32 bits, the CE takes it as its IPv4 address. If it 660 has more than 32 bits, the CE MUST takes the first 32 bits as 661 its shared public IPv4 address, and bits beyond the first 32 as 662 its Port-set identifier (PSID). Ports of its restricted port 663 set are by default those that have any non-zero value in their 664 first 4 bits (the PSID offset), followed by the PSID, and 665 followed by any values in remaining bits. If the WKP 666 authorized option applies to the Mapping rule, there is no 667 4-bit offset before the PSID so that all ports can be assigned. 669 NOTE: The choice of the default PSID position in Port fields 670 has been guided by the following objectives: (1) for fairness, 671 avoid having any of the well-known ports 0-1023 in the port set 672 specified by any PSID value; (2) for compatibility RTP/RTCP 673 [RFC4961], include in each port set pairs of consecutive ports; 674 (3) in order to facilitate operation and training, have the 675 PSID at a fixed position in port fields; (4) in order to 676 facilitate documentation in hexadecimal notation, and to 677 facilitate maintenance, have this position nibble aligned. 678 Ports that are excluded from assignment to CEs are 0-4095 679 instead of just 0-1023 in a trade-off to favor nibble alignment 680 of PSIDs and overall simplicity. 682 R-8: A CE whose delegated IPv6 prefix has its longest match with the 683 Rule IPv6 prefix of the BR mapping rule MUST take as IPv4 684 address the 32 bit that, in the delegated IPv6 prefix, follow 685 this Rule IPv6 prefix. If this is the case while the Hub&spoke 686 option applies to the Domain, or if the Rule IPv6 prefix is not 687 a /80, there is a configuration error in the Domain. An 688 implementation-dependent administrative action MAY be taken. 690 A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix 691 of neither any CE Mapping rule nor the BR mapping rule, and is 692 in a Domain that has a NAT64+ mapping rule, MUST be noted as 693 having the unspecified IPv4 address. 695 4.5. Address Mapping from 4rd IPv4 addresses to 4rd IPv6 Addresses 696 : 32 : : 16 : \ 697 +----------------------------+ +---------------+ | 698 | IPv4 address | |Port_or_ICMP_ID| | Shared-address 699 +----------------------------+ +---+------+----+ | case 700 : Longest match : : 4 : PSID : | (PSID length 701 : with a Rule IPv4 prefix : :length: | of the rule > 0) 702 : || : : : | with WKPs 703 : \/ : : : | not authorized 704 +----------------+-----------+ +------+ | (PSID offset = 4) 705 |Rule IPv4 prefix|IPv4 suffix| | PSID | | 706 +----------------+-----------+ +------+ | 707 : || \_______ \____ | | | 708 : \/ \ \| / | 709 +--------------------------+--------+-----+ / 710 | Rule IPv6 prefix | EA bits | 711 +--------------------------+--------------+ 712 : : 713 +-----------------------------------------+ 714 | IPv6 prefix | 715 +-----------------------------------------+ 716 :\_______________________________ / \ 717 : ___________________\______/ \_______________ 718 : / \ \ 719 : / (CE mapping rule) \ (BR mapping rule) \ 720 : =<64 : : 112 : 721 +----------+---+---+------+---+ +--------------+---+------+---+ 722 |CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP| 723 +----------+-|-+---+------+---+ +--------------+---+------+---+ 724 : =<64 : | :16 : 32 :16 : : 64 :16 : 32 :16 : 725 | 726 Padding to /64 728 From 4rd IPv4 address to 4rd IPv6 address 730 Figure 5 732 R-9: BRs, and CEs that are assigned public IPv4 addresses, shared or 733 not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses by 734 the steps below or their functional equivalent (Figure 5 735 details the shared public IPv4 address case): 737 Note: the rules for forming 4rd specific Interface Identifiers 738 is obey the latest specification of [RFC7136]. "Specifications 739 of forms of 64-bit IID MUST specify how all 64 bits are set". 740 And "the whole IID value MUST be viewed as an opaque bit string 741 by third parties, except possibly in the local context." 742 (1) If Hub&spoke topology does not apply to the Domain, or if 743 it applies but the IPv6 address to be derived is a source 744 address from a CE or a destination address from a BR, find 745 the CE mapping rule whose Rule IPv4 prefix has the longest 746 match with the IPv4 address. 748 If no Mapping rule is thus obtained, take the BR mapping 749 rule. 751 If the obtained Mapping rule assigns IPv4 prefixes to CEs, 752 i.e. if length of the Rule IPv4 prefix plus EA-bits length 753 is 32 - k, with k >= 0, delete the last k bits of the IPv4 754 address. 756 Otherwise, i.e. if length of the Rule IPv4 prefix plus EA- 757 bits length is 32 + k, with k > 0, take k as PSID length, 758 and append to the IPv4 address the PSID copied from bits p 759 to p+3 of the Port_or_ICMP_ID field where: (1) p, the PSID 760 offset, is 4 by default, and 0 if the WKPs authorized 761 option applies to the rule; (2) The Port_or_ICMP_ID field 762 is in bits of the IP payload that depend on whether the 763 address is source or destination, on whether the packet is 764 ICMP or not, and, if it is ICMP, whether it is an error 765 message or an echo message. This field is: 767 a. If the packet Protocol is not ICMP, the port field 768 associated with the address (bits 0-15 for a source 769 address, and bits 16-31 for a destination address). 771 b. If the packet is an ICMPv4 echo or echo-reply message, 772 the ICMPv4 Identification field (bits 32-47 ). 774 c. If the packet is an ICMPv4 error message, the port 775 field associated with the address in the returned 776 packet header (bits 240-255 for a source address, bits 777 224-239 for a destination address). 779 NOTE 1: Using Identification fields of ICMP messages as 780 port fields permits to exchange Echo requests and Echo 781 replies between shared-address CEs and IPv4 hosts having 782 exclusive IPv4 addresses. Echo exchanges between two 783 shared-address CEs remain impossible, but this is a 784 limitation inherent to address sharing (one reason among 785 many to use IPv6). 787 NOTE 2: When the PSID is taken in the port field of the 788 IPv4 payload, it is, to avoid dependency on any particular 789 layer-4 protocol having port fields, without checking that 790 the protocol is indeed one that has a port field . A 791 packet may consequently go, in case of source mistake, 792 from a BR to a shared-address CE with a protocol that is 793 not supported by this CE. In this case, the CE NAT44 794 returns an ICMPv4 "protocol unreachable" error message. 795 The IPv4 source is thus appropriately informed of its 796 mistake. 798 (2) Replace in the result the Rule IPv4 prefix by the Rule 799 IPv6 prefix. 801 (3) If the result is shorter than a /64, append to the result 802 a null padding up to 64 bits, followed by the 4rd tag 803 (0x0300), and followed by the IPv4 address. 805 NOTE: The 4rd tag is a 4rd-specific mark. Its function is 806 to ensure that 4rd IPv6 addresses are recognizable by CEs 807 without any interference with the choice of subnet 808 prefixes in CE sites. (These choices may have been done 809 before 4rd is enabled.) 811 For this, the 4rd tag has its "u" and "g" bits of 812 [RFC4291] both set to 1, so that they maximumly differ 813 from these existing IPv6 address schemas. So far, u=g=1 814 has not been used in any IPv6 addressing architecture. 816 With the 4rd tage, IPv6 packets can be routed to the 4rd 817 function within a CE node based on a /80 prefix that no 818 native-IPv6 address can contain. 820 (4) Add to the result a Checksum-neutrality preserver (CNP). 821 Its value, in one's complement arithmetic, is the opposite 822 of the sum of 16-bit fields of the IPv6 address other than 823 the IPv4 address and the CNP themselves (i.e. 5 824 consecutive fields in address-bits 0-79). 826 NOTE: CNP guarantees that Tunnel packets are valid IPv6 827 packets for all layer-4 protocols that use the same 828 checksum algorithm as TCP. This guarantee does not depend 829 on where checksum fields of these protocols are placed in 830 IP payloads. (Today, such protocols are UDP [RFC0768], 831 TCP [RFC0793], UDP-Lite [RFC3828], and DCCP [RFC5595]. 832 Should new ones be specified, BRs will support them 833 without needing an update.) 835 R-10: 4rd-capable CE SHOULD, and 4rd-enbaled CE MUST always prohibit 836 all addresses that use its advertised prefix and have IID 837 starting with 0x0300 (4rd Tag), by using Duplicate Address 838 Detection [RFC4862]. 840 R-11: A CE that is assigned the unspecified IPv4 address (see 841 Section 4.4) MUST use, for packets tunneled between itself and 842 the Domain NAT64+, addresses as detailed in Figure 6: (a) for 843 its IPv6 source, (b) as IPv6 destinations that depend on IPv4 844 destinations. A NAT64+, being NAT64 conforming [RFC6146], MUST 845 accept IPv6 packets whose destination conforms to Figure 6 (b) 846 (4rd tag instead of "u" and 0x00 octets). In its Binding 847 Information Base, it MUST remember whether a mapping was 848 created with a "u" or 4rd-tag destination. In the IPv4 to IPv6 849 direction, it MUST use 4rd tunneling, with source address 850 conforming to Figure 6 (b), when using a mapping that was 851 created with a 4rd-tag destination. 853 +---------------------+---------+-------+-------------+------+ 854 (a) | CE IPv6 prefix | 0 |4rd tag| 0 | CNP | 855 +---------------------+---------+-------+-------------+------+ 856 : =< 64 : >= 0 : 16 : 32 : 16 : 857 4rd IPv6 address of a CE having no public IPv4 address 859 <----------- Rule IPv6 prefix --------->: 860 +-------------------------------+-------+-------------+------+ 861 (b) | NAT64+ IPv6 prefix |4rd tag|IPv4 address | CNP | 862 +-------------------------------+-------+-------------+------+ 863 : 64 : 16 : 32 : 16 : 864 4rd IPv6 address of a host reachable via a NAT64+ 866 Figure 6 868 R-12: For anti-spoofing protection, CEs and BRs MUST check that the 869 source address of each received Tunnel packet is that which, 870 according to Section 4.5, is derived from the source 4rd IPv4 871 address. For this, the IPv4 address used to obtain the source 872 4rd IPv4 address is that embedded in the IPv6 source address 873 (in its bits 80-111). (This verification is needed because 874 IPv6 ingress filtering [RFC3704] applies only to IPv6 prefixes, 875 without guarantee that Tunnel packets are built as specified in 876 Section 4.5.) 878 R-13: For additional protection against packet corruption at a link 879 layer that might be undetected at this layer during Domain 880 traversal, CEs and BRs SHOULD verify that source and 881 destination IPv6 addresses have not been modified. This can be 882 done by checking that they remain checksum neutral (see the 883 Note on CNP above). 885 4.6. Fragmentation Processing 887 4.6.1. Fragmentation at Domain Entry 889 R-14: If an IPv4 packet enters a CE or BR with a size such that the 890 derived Tunnel packet would be longer than the Domain PMTU, the 891 packet has to be either discarded or fragmented. The Domain- 892 entry node MUST discard it if the packet has DF=1, with an ICMP 893 error message returned to the source. It MUST fragment it 894 otherwise, with the payload of each fragment not exceeding PMTU 895 - 48. The first fragment has its offset equal to the received 896 offset. Following fragments have offsets increased by lengths 897 of previous-fragments payloads. Functionally, fragmentation is 898 supposed to be done in IPv4 before applying to each fragment 899 the reversible header translation of Section 4.3. 901 4.6.2. Ports of Fragments addressed to Shared-Address CEs 903 Because ports are available only in first fragments of IPv4 904 fragmented packets, a BR needs a mechanism to send to the right 905 shared-address CEs all fragments of fragmented packets. 907 For this, a BR MAY systematically reassemble fragmented IPv4 packets 908 before tunneling them. But this consumes large memory space, opens 909 denial-of-service-attack opportunities, and can significantly 910 increase forwarding delays. This is the reason for the following 911 requirement: 913 R-15: BRs SHOULD support an algorithm whereby received IPv4 packets 914 can be forwarded on the fly. The following is an example of 915 such algorithm: 917 (1) At BR initialization, if at least one CE mapping rule 918 concerns shared public IPv4 addresses (length of Rule IPv4 919 prefix + EA-bits length > 32), the BR initializes an empty 920 "IPv4-packet table" whose entries have the following 921 items: 923 - IPv4 source 925 - IPv4 destination 927 - IPv4 identification 929 - Destination port 931 (2) When the BR receives an IPv4 packet whose matching Mapping 932 rule is one of shared public IPv4 addresses (length of 933 Rule IPv4 prefix + EA-bits length > 32), the BR searches 934 the table for an entry whose IPv4 source, IPv4 935 destination, and IPv4 Identification, are those of the 936 received packet. The BR then performs actions detailed in 937 Table 5 depending on which conditions hold. 939 +---------------------------+---+---+---+---+---+---+---+---+ 940 | - CONDITIONS - | | | | | | | | | 941 | First Fragment (offset=0) | Y | Y | Y | Y | N | N | N | N | 942 | Last fragment (MF=0) | Y | Y | N | N | Y | Y | N | N | 943 | An entry has been found | Y | N | Y | N | Y | N | Y | N | 944 | ------------------------- | | | | | | | | | 945 | - RESULTING ACTIONS - | | | | | | | | | 946 | Create a new entry | - | - | - | X | - | - | - | - | 947 | Use port of the entry | - | - | - | - | X | - | X | - | 948 | Update port of the entry | - | - | X | - | - | - | - | - | 949 | Delete the entry | X | - | - | - | X | - | - | - | 950 | Forward the packet | X | X | X | X | X | - | X | - | 951 +---------------------------+---+---+---+---+---+---+---+---+ 953 Table 5 955 (3) The BR performs garbage collection for table entries that 956 remain unchanged for longer than some limit. This limit, 957 normally longer that the maximum time normally needed to 958 reassemble a packet is not critical. It should however not 959 be longer than 15 seconds [RFC0791]. 961 R-16: For the above algorithm to be effective, CEs that are assigned 962 shared public IPv4 addresses MUST NOT interleave fragments of 963 several fragmented packets. 965 R-17: CEs that are assigned IPv4 prefixes, and are in nodes that 966 route public IPv4 addresses rather than only using NAT44s, MUST 967 have the same behavior as described just above for BRs. 969 4.6.3. Packet Identifications from Shared-Address CEs 971 When packets go from CEs that share the same IPv4 address to a common 972 destination, a precaution is needed to guarantee that packet 973 Identifications set by sources are different. Otherwise, packet 974 reassembly at destination could otherwise be confused because it is 975 based only on source IPv4 address and Identification. Probability of 976 such confusions may in theory be very low but, in order to avoid 977 creating new attack opportunities, a safe solution is needed. 979 R-18: A CE that is assigned a shared public IPv4 address MUST only 980 use packet Identifications that have the CE PSID in their bits 981 0 to PSID length - 1. 983 R-19: A BR or a CE that receives a packet from a shared-address CE 984 MUST check that bits 0 to PSID length - 1 of their packet 985 Identifications are equal to the PSID found in source 4rd IPv4 986 address. 988 4.7. TOS and Traffic-Class Processing 990 IPv4 TOS and IPv6 Traffic class have the same semantic, that of the 991 differentiated-services field, or DS field, specified in [RFC2474] 992 and [RFC6040]. Their first 6 bits contain a differentiated services 993 codepoint (DSCP), and their two last bits can convey explicit 994 congestion notifications (ECNs), which both may evolve during Domain 995 traversal. [RFC2983] discusses how the DSCP can be handled by tunnel 996 end points. The Tunnel traffic class option permits to ignore DS- 997 field evolutions occurring during Domain traversal, if the desired 998 behavior is that of generic tunnels conforming to [RFC2473]. 1000 R-20: Unless the Tunnel traffic class option is configured for the 1001 Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6 1002 Traffic class at Domain entry, and copy back the IPv6 Traffic 1003 class into the IPv4 TOS at Domain exit. 1005 R-21: If the Tunnel traffic class option is configured for a Domain, 1006 BRs and CEs MUST at Domain entry take the configured Tunnel 1007 traffic class as IPv6 Traffic class, and copy the received IPv4 1008 TOS into the IPv4_TOS of the fragment header (Figure 3). At 1009 Domain exit, they MUST copy back the IPv4_TOS of the fragment 1010 header into the IPv4 TOS. 1012 4.8. Tunnel-Generated ICMPv6 Error Messages 1014 If a Tunnel packet is discarded on its way across a 4rd domain 1015 because of an unreachable destination, an ICMPv6 error message is 1016 returned to the IPv6 source. For the IPv4 source of the discarded 1017 packet to be informed of packet loss, the ICMPv6 message has to be 1018 converted into an ICMPv4 message. 1020 R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it 1021 MUST synthesize an ICMPv4 error packet [RFC0792]. This packet 1022 MUST contain the first 8 octets of the discarded-packet IP 1023 payload. The reserved IPv4 dummy address (TBD, (see Section 6) 1024 MUST be used as its source address . 1026 Like in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination 1027 unreachable, No route to destination") MUST be translated into 1028 ICMPv4 Type = 3 and Code = 0 (Destination unreachable, Net 1029 unreachable), and ICMPv6 Type = 3 and Code = 0 (Time exceeded, 1030 Hop limit exceeded in transit) MUST be translated into ICMPv4 1031 Type = 11 and Code = 0 (Destination unreachable, Net 1032 unreachable). 1034 4.9. Provisioning 4rd Parameters to CEs 1036 Domain parameters listed in Section 4.2 are subject to the following 1037 constraints: 1039 R-23: Each Domain MUST have a BR mapping rule and/or a NAT64+ mapping 1040 rule. (The BR mapping rule is only used by CEs that are 1041 assigned public IPv4 addresses, shared or not. The NAT64+ 1042 mapping rule is only used by CEs that are assigned the 1043 unspecified IPv4 address (Section 4.4), and therefore need an 1044 ISP NAT64 to reach IPv4 destinations. 1046 R-24: Each CE and each BR MUST support up to 32 Mapping rules. 1048 This number of is to ensure that independently acquired CEs an 1049 BR nodes can always interwork. 1051 ISPs that need Mapping rules for more IPv4 prefixes than this 1052 number SHOULD split their networks into multiple Domains. 1053 Communication between these domains can be done in IPv4, or by 1054 some implementation-dependent but equivalent other means. 1056 R-25: For mesh topologies, where CE-CE paths don't go via BRs, all 1057 mapping rules of the Domain MUST be sent to all CEs. For hub- 1058 and-spoke topologies, where all CE-CE paths go via BRs, each CE 1059 MAY be sent only the BR mapping rule of the Domain plus, if 1060 different, the CE mapping rule that applies to its CE IPv6 1061 prefix. 1063 R-26: In a Domain where the chosen topology is Hub&spoke, all CEs 1064 MUST have IPv6 prefixes that match a CE mapping rule. 1065 (Otherwise, packets sent to CEs whose IPv6 prefixes would match 1066 only the BR mapping rule would, with longest-match selected 1067 routes, be routed directly to these CEs. This would be 1068 contrary to the Hub&spoke requirement). 1070 R-27: CEs MUST be able to acquire parameters of 4rd domains 1071 (Section 4.2) in DHCPv6 (ref. [RFC2131]). Formats of DHCPv6 1072 options to be used are detailed in Figure 7, Figure 8, and 1073 Figure 9 with field values specified after each Figure. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | option-code = OPTION_4RD | option-length | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | encapsulated 4rd rule options | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 DHCPv6 option for 4rd 1085 Figure 7 1087 o option-code: TBD1, OPTION_4RD (see Section 6) 1089 o option-length: the length of encapsulated options in octets 1091 o encapsulated 4rd rule options: the 4RD DHCPv6 option contains at 1092 least one encapsulated 4RD_MAP_RULE option and maximum one 1093 encapsulated 4RD_NON_MAP_RULE option. Since DHCP servers normally 1094 send whatever options the operator configures, operators should be 1095 advised to configure these options appropriately. DHCP servers 1096 MAY check to see that the configuration follows these rules and 1097 notify the operator in an implementation-dependent manner if the 1098 settings for these options aren't valid. The length of 1099 encapsulated options is in octets. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | option = 4RD_MAP_RULE | option-length | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | prefix4-len | prefix6-len | ea-len |W| Reserved | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | rule-ipv4-prefix | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | | 1111 + + 1112 | rule-ipv6-prefix | 1113 + + 1114 | | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Encapsulated option for Mapping-rule parameters 1119 Figure 8 1121 o option-code: TBD2, encapsulated 4RD_MAP_RULE option (see 1122 Section 6) 1124 o option-length: 20 1126 o prefix4-len: number of bits of the Rule IPv4 prefix 1128 o prefix6-len: number of bits of the Rule IPv6 prefix 1130 o ea-len: EA-bits length 1132 o W: WKP authorized, = 1 if set 1134 o rule-ipv4-prefix: the Rule IPv4 prefix, left aligned 1136 o rule-ipv6-prefix: Rule IPv6 prefix, left aligned 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | option = 4RD_NON_MAP_RULE | option-length | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |H| 0 |T| traffic-class | domain-pmtu | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 Encapsulated option for non-mapping-rule parameters of 4rd-domains 1148 Figure 9 1150 o option-code: TBD3, encapsulated 4RD_NON_MAP_RULE option (see 1151 Section 6) 1153 o option-length: 4 1155 o H: Hub&spoke topology (= 1 if Yes) 1157 o T: Traffic-class flag (= 1 if a Tunnel traffic class is provided) 1159 o traffic-class: Tunnel-traffic class 1161 o domain-pmtu: Domain PMTU (at least 1280) 1163 Other means than DHCPv6 that may prove useful to provide 4rd 1164 parameters to CEs are off-scope for this document. The same or 1165 similar parameter formats would however be recommended to facilitate 1166 training and operation. 1168 5. Security Considerations 1170 Spoofing attacks 1172 With IPv6 ingress filtering effective in the Domain [RFC3704], and 1173 with consistency checks between 4rd IPv4 and IPv6 addresses of 1174 Section 4.5, no spoofing opportunity in IPv4 is introduced by 4rd. 1176 Routing-loop attacks 1178 Routing-loop attacks that may exist in some automatic-tunneling 1179 scenarios are documented in [RFC6324]. No opportunity for 1180 routing-loop attacks has been identified with 4rd. 1182 Fragmentation-related attacks 1184 As discussed in Section 4.6, each BR of a Domain that assigns 1185 shared public IPv4 should maintain a dynamic table for fragmented 1186 packets that go to these shared-address CEs. 1188 This opens a BNR vulnerability to a denial of service attack from 1189 hosts that would send very large numbers of first fragments and 1190 would never send last fragments having the same packet 1191 identifications. This vulnerability is inherent to IPv4 address 1192 sharing, be it static or dynamic. Compared to what it is with 1193 algorithms that reassemble IPv4 packets in BRs, it is however 1194 significantly mitigated by the algorithm of Section 4.6.2 which 1195 uses much less memory space. 1197 6. IANA Considerations 1199 IANA is requested to allocate the following: 1201 o One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9 1202 respectively (to be added to section 24.3 of [RFC3315]. 1203 Encapsulated options of OPTION_4RD, 4RD_MAP_RULE (TBD2) and 1204 4RD_NON_MAP_RULE (TBD3) should also be recorded into the DHCPv6 1205 option code space. 1207 Value | Description | Reference 1208 -----------+------------------+--------------- 1209 TBD1 | OPTION_4RD | this document 1210 TBD2 | 4RD_MAP_RULE | this document 1211 TBD3 | 4RD_NON_MAP_RULE | this document 1213 o A reserved IPv4 address to be used as the "IPv4 dummy address" of 1214 Section 4.8. Its proposed value is 192.0.0.8/32 (Section 4.8). 1216 7. Relationship with Previous Works 1218 The present specification has been influenced by many previous IETF 1219 drafts, in particular those accessible at http://tools.ietf.org/html/ 1220 draft-xxxx where xxxx are the following (in order of their first 1221 versions): 1223 o bagnulo-behave-nat64 (2008-06-10) 1225 o xli-behave-ivi (2008-07-06) 1227 o despres-sam-scenarios (2008-09-28) 1229 o boucadair-port-range (2008-10-23) 1231 o ymbk-aplusp (2008-10-27) 1233 o xli-behave-divi (2009-10-19) 1235 o thaler-port-restricted-ip-issues (2010-02-28) 1237 o cui-softwire-host-4over6 (2010-05-05) 1239 o xli-behave-divi-pd (2011-07-02) 1241 o dec-stateless-4v6 (2011-03-05) 1243 o matsushima-v6ops-transition-experience (2011-03-07) 1244 o despres-intarea-4rd (2011-03-07) 1246 o deng-aplusp-experiment-results (2011-03-08) 1248 o murakami-softwire-4rd (2011-07-04) 1250 o operators-softwire-stateless-4v6-motivation (2011-05-05) 1252 o murakami-softwire-4v6-translation (2011-07-04) 1254 o despres-softwire-4rd-addmapping (2011-08-19) 1256 o boucadair-softwire-stateless-requirements (2011-09-08) 1258 o chen-softwire-4v6-add-format (2011-10-2) 1260 o mawatari-softwire-464xlat (2011-10-16) 1262 o mdt-softwire-map-dhcp-option (2011-10-24) 1264 o mdt-softwire-mapping-address-and-port (2011-11-25) 1266 o mdt-softwire-map-translation (2012-01-10) 1268 o mdt-softwire-map-encapsulation (2012-01-27) 1270 8. Acknowledgements 1272 This specification has benefited over several years from independent 1273 proposals, questions, comments, constructive suggestions, and useful 1274 criticisms, coming from numerous IETF contributors. 1276 Authors would like to express recognition to all these contributors, 1277 and more especially to the following, in alphabetical order of first 1278 names: Brian Carpenter, Behcet Sarikaya, Bing Liu, Cameron Byrne, 1279 Congxiao Bao, Dan Wing, Erik Kline, Francis Dupont, Gabor Bajko, Gang 1280 Chen, Hui Deng, Jan Zorz, Jacni Quin (who was an active co-author of 1281 some earlier versions of this specification), James Huang, Jari 1282 Arkko, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Mark Townsley, 1283 Marcello Bagnulo, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole 1284 Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, 1285 Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, 1286 Teemu Savolainen, Tetsuya Murakami, Tomasz Mrugalski, Tina Tsou, 1287 Tomasz Mrugalski, Ted Lemon, Suresh Krishnan, Washam Fan, Wojciech 1288 Dec, Xiaohong Deng, Xing Li, Yu Fu. 1290 9. References 1292 9.1. Normative References 1294 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1295 1981. 1297 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1298 RFC 792, September 1981. 1300 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1301 793, September 1981. 1303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1304 Requirement Levels", BCP 14, RFC 2119, March 1997. 1306 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1307 2131, March 1997. 1309 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1310 (IPv6) Specification", RFC 2460, December 1998. 1312 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1313 "Definition of the Differentiated Services Field (DS 1314 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1315 1998. 1317 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 1318 2983, October 2000. 1320 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1321 and M. Carney, "Dynamic Host Configuration Protocol for 1322 IPv6 (DHCPv6)", RFC 3315, July 2003. 1324 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1325 Architecture", RFC 4291, February 2006. 1327 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1328 Message Protocol (ICMPv6) for the Internet Protocol 1329 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1331 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1332 Address Autoconfiguration", RFC 4862, September 2007. 1334 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1335 Problem Statement", RFC 4925, July 2007. 1337 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1338 Pignataro, "The Generalized TTL Security Mechanism 1339 (GTSM)", RFC 5082, October 2007. 1341 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1342 Notification", RFC 6040, November 2010. 1344 9.2. Informative References 1346 [I-D.ietf-softwire-stateless-4v6-motivation] 1347 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 1348 Borges, I., and G. Chen, "Motivations for Carrier-side 1349 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 1350 softwire-stateless-4v6-motivation-05 (work in progress), 1351 November 2012. 1353 [I-D.shirasaki-nat444] 1354 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1355 and H. Ashida, "NAT444", draft-shirasaki-nat444-06 (work 1356 in progress), July 2012. 1358 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1359 August 1980. 1361 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1362 November 1990. 1364 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1365 E. Lear, "Address Allocation for Private Internets", BCP 1366 5, RFC 1918, February 1996. 1368 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1369 IPv6 Specification", RFC 2473, December 1998. 1371 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1372 Address Translator (Traditional NAT)", RFC 3022, January 1373 2001. 1375 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1376 Networks", BCP 84, RFC 3704, March 2004. 1378 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1379 G. Fairhurst, "The Lightweight User Datagram Protocol 1380 (UDP-Lite)", RFC 3828, July 2004. 1382 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1383 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1385 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1386 Discovery", RFC 4821, March 2007. 1388 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1389 BCP 131, RFC 4961, July 2007. 1391 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1392 (DCCP) Service Codes", RFC 5595, September 2009. 1394 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1395 Infrastructures (6rd) -- Protocol Specification", RFC 1396 5969, August 2010. 1398 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1399 Algorithm", RFC 6145, April 2011. 1401 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1402 NAT64: Network Address and Protocol Translation from IPv6 1403 Clients to IPv4 Servers", RFC 6146, April 2011. 1405 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1406 IPv6 Automatic Tunnels: Problem Statement and Proposed 1407 Mitigations", RFC 6324, August 2011. 1409 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1410 IPv4 Address Shortage", RFC 6346, August 2011. 1412 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1413 "IPv6 Flow Label Specification", RFC 6437, November 2011. 1415 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 1416 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 1418 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1419 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1420 2013. 1422 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 1423 Interface Identifiers", RFC 7136, February 2014. 1425 Appendix A. Textual representation of Mapping rules 1427 In the next sections, each Mapping rule will be represented as 1428 follows, using 0bXXX to represent binary number XXX, and square 1429 brackets [ ] for what is optional: 1431 {Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix 1432 [, WKPs authorized]} 1434 EXAMPLES: 1435 {0.0.0.0/0, 32, 2001:db8:0:1:300::/80} 1436 a BR mapping rule 1437 {198.16.0.0/14, 22, 2001:db8:4000::/34} 1438 a CE mapping rule 1439 {0.0.0.0/0, 32, 2001:db8:0:1::/80} 1440 a NAT64+ mapping rule) 1441 {198.16.0.0/14, 22, 2001:db8:4000::/34, Yes} 1442 a CE mapping rule and Hub&spoke Topology 1444 Appendix B. Configuring multiple Mapping Rules 1446 As far as mapping rules are concerned, the simplest deployment model 1447 is that in which the Domain has only one rule (the BR mapping rule). 1448 To assign an IPv4 address to a CE in this model, an IPv6 /112 is 1449 assigned to it comprising the BR /64 prefix, the 4rd tag, and the 1450 IPv4 address. This model has however the following limitations: (1) 1451 shared IPv4 addresses are not supported; (2) IPv6 prefixes used for 1452 4rd are too long to be used also for native IPv6 addresses; (3) if 1453 the IPv4 address space of the ISP is split with many disjoint IPv4 1454 prefixes, the IPv6 routing plan must be as complex as an IPv4 routing 1455 plan based on these prefixes. 1457 With more mapping rules, CE prefixes used for 4rd can be those used 1458 for native IPv6. How to choose CE mapping rules for a particular 1459 deployment needs not being standardized. 1461 The following is only a particular pragmatic approach that can be 1462 used for various deployment scenarios. It is used in some of the use 1463 cases that follow. 1465 (1) Select a "Common_IPv6_prefix" that will appear at the beginning 1466 of all 4rd CE IPv6 prefixes. 1468 (2) Choose all IPv4 prefixes to be used, and assign one of them to 1469 each CE mapping rule i. 1471 (3) For each CE mapping rule i, do the following: 1473 A. choose the length of its Rule IPv6 prefix (possibly the same 1474 for all CE mapping rules). 1476 B. Determine its PSID_length(i). A CE mapping rule that 1477 assigns shared addresses with a sharing ratio 2^Ki, has 1478 PSID_length = Ki. A CE mapping rule rule that assigns IPv4 1479 prefixes of length L < 32, is considered to have a negative 1480 PSID_length = L - 32. 1482 C. Derive EA-bits length (i) = 32 - L(Rule IPv4 prefix(i)) + 1483 PSID_length(i). 1485 D. Derive the length of Rule_code(i), the prefix to be appended 1486 to the Common prefix to get the Rule IPv6 prefix of rule i: 1488 L(Rule_code(i)) = L(CE IPv6 prefix(i)) 1489 - L(Common_IPv6_prefix] 1490 - (32 - L(Rule IPv4 prefix(i))) 1491 - PSID_length(i) 1493 E. Derive Rule_code(i) with the following constraints: (1) its 1494 length is L(Rule_code(i); it does not overlap with any of 1495 the previously obtained Rule codes (for instance, 010, and 1496 01011 do overlap, while 00, 011, and 010 do not); it has the 1497 lowest possible value as a fractional binary number (for 1498 instance, 0100 < 10 < 11011 < 111). Thus, rules whose 1499 Rule_code lengths are 4, 3 , 5, and 2, give Rule_codes 0000, 1500 001, 00010, and 01) 1502 F. Take Rule IPv6 prefix(i)= the Common_IPv6_prefix followed by 1503 Rule_code(i). 1505 :<--------------------- L(CE IPv6 prefix(i)) --------------------->: 1506 : : 1507 : 32 - L(Rule IPv4 prefix(i)) PSID_length(i): 1508 : \ | : 1509 : :<---------'--------><--'-->: 1510 : : || : 1511 : : \/ : 1512 : :<------->:<--- EA-bits length(i) --->: 1513 : L(Rule code(i)) 1514 : : : 1515 +----------------------------+---------+ 1516 | Common IPv6 prefix |Rule code| 1517 | | (i) | 1518 +----------------------------+---------+ 1519 :<------ L(Rule IPv6 prefix(i)) ------>: 1521 Figure 10 1523 Appendix C. ADDING SHARED IPv4 ADDRESSES TO AN IPv6 NETWORK 1525 C.1. With CEs within CPEs 1527 We consider an ISP that offers IPv6-only service to up to 2^20 1528 customers. Each customer is delegated a /56, starting with common 1529 prefix 2001:db8:0::/36. It wants to add public IPv4 service to 1530 customers that are 4rd-capable. It prefers to do it with stateless 1531 operation in its nodes, but has largely less IPv4 addresses than IPv6 1532 addresses so that a sharing ratio is necessary. 1534 The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16, 1535 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor 1536 aggregetable). This gives 2^(32-15) + 3*2^(32-16) IPv4 addresses, 1537 i.e. 2^18 + 2^16). For the 2^20 customers to have the same sharing 1538 ratio, the number of IPv4 addresses to be shared has to be a power of 1539 2. The ISP can therefore renounce to use one /16, say the last one. 1540 (Whether it could be motivated to return it to its Internet Registry 1541 is off-scope for this document.) The sharing ratio to apply is then 1542 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2. 1544 Applying principles of Appendix B with L[Common IPv6 prefix] = 36, 1545 L[PSID] = 2 for all rules, and L[CE IPv6 prefix(i)] = 56 for all 1546 rules, Rule codes and Rule IPv6 prefixes are: 1548 +--------------+--------+-----------+-----------+-------------------+ 1549 | CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 | 1550 | prefix | bits | length | (binary) | prefix | 1551 | | length | | | | 1552 +--------------+--------+-----------+-----------+-------------------+ 1553 | 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 | 1554 | 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 | 1555 | 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 | 1556 +--------------+--------+-----------+-----------+-------------------+ 1558 Mapping rules are then the following: 1560 {192.8.0.0/15, 19, 2001:0db8:0000::/37} 1561 {192.4.0.0/16, 18, 2001:0db8:0800::/38} 1562 {192.2.0.0/16, 18, 2001:0db8:0c00::/38} 1563 {0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80} 1565 The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56, 1566 derives its IPv4 address and its port set as follows (Section 4.4): 1568 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 1569 Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match) 1570 EA-bits length(i) : 18 1571 EA bits : 0b11 1011 1011 1011 1011 1572 Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16) 1573 IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110 1574 : 192.4.238.238 1575 PSID : 0b11 1576 Ports : 0bYYYY 11XX XXXX XXXX 1577 with YYYY > 0, and X...X any value 1579 An IPv4 packet sent to address 192.4.238.238 and port 7777 is 1580 tunneled to the IPv6 address obtained as follows (Section 4.5): 1582 IPv4 address : 192.4.238.238 (0xC004 EEEE) 1583 : 0b1100 0000 0000 0100 1110 1110 1110 1110 1584 Rule IPv4 prefix(i): 192.4.0.0/16 (longest match) 1585 : 0b1100 0000 0000 0100 1586 IPv4 suffix (i) : 0b1110 1110 1110 1110 1587 EA-bits length (i) : 18 1588 PSID length (i) : 2 (= 16 + 18 - 32) 1589 Port field : 0b 0001 1110 0110 0001 (7777) 1590 PSID : 0b11 1591 Rule IPv6 prefix(i): 2001:0db8:0800::/38 1592 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 1593 IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY 1594 with YYYY = the computed CNP 1596 C.2. With some CEs behind Third-party Router CPEs 1598 We now consider an ISP that has the same need as in the previous 1599 section except that, instead of using only its own IPv6 1600 infrastructure, it uses that of a third-party provider, and that some 1601 of its customers use CPEs of this provider to use specific services 1602 it offers. In these CPEs, a non-zero index is used to route IPv6 1603 packets to the physical port to which CEs are attached, say 0x2. 1604 Each such CPE delegates to the CE nodes the customer-site IPv6 prefix 1605 followed by this index. 1607 The ISP is supposed to have the same IPv4 prefixes as in the previous 1608 use case, 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16, and to use 1609 the same Common IPv6 prefix, 2001:db8:0::/36. 1611 We also assume that only a minority of customers use third-party 1612 CPEs, so that it is sufficient to use only one of the two /16s for 1613 them. 1615 Mapping rules, are then (see Appendix C.1): 1617 {192.8.0.0/15, 19, 2001:0db8:0000::/37} 1618 {192.4.0.0/16, 18, 2001:0db8:0800::/38} 1619 {192.2.0.0/16, 18, 2001:0db8:0c00::/38} 1620 {0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80} 1622 CEs that are behind third-party CPEs derive their own IPv4 addresses 1623 and port sets as in Appendix C.1. 1625 In a BR, and also in a CE if the topology is mesh, the IPv6 address 1626 that is derived from IPv4 address 192.4.238.238 and port 7777 is 1627 obtained as in the previous section, except for the two last steps 1628 which are modified: 1630 IPv4 address : 192.4.238.238 (0xC004 EEEE) 1631 : 0b1100 0000 0000 0100 1110 1110 1110 1110 1632 Rule IPv4 prefix(i): 192.4.0.0/16 (longest match) 1633 : 0b1100 0000 0000 0100 1634 IPv4 suffix (i) : 0b1110 1110 1110 1110 1635 EA-bits length (i) : 18 1636 PSID length (i) : 2 (= 16 + 18 - 32) 1637 Port field : 0b 0001 1110 0110 0001 (7777) 1638 PSID : 0b11 1639 Rule IPv6 prefix(i): 2001:0db8:0800::/38 1640 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60 1641 IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY 1642 with YYYY = the computed CNP 1644 Appendix D. REPLACING DUAL-STACK ROUTING BY IPv6-ONLY ROUTING 1646 In this use case, we consider an ISP that offers IPv4 service with 1647 public addresses individually assigned to its customers. It also 1648 offers IPv6 service, having deployed for this dual-stack routing. 1649 Because it provides its own CPEs to customers, it can upgrade all its 1650 CPEs to support 4rd. It wishes to take advantage of this capability 1651 to replace dual-stack routing by IPv6-only routing without changing 1652 any IPv4 address or IPv6 prefix. 1654 For this, the ISP can use the single-rule model described at the 1655 beginning of Appendix B. If the prefix routed to BRs is chosen to 1656 start with 2001:db8:0:1::/64, this rule is: 1658 {0.0.0.0/0, 32, 2001:db8:0:1:300::/80} 1660 All what is needed in the network before disabling IPv4 routing is 1661 the following: 1663 o In all routers, where there is an IPv4 route toward x.x.x.x/n, add 1664 a parallel route toward 2001:db8:0:1:300:x.x.x.x::/(80+n) 1666 o Where IPv4 address x.x.x.x was assigned to a CPE, now delegate 1667 IPv6 prefix 2001:db8:0:1:300:x.x.x.x::/112. 1669 NOTE: In parallel with this deployment, or after it, shared IPv4 1670 addresses can be assigned to IPv6 customers. It is sufficient that 1671 IPv4 prefixes used for this be different from those used for 1672 exclusive-address assignments. Under this constraint, Mapping rules 1673 can be set up according to the same principles as those of 1674 Appendix C. 1676 Appendix E. ADDING IPv6 AND 4rd SERVICE TO A NET-10 NETWORK 1678 In this use case, we consider an ISP that has only deployed IPv4, 1679 possibly because some of its network devices are not yet IPv6 1680 capable. Because it did not have enough IPv4 addresses, it has 1681 assigned private IPv4 addresses of [RFC1918] to customers, say 1682 10.x.x.x. It thus supports up to 2^24 customers (a "Net-10" network, 1683 using the NAT444 model of [I-D.shirasaki-nat444]). 1685 Now, it wishes to offer IPv6 service without further delay, using for 1686 this 6rd [RFC5969]. It also wishes to offer incoming IPv4 1687 connectivity to its customers with a simpler solution than that of 1688 PCP [RFC6887]. 1690 This appendix describes an example that adds IPv6 (using 6rd) and 4rd 1691 services to the "Net-10" private IPv4 network. 1693 The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32, 1694 and the public IPv4 prefix to be used for shared addresses is 1695 supposed to be 198.16.0.0/16 (0xc610). The resulting sharing ratio 1696 is 2^24 / 2^(32-16) = 256, giving a PSID length of 8. 1698 The ISP installs one or several BRs, at its border to the public IPv4 1699 Internet. They support 6rd, and 4rd above it. The BR prefix /64 is 1700 supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e. 1701 2001:db8:0:100:/64). 1703 In accordance with [RFC5969], 6rd BRs are configured with the 1704 following parameters IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32; 1705 6rdBRIPv4Address = 192.168.0.1 (0xC0A80001). 1707 4rd Mapping rules are then the following: 1709 {198.16.0.0/16, 24, 2001:db8:0:0:300::/80} 1710 {0.0.0.0/0, 32, 2001:db8:0:100:300:/80,} 1712 Any customer device that supports 4rd in addition to 6rd can then use 1713 its assigned shared IPv4 address with 240 assigned ports. 1715 If its NAT44 supports port forwarding to provide incoming IPv4 1716 connectivity (statically, or dynamically with UPnP an/or NAT-PMP), it 1717 can use it with ports of the assigned port set (a possibility that 1718 does not exist in Net-10 networks without 4rd/6rd). 1720 Authors' Addresses 1722 Remi Despres 1723 RD-IPtech 1724 3 rue du President Wilson 1725 Levallois 1726 France 1728 Email: despres.remi@laposte.net 1730 Sheng Jiang (editor) 1731 Huawei Technologies Co., Ltd 1732 Q14, Huawei Campus, No.156 BeiQing Road 1733 Hai-Dian District, Beijing 100095 1734 P.R. China 1736 Email: jiangsheng@huawei.com 1738 Reinaldo Penno 1739 Cisco Systems, Inc. 1740 170 West Tasman Drivee 1741 San Jose, California 95134 1742 USA 1744 Email: repenno@cisco.com 1746 Yiu Lee 1747 Comcast 1748 One Comcast Center 1749 Philadelphia, PA 1903 1750 USA 1752 Email: Yiu_Lee@Cable.Comcast.com 1753 Gang Chen 1754 China Mobile 1755 53A, Xibianmennei Ave. 1756 Xuanwu District, Beijing 100053 1757 China 1759 Email: phdgang@gmail.com 1761 Maoke Chen 1762 Freebit Co, Ltd. 1763 13F E-space Tower, Maruyama-cho 3-6 1764 Shibuya-ku, Tokyo 150-0044 1765 Japan 1767 Email: fibrib@gmail.com