RFC 7600
IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
4.6. Fragmentation Processing
4.6.1. Fragmentation at Domain Entry
R-14: If an IPv4 packet enters a CE or BR with a size such that the derived Tunnel packet would be longer than the Domain PMTU, the packet has to be either discarded or fragmented. The Domain-entry node MUST discard it if the packet has DF = 1, with an ICMP error message returned to the source. It MUST fragment it otherwise, with the payload of each fragment not exceeding PMTU - 48. The first fragment has its offset equal to the received offset. Subsequent fragments have offsets increased by the lengths of the payloads of previous fragments. Functionally, fragmentation is supposed to be done in IPv4 before applying reversible header translation to each fragment; see Section 4.3.
4.6.2. Ports of Fragments Addressed to Shared-Address CEs
Because ports are available only in the first fragments of IPv4 fragmented packets, a BR needs a mechanism to send to the right shared-address CEs all fragments of fragmented packets. For this, a BR MAY systematically reassemble fragmented IPv4 packets before tunneling them. But this consumes large memory space, creates opportunities for denial-of-service-attacks, and can significantly increase forwarding delays. This is the reason for the following requirement: R-15: BRs SHOULD support an algorithm whereby received IPv4 packets can be forwarded on the fly. The following is an example of such an algorithm: (1) At BR initialization, if at least one CE Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR initializes an empty "IPv4 packet table" whose entries have the following items: - IPv4 source - IPv4 destination - IPv4 identification - Destination port (2) When the BR receives an IPv4 packet whose matching Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR searches the table for an entry whose IPv4 source, IPv4 destination, and IPv4 identification are those of the received packet. The BR then performs actions as detailed in Table 5, depending on which conditions hold.
+-----------------------------+---+---+---+---+---+---+---+---+ | - CONDITIONS - | | | | | | | | | | First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N | | Last fragment (MF = 0) | Y | Y | N | N | Y | Y | N | N | | An entry has been found | Y | N | Y | N | Y | N | Y | N | | ------------------------- | | | | | | | | | | - RESULTING ACTIONS - | | | | | | | | | | Create a new entry | - | - | - | X | - | - | - | - | | Use port of the entry | - | - | - | - | X | - | X | - | | Update port of the entry | - | - | X | - | - | - | - | - | | Delete the entry | X | - | - | - | X | - | - | - | | Forward the packet | X | X | X | X | X | - | X | - | +-----------------------------+---+---+---+---+---+---+---+---+ Table 5: BR Actions (3) The BR performs garbage collection for table entries that remain unchanged for longer than some limit. This limit, which is normally longer than the maximum time normally needed to reassemble a packet, is not critical. It should not, however, be longer than 15 seconds [RFC791]. R-16: For the above algorithm to be effective, CEs that are assigned shared public IPv4 addresses MUST NOT interleave fragments of several fragmented packets. R-17: CEs that are assigned IPv4 prefixes and are in nodes that route public IPv4 addresses rather than only using NAT44s MUST have the same behavior as that described just above for BRs.
4.6.3. Packet Identifications from Shared-Address CEs
When packets go from CEs that share the same IPv4 address to a common destination, a precaution is needed to guarantee that packet identifications set by sources are different. Otherwise, packet reassembly at the destination could be confused because it is based only on source IPv4 address and Identification. The probability of such confusing situations may in theory be very low, but a safe solution is needed in order to avoid creating new attack opportunities. R-18: A CE that is assigned a shared public IPv4 address MUST only use packet identifications that have the CE PSID in their bits 0 to PSID length - 1. R-19: A BR or a CE that receives a packet from a shared-address CE MUST check that bits 0 to PSID length - 1 of their packet identifications are equal to the PSID found in the source 4rd IPv4 address.4.7. TOS and Traffic Class Processing
IPv4 TOS and IPv6 traffic class have the same semantic, that of the differentiated services field, or DS field, specified in [RFC2474] and [RFC6040]. Their first 6 bits contain a differentiated services codepoint (DSCP), and their last 2 bits can convey explicit congestion notifications (ECNs), which both may evolve during Domain traversal. [RFC2983] discusses how the DSCP can be handled by tunnel endpoints. The Tunnel Traffic Class option provides permission to ignore DS-field evolutions occurring during Domain traversal, if the desired behavior is that of generic tunnels conforming to [RFC2473]. R-20: Unless the Tunnel Traffic Class option is configured for the Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6 traffic class at Domain entry and copy back the IPv6 traffic class into the IPv4 TOS at Domain exit. R-21: If the Tunnel Traffic Class option is configured for a Domain, BRs and CEs MUST at Domain entry take the configured Tunnel Traffic Class as the IPv6 traffic class and copy the received IPv4 TOS into the IPv4_TOS of the fragment header (Figure 3). At Domain exit, they MUST copy back the IPv4_TOS of the fragment header into the IPv4 TOS.
4.8. Tunnel-Generated ICMPv6 Error Messages
If a Tunnel packet is discarded on its way across a 4rd domain because of an unreachable destination, an ICMPv6 error message is returned to the IPv6 source. For the IPv4 source of the discarded packet to be informed of packet loss, the ICMPv6 message has to be converted into an ICMPv4 message. R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC792]. This packet MUST contain the first 8 octets of the discarded packet's IP payload. The reserved IPv4 dummy address (192.0.0.8/32; see Section 6) MUST be used as its source address. As described in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination Unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0 (Time Exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded, time to live exceeded in transit).4.9. Provisioning 4rd Parameters to CEs
Domain parameters listed in Section 4.2 are subject to the following constraints: R-23: Each Domain MUST have a BR Mapping rule and/or a NAT64+ Mapping rule. The BR Mapping rule is only used by CEs that are assigned public IPv4 addresses, shared or not. The NAT64+ Mapping rule is only used by CEs that are assigned the unspecified IPv4 address (Section 4.4) and therefore need an ISP NAT64 to reach IPv4 destinations. R-24: Each CE and each BR MUST support up to 32 Mapping rules. Support for up to 32 Mapping rules ensures that independently acquired CEs and BR nodes can always interwork. ISPs that need Mapping rules for more IPv4 prefixes than this number SHOULD split their networks into multiple Domains. Communication between these domains can be done in IPv4 or by some other implementation-dependent, but equivalent, means.
R-25: For mesh topologies, where CE-CE paths don't go via BRs, all
Mapping rules of the Domain MUST be sent to all CEs. For
hub-and-spoke topologies, where all CE-CE paths go via BRs,
each CE MAY be sent only the BR Mapping rule of the Domain
plus, if different, the CE Mapping rule that applies to its CE
IPv6 prefix.
R-26: In a Domain where the chosen topology is hub-and-spoke, all CEs
MUST have IPv6 prefixes that match a CE Mapping rule.
(Otherwise, packets sent to CEs whose IPv6 prefixes would match
only the BR Mapping rule would, with longest-match selected
routes, be routed directly to these CEs. This would be
contrary to the hub-and-spoke requirement.)
R-27: CEs MUST be able to acquire parameters of 4rd domains
(Section 4.2) in DHCPv6 [RFC3315]. Formats of DHCPv6 options
to be used are detailed in Figures 7, 8, and 9, with field
values specified after each figure.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated 4rd rule options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 Option for 4rd
o option code: 97, OPTION_4RD (see Section 6)
o option-length: the length of encapsulated options, in octets
o encapsulated 4rd rule options: The OPTION_4RD DHCPv6 option
contains at least one encapsulated OPTION_4RD_MAP_RULE option and
a maximum of one encapsulated OPTION_4RD_NON_MAP_RULE option.
Since DHCP servers normally send whatever options the operator
configures, operators are advised to configure these options
appropriately. DHCP servers MAY check to see that the
configuration follows these rules and notify the operator in an
implementation-dependent manner if the settings for these options
aren't valid. The length of encapsulated options is in octets.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | prefix6-len | ea-len |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| rule-ipv6-prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encapsulated Option for Mapping-Rule Parameters
o option code: 98, encapsulated OPTION_4RD_MAP_RULE option (see
Section 6)
o option-length: 20
o prefix4-len: number of bits of the Rule IPv4 prefix
o prefix6-len: number of bits of the Rule IPv6 prefix
o ea-len: EA-bits length
o W: WKP authorized, = 1 if set
o rule-ipv4-prefix: Rule IPv4 prefix, left-aligned
o rule-ipv6-prefix: Rule IPv6 prefix, left-aligned
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |option =OPTION_4RD_NON_MAP_RULE| option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| 0 |T| traffic-class | domain-pmtu | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Encapsulated Option for Non-Mapping-Rule Parameters of 4rd Domains o option code: 99, encapsulated OPTION_4RD_NON_MAP_RULE option (see Section 6) o option-length: 4 o H: Hub-and-spoke topology (= 1 if Yes) o T: Traffic Class flag (= 1 if a Tunnel Traffic Class is provided) o traffic-class: Tunnel Traffic Class o domain-pmtu: Domain PMTU (at least 1280 octets) Means other than DHCPv6 that may prove useful to provide 4rd parameters to CEs are off-scope for this document. The same or similar parameter formats would, however, be recommended to facilitate training and operation.5. Security Considerations
Spoofing attacks With IPv6 ingress filtering in effect in the Domain [RFC3704], as required in Section 3 (Figure 1 in particular), and with consistency checks between 4rd IPv4 and IPv6 addresses (Section 4.5), no spoofing opportunity in IPv4 is introduced by 4rd: being able to use as source IPv6 address only one that has been allocated to him, a customer can only provide as source 4rd IPv4 address that which derives this IPv6 address according to Section 4.5, i.e., one that his ISP has allocated to him. Routing loop attacks Routing loop attacks that may exist in some "automatic tunneling" scenarios are documented in [RFC6324]. No opportunities for routing loop attacks have been identified with 4rd.
Fragmentation-related attacks
As discussed in Section 4.6, each BR of a Domain that assigns
shared public IPv4 addresses should maintain a dynamic table of
fragmented packets that go to these shared-address CEs.
This leaves BRs vulnerable to denial-of-service attacks from hosts
that would send very large numbers of first fragments and would
never send last fragments having the same packet identifications.
This vulnerability is inherent in IPv4 address sharing, be it
static or dynamic. Compared to what it is with algorithms that
reassemble IPv4 packets in BRs, it is, however, significantly
mitigated by the algorithm provided in Section 4.6.2, as that
algorithm uses much less memory space.
6. IANA Considerations
IANA has allocated the following:
o Encapsulated options OPTION_4RD (97), OPTION_4RD_MAP_RULE (98),
and OPTION_4RD_NON_MAP_RULE (99). These options have been
recorded in the option code space of the "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)" registry. See
Section 4.9 of this document and Section 24.3 of [RFC3315]).
Value | Description | Reference
-----------+-------------------------+---------------
97 | OPTION_4RD | this document
98 | OPTION_4RD_MAP_RULE | this document
99 | OPTION_4RD_NON_MAP_RULE | this document
o Reserved IPv4 address 192.0.0.8/32 to be used as the "IPv4 dummy
address" (Section 4.8).
7. Relationship with Previous Works
The present specification has been influenced by many previous IETF
drafts, in particular those accessible at
<http://tools.ietf.org/html/draft-xxxx>, where "xxxx" refers to the
following (listed in order, by date of their first versions):
o bagnulo-behave-nat64 (2008-06-10)
o xli-behave-ivi (2008-07-06)
o despres-sam-scenarios (2008-09-28)
o boucadair-port-range (2008-10-23)
o ymbk-aplusp (2008-10-27) o xli-behave-divi (2009-10-19) o thaler-port-restricted-ip-issues (2010-02-28) o cui-softwire-host-4over6 (2010-07-06) o dec-stateless-4v6 (2011-03-05) o matsushima-v6ops-transition-experience (2011-03-07) o despres-intarea-4rd (2011-03-07) o deng-aplusp-experiment-results (2011-03-07) o operators-softwire-stateless-4v6-motivation (2011-05-05) o xli-behave-divi-pd (2011-07-04) o murakami-softwire-4rd (2011-07-04) o murakami-softwire-4v6-translation (2011-07-04) o despres-softwire-4rd-addmapping (2011-08-19) o boucadair-softwire-stateless-requirements (2011-09-08) o chen-softwire-4v6-add-format (2011-10-12) o mawatari-softwire-464xlat (2011-10-16) o mdt-softwire-map-dhcp-option (2011-10-24) o mdt-softwire-mapping-address-and-port (2011-10-24) o mdt-softwire-map-translation (2012-01-10) o mdt-softwire-map-encapsulation (2012-01-27)
8. References
8.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. [RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, DOI 10.17487/RFC4925, July 2007, <http://www.rfc-editor.org/info/rfc4925>. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.8.2. Informative References
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012. [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <http://www.rfc-editor.org/info/rfc4961>. [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, <http://www.rfc-editor.org/info/rfc5595>. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>. [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <http://www.rfc-editor.org/info/rfc6324>. [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>. [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>. [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>. [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>. [Solutions-4v6] Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, draft-ietf-softwire-stateless-4v6-motivation-05, November 2012.
Appendix A. Textual Representation of Mapping Rules
In the sections that follow, each Mapping rule will be represented as follows, using 0bXXX to represent binary number XXX; square brackets ("[ ]") indicate optional items: {Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix [, WKPs authorized]} EXAMPLES: {0.0.0.0/0, 32, 2001:db8:0:1:300::/80} a BR Mapping rule {198.16.0.0/14, 22, 2001:db8:4000::/34} a CE Mapping rule {0.0.0.0/0, 32, 2001:db8:0:1::/80} a NAT64+ Mapping rule {198.16.0.0/14, 22, 2001:db8:4000::/34, Yes} a CE Mapping rule and hub-and-spoke topologyAppendix B. Configuring Multiple Mapping Rules
As far as Mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the BR Mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it, comprising the BR /64 prefix, the 4rd Tag, and the IPv4 address. However, this model has the following limitations: (1) shared IPv4 addresses are not supported; (2) IPv6 prefixes used for 4rd are too long to also be used for native IPv6 addresses; (3) if the IPv4 address space of the ISP is split with many disjoint IPv4 prefixes, the IPv6 routing plan must be as complex as an IPv4 routing plan based on these prefixes. With more Mapping rules, CE prefixes used for 4rd can be those used for native IPv6. How to choose CE Mapping rules for a particular deployment does not need to be standardized. The following is only a particular pragmatic approach that can be used for various deployment scenarios. It is applied in some of the use cases that follow. (1) Select a "Common_IPv6_prefix" that will appear at the beginning of all 4rd CE IPv6 prefixes. (2) Choose all IPv4 prefixes to be used, and assign one of them to each CE Mapping rule i.
(3) For each CE Mapping rule i, do the following:
A. Choose the length of its Rule IPv6 prefix (possibly the same
for all CE Mapping rules).
B. Determine its PSID_length(i). A CE Mapping rule that
assigns shared addresses with a sharing ratio of 2^Ki has
PSID_length = Ki. A CE Mapping rule that assigns IPv4
prefixes of length L < 32 is considered to have a negative
PSID_length (PSID_length = L - 32).
C. Derive EA-bits length(i) = 32 - L(Rule IPv4 prefix(i)) +
PSID_length(i).
D. Derive the length of Rule_code(i), the prefix to be appended
to the common prefix to get the Rule IPv6 prefix of rule i:
L(Rule_code(i)) = L(CE IPv6 prefix(i))
- L(Common_IPv6_prefix)
- (32 - L(Rule IPv4 prefix(i)))
- PSID_length(i)
E. Derive Rule_code(i) with the following constraints: (1) its
length is L(Rule_code(i)); (2) it does not overlap with any
of the previously obtained Rule_codes (for instance, 010 and
01011 do overlap, while 00, 011, and 010 do not); (3) it has
the lowest possible value as a fractional binary number (for
instance, 0100 < 10 < 11011 < 111). Thus, rules whose
Rule_code lengths are 4, 3, 5, and 2 give Rule_codes 0000,
001, 00010, and 01.
F. Take Rule IPv6 prefix(i) = the Common_IPv6_prefix followed
by Rule_code(i).
:<--------------------- L(CE IPv6 prefix(i)) --------------------->:
: :
: 32 - L(Rule IPv4 prefix(i)) PSID_length(i):
: \ | :
: :<---------'--------><--'-->:
: : || :
: : \/ :
: :<------->:<--- EA-bits length(i) --->:
: L(Rule_code(i))
: : :
+----------------------------+---------+
| Common_IPv6_prefix |Rule_code|
| | (i) |
+----------------------------+---------+
:<------ L(Rule IPv6 prefix(i)) ------>:
Figure 10: Diagram of One Pragmatic Approach
Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network
C.1. With CEs within CPEs
Here, we consider an ISP that offers IPv6-only service to up to 2^20
customers. Each customer is delegated a /56, starting with common
prefix 2001:db8:0::/36. The ISP wants to add public IPv4 service for
customers that are 4rd capable. It prefers to do so with stateless
operation in its nodes but has significantly fewer IPv4 addresses
than IPv6 addresses, so a sharing ratio is necessary.
The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16,
192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor
aggregatable). This gives 2^(32 - 15) + 3 * 2^(32 - 16) IPv4
addresses, i.e., 2^18 + 2^16. For the 2^20 customers to have the
same sharing ratio, the number of IPv4 addresses to be shared has to
be a power of 2. The ISP can therefore give up using one of its
/16s, say the last one. (Whether or not it could be motivated to
return it to its Internet Registry is off-scope for this document.)
The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a
PSID length of 2.
Applying the principles of Appendix B with L(Common_IPv6_prefix) = 36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all rules, Rule_codes and Rule IPv6 prefixes are as follows: +--------------+--------+-----------+-----------+-------------------+ | CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 | | prefix | bits | length | (binary) | prefix | | | length | | | | +--------------+--------+-----------+-----------+-------------------+ | 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 | | 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 | | 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 | +--------------+--------+-----------+-----------+-------------------+ Mapping rules are then the following: {192.8.0.0/15, 19, 2001:0db8:0000::/37} {192.4.0.0/16, 18, 2001:0db8:0800::/38} {192.2.0.0/16, 18, 2001:0db8:0c00::/38} {0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80} The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56 derives its IPv4 address and its port set as follows (Section 4.4): CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match) EA-bits length(i) : 18 EA bits : 0b11 1011 1011 1011 1011 Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16) IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110 : 192.4.238.238 PSID : 0b11 Ports : 0bYYYY 11XX XXXX XXXX with YYYY > 0, and X...X any value
An IPv4 packet sent to address 192.4.238.238 and port 7777 is tunneled to the IPv6 address obtained as follows (Section 4.5): IPv4 address : 192.4.238.238 (0xc004 eeee) : 0b1100 0000 0000 0100 1110 1110 1110 1110 Rule IPv4 prefix(i): 192.4.0.0/16 (longest match) : 0b1100 0000 0000 0100 IPv4 suffix(i) : 0b1110 1110 1110 1110 EA-bits length(i) : 18 PSID length(i) : 2 (= 16 + 18 - 32) Port field : 0b 0001 1110 0110 0001 (7777) PSID : 0b11 Rule IPv6 prefix(i): 2001:0db8:0800::/38 CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56 IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY with YYYY = the computed CNPC.2. With Some CEs behind Third-Party Router CPEs
We now consider an ISP that has the same need as the ISP described in the previous section, except that (1) instead of using only its own IPv6 infrastructure, it uses that of a third-party provider and (2) some of its customers use this provider's Customer Premises Equipment (CPEs) so that they can use specific services offered by the provider. In these CPEs, a non-zero index is used to route IPv6 packets to the physical port to which CEs are attached, say 0x2. Each such CPE delegates to the CE nodes the customer-site IPv6 prefix followed by this index. The ISP is supposed to have the same IPv4 prefixes as those in the previous use case -- 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16 -- and to use the same Common_IPv6_prefix, 2001:db8:0::/36. We also assume that only a minority of customers use third-party CPEs, so that it is sufficient to use only one of the two /16s for them. Mapping rules are then (see Appendix C.1): {192.8.0.0/15, 19, 2001:0db8:0000::/37} {192.4.0.0/16, 18, 2001:0db8:0800::/38} {192.2.0.0/16, 18, 2001:0db8:0c00::/38} {0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80} CEs that are behind third-party CPEs derive their own IPv4 addresses and port sets as described in Appendix C.1.
In a BR, and also in a CE if the topology is mesh, the IPv6 address
that is derived from IPv4 address 192.4.238.238 and port 7777 is
obtained as described in the previous section, except for the last
two steps, which are modified as follows:
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60
IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
with YYYY = the computed CNP
Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing
In this use case, we consider an ISP that offers IPv4 service with
public addresses individually assigned to its customers. It also
offers IPv6 service, as it has deployed dual-stack routing. Because
it provides its own CPEs to customers, it can upgrade all of its CPEs
to support 4rd. It wishes to take advantage of this capability to
replace dual-stack routing with IPv6-only routing, without changing
any IPv4 address or IPv6 prefix.
For this, the ISP can use the single-rule model described at the
beginning of Appendix B. If the prefix routed to BRs is chosen to
start with 2001:db8:0:1::/64, this rule is:
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
All that is needed in the network before disabling IPv4 routing is
the following:
o In all routers, where there is an IPv4 route toward x.x.x.x/n, add
a parallel route toward 2001:db8:0:1:300:x.x.x.x::/(80+n).
o Where IPv4 address x.x.x.x was assigned to a CPE, now delegate
IPv6 prefix 2001:db8:0:1:300:x.x.x.x::/112.
NOTE: In parallel with this deployment, or after it, shared IPv4 addresses can be assigned to IPv6 customers. It is sufficient that IPv4 prefixes used for this be different from those used for exclusive-address assignments. Under this constraint, Mapping rules can be set up according to the same principles as those described in Appendix C.Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network
In this use case, we consider an ISP that has only deployed IPv4, possibly because some of its network devices are not yet IPv6 capable. Because it did not have enough IPv4 addresses, it has assigned private IPv4 addresses [RFC1918] to customers, say 10.x.x.x. It thus supports up to 2^24 customers (a "Net-10" network, using the NAT444 model [NAT444]). Now, it wishes to offer IPv6 service without further delay, using 6rd [RFC5969]. It also wishes to offer incoming IPv4 connectivity to its customers with a simpler solution than that provided by the Port Control Protocol (PCP) [RFC6887]. This appendix describes an example that adds IPv6 (using 6rd) and 4rd services to the "Net-10" private IPv4 network. The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32, and the public IPv4 prefix to be used for shared addresses is supposed to be 198.16.0.0/16 (0xc610). The resulting sharing ratio is 2^24 / 2^(32 - 16) = 256, giving a PSID length of 8. The ISP installs one or several BRs at its border to the public IPv4 Internet. They support 6rd, and 4rd above it. The BR prefix /64 is supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e., 2001:db8:0:100:/64). In accordance with [RFC5969], 6rd BRs are configured with the following parameters: IPv4MaskLen = 8; 6rdPrefix = 2001:db8::/32; 6rdBRIPv4Address = 192.168.0.1 (0xc0a80001). 4rd Mapping rules are then the following: {198.16.0.0/16, 24, 2001:db8:0:0:300::/80} {0.0.0.0/0, 32, 2001:db8:0:100:300:/80,} Any customer device that supports 4rd in addition to 6rd can then use its assigned shared IPv4 address with 240 assigned ports.
If its NAT44 supports port forwarding to provide incoming IPv4 connectivity (statically, or dynamically with Universal Plug and Play (UPnP) and/or the NAT Port Mapping Protocol (NAT-PMP)), it can use it with ports of the assigned port set (a possibility that does not exist in Net-10 networks without 4rd/6rd).Acknowledgements
This specification has benefited over several years from independent proposals, questions, comments, constructive suggestions, and useful criticisms from numerous IETF contributors. The authors would like to express recognition of all of these contributors, and especially the following, in alphabetical order by their first names: Behcet Sarikaya, Bing Liu, Brian Carpenter, Cameron Byrne, Congxiao Bao, Dan Wing, Derek Atkins, Erik Kline, Francis Dupont, Gabor Bajko, Hui Deng, Jacni Quin (who was an active coauthor of some earlier versions of this specification), James Huang, Jan Zorz, Jari Arkko, Kathleen Moriarty, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Marcello Bagnulo, Mark Townsley, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, Suresh Krishnan, Ted Lemon, Teemu Savolainen, Tetsuya Murakami, Tina Tsou, Tomek Mrugalski, Washam Fan, Wojciech Dec, Xiaohong Deng, Xing Li, and Yu Fu.Authors' Addresses
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France Email: despres.remi@laposte.net Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No. 156 BeiQing Road Hai-Dian District, Beijing 100095 China Email: jiangsheng@huawei.com
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States Email: repenno@cisco.com Yiu Lee Comcast One Comcast Center Philadelphia, PA 19103 United States Email: yiu_lee@cable.comcast.com Gang Chen China Mobile 29, Jinrong Avenue Xicheng District, Beijing 100033 China Email: phdgang@gmail.com, chengang@chinamobile.com Maoke Chen (a.k.a. Noriyuki Arai) BBIX, Inc. Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1 Minato-ku, Tokyo 105-7310 Japan Email: maoke@bbix.net