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