summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7600.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7600.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7600.txt')
-rw-r--r--doc/rfc/rfc7600.txt2523
1 files changed, 2523 insertions, 0 deletions
diff --git a/doc/rfc/rfc7600.txt b/doc/rfc/rfc7600.txt
new file mode 100644
index 0000000..6282fdf
--- /dev/null
+++ b/doc/rfc/rfc7600.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Despres
+Request for Comments: 7600 RD-IPtech
+Category: Experimental S. Jiang, Ed.
+ISSN: 2070-1721 Huawei Technologies Co., Ltd
+ R. Penno
+ Cisco Systems, Inc.
+ Y. Lee
+ Comcast
+ G. Chen
+ China Mobile
+ M. Chen
+ BBIX, Inc.
+ July 2015
+
+
+ IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
+
+Abstract
+
+ This document specifies a stateless solution for service providers to
+ progressively deploy IPv6-only network domains while still offering
+ IPv4 service to customers. The solution's distinctive properties are
+ that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during
+ domain traversal and that IPv4 fragmentation rules are fully
+ preserved end to end. Each customer can be assigned one public IPv4
+ address, several public IPv4 addresses, or a shared address with a
+ restricted port set.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7600.
+
+
+
+
+
+
+Despres, et al. Experimental [Page 1]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 2]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................5
+ 3. The 4rd Model ...................................................7
+ 4. Protocol Specifications .........................................9
+ 4.1. NAT44 on CE ................................................9
+ 4.2. Mapping Rules and Other Domain Parameters .................10
+ 4.3. Reversible Packet Translations at Domain Entries
+ and Exits .................................................11
+ 4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4
+ Prefixes ..................................................17
+ 4.5. Address Mapping from 4rd IPv4 Addresses to 4rd
+ IPv6 Addresses ............................................19
+ 4.6. Fragmentation Processing ..................................23
+ 4.6.1. Fragmentation at Domain Entry ......................23
+ 4.6.2. Ports of Fragments Addressed to
+ Shared-Address CEs .................................24
+ 4.6.3. Packet Identifications from Shared-Address CEs .....26
+ 4.7. TOS and Traffic Class Processing ..........................26
+ 4.8. Tunnel-Generated ICMPv6 Error Messages ....................27
+ 4.9. Provisioning 4rd Parameters to CEs ........................27
+ 5. Security Considerations ........................................30
+ 6. IANA Considerations ............................................31
+ 7. Relationship with Previous Works ...............................31
+ 8. References .....................................................33
+ 8.1. Normative References ......................................33
+ 8.2. Informative References ....................................34
+ Appendix A. Textual Representation of Mapping Rules ...............37
+ Appendix B. Configuring Multiple Mapping Rules ....................37
+ Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network .......39
+ C.1. With CEs within CPEs .......................................39
+ C.2. With Some CEs behind Third-Party Router CPEs ..............41
+ Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing ...42
+ Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network .......43
+ Acknowledgements ..................................................44
+ Authors' Addresses ................................................44
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 3]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+1. Introduction
+
+ For service providers to progressively deploy IPv6-only network
+ domains while still offering IPv4 service to customers, the need for
+ a stateless solution, i.e., one where no per-customer state is needed
+ in IPv4-IPv6 gateway nodes of the provider, has been discussed in
+ [Solutions-4v6]. This document specifies one such solution, named
+ "4rd" for IPv4 Residual Deployment. Its distinctive properties are
+ that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during
+ domain traversal and that IPv4 fragmentation rules are fully
+ preserved end to end.
+
+ Using this solution, IPv4 packets are transparently tunneled across
+ IPv6 networks (the reverse of IPv6 Rapid Deployment on IPv4
+ Infrastructures (6rd) [RFC5969], in which IPv6 packets are
+ statelessly tunneled across IPv4 networks).
+
+ While IPv6 headers are too long to be mapped into IPv4 headers (which
+ is why 6rd requires encapsulation of full IPv6 packets in IPv4
+ packets), IPv4 headers can be reversibly translated into IPv6 headers
+ in such a way that, during IPv6 domain traversal, UDP packets having
+ checksums and TCP packets are valid IPv6 packets. IPv6-only
+ middleboxes that perform deep packet inspection can operate on them,
+ in particular for port inspection and web caches.
+
+ In order to deal with the IPv4 address shortage, customers can be
+ assigned shared public IPv4 addresses with statically assigned
+ restricted port sets. As such, it is a particular application of the
+ Address plus Port (A+P) approach [RFC6346].
+
+ Deploying 4rd in networks that have enough public IPv4 addresses,
+ customer sites can also be assigned full public IPv4 addresses. 4rd
+ also supports scenarios where a set of public IPv4 addresses are
+ assigned to customer sites.
+
+ The design of 4rd builds on a number of previous proposals made for
+ IPv4-via-IPv6 transition technologies (Section 7).
+
+ In some use cases, IPv4-only applications of 4rd-capable customer
+ nodes can also work with stateful NAT64s [RFC6146], provided these
+ are upgraded to support 4rd tunnels in addition to their IP/ICMP
+ translation [RFC6145]. The advantage is then a more complete IPv4
+ transparency than with double translation.
+
+ How the 4rd model fits in the Internet architecture is summarized in
+ Section 3. The protocol specifications are detailed in Section 4.
+ Sections 5 and 6 deal with security considerations and IANA
+ considerations, respectively. Previous proposals that influenced
+
+
+
+Despres, et al. Experimental [Page 4]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ this specification are listed in Section 7. A few typical 4rd use
+ cases are presented in Appendices A, B, C, D, and E.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ ISP: Internet Service Provider. In this document, the service it
+ offers can be DSL, fiber-optics, cable, or mobile. The ISP can
+ also be a private-network operator.
+
+ 4rd (IPv4 Residual Deployment): An extension of the IPv4 service
+ where public IPv4 addresses can be statically shared among
+ several customer sites, each one being assigned an exclusive
+ port set. This service is supported across IPv6-routing
+ domains.
+
+ 4rd domain (or Domain): An ISP-operated IPv6 network across which
+ 4rd is supported according to the present specification.
+
+ Tunnel packet: An IPv6 packet that transparently conveys an IPv4
+ packet across a 4rd domain. Its header has enough information
+ to reconstitute the IPv4 header at Domain exit. Its payload is
+ the original IPv4 payload.
+
+ CE (Customer Edge): A customer-side tunnel endpoint. It can be in a
+ node that is a host, a router, or both.
+
+ BR (Border Relay): An ISP-side tunnel endpoint. Because its
+ operation is stateless (neither per CE nor per session state),
+ it can be replicated in as many nodes as needed for scalability.
+
+ 4rd IPv6 address: IPv6 address used as the destination of a Tunnel
+ packet sent to a CE or a BR.
+
+ NAT64+: An ISP NAT64 [RFC6146] that is upgraded to support 4rd
+ tunneling when IPv6 addresses it deals with are 4rd IPv6
+ addresses.
+
+ 4rd IPv4 address: A public IPv4 address or, in the case of a shared
+ public IPv4 address, a public transport address (public IPv4
+ address plus port number).
+
+ PSID (Port-Set Identifier): A flexible-length field that
+ algorithmically identifies a port set.
+
+
+
+
+Despres, et al. Experimental [Page 5]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 4rd IPv4 prefix: A flexible-length prefix that may be a public IPv4
+ prefix, a public IPv4 address, or a public IPv4 address followed
+ by a PSID.
+
+ Mapping rule: A set of parameters that are used by BRs and CEs to
+ derive 4rd IPv6 addresses from 4rd IPv4 addresses. Mapping
+ rules are also used by each CE to derive a 4rd IPv4 prefix from
+ an IPv6 prefix that has been delegated to it.
+
+ EA bits (Embedded Address bits): Bits that are the same in a 4rd
+ IPv4 address and in the 4rd IPv6 address derived from it.
+
+ BR Mapping rule: The Mapping rule that is applicable to off-domain
+ IPv4 addresses (addresses reachable via BRs). It can also apply
+ to some or all CE-assigned IPv4 addresses.
+
+ CE Mapping rule: A Mapping rule that is applicable only to
+ CE-assigned IPv4 addresses (shared or not).
+
+ NAT64+ Mapping rule: The Mapping rule that is applicable to IPv4
+ addresses reachable via a NAT64+.
+
+ CNP (Checksum Neutrality Preserver): A field of 4rd IPv6 addresses
+ that ensures that TCP-like checksums do not change when IPv4
+ addresses are replaced with 4rd IPv6 addresses.
+
+ 4rd Tag: A 16-bit tag whose value allows 4rd CEs, BRs, and NAT64+s
+ to distinguish 4rd IPv6 addresses from other IPv6 addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 6]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+3. The 4rd Model
+
+ 4rd Domain
+ +-----------------------------+
+ | IPv6 routing |
+ | Enforced ingress filtering | +----------
+ ... | | |
+ | +------+
+ Customer site | |BR(s) | IPv4
+ +------------+ | BR IPv6 prefix --> |and/or| Internet
+ | dual-stack | | |N4T64+|
+ | +--+ | +------+
+ | |CE+-+ <-- a CE IPv6 prefix | |
+ | +--+ | | +----------
+ | | | |
+ +------------+ | <--IPv4 tunnels--> +------------
+ => Derived | (Mesh or hub-and-spoke |
+ 4rd IPv4 prefix| topologies) | IPv6
+ | | Internet
+ ... | |
+ | +------------
+ +-----------------------------+
+ <== one or several Mapping rules
+ (e.g., announced to CEs in stateless DHCPv6)
+
+ Figure 1: The 4rd Model in the Internet Architecture
+
+ How the 4rd model fits in the Internet architecture is represented in
+ Figure 1.
+
+ A 4rd domain is an IPv6 network that includes one or several 4rd BRs
+ or NAT64+s at its border with the public IPv4 Internet and that can
+ advertise its IPv4-IPv6 Mapping rule(s) to CEs according to
+ Section 4.9.
+
+ BRs of a 4rd Domain are all identical as far as 4rd is concerned. In
+ a 4rd CE, the IPv4 packets that need to reach a BR will be
+ transformed (as detailed in Section 4.3) into IPv6 packets that have
+ the same anycast IPv6 prefix, which is the 80-bit BR prefix, in their
+ destination addresses. They are then routed to any of the BRs. The
+ 80-bit BR IPv6 prefix is an arbitrarily chosen /64 prefix from the
+ IPv6 address space of the network operator and appended with 0x0300
+ (16-bit 4rd Tag; see R-9 in Section 4.5).
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 7]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ Using the Mapping rule that applies, each CE derives its 4rd IPv4
+ prefix from its delegated IPv6 prefix, or one of them if it has
+ several; see Section 4.4 for details. If the obtained IPv4 prefix
+ has more than 32 bits, the assigned IPv4 address is shared among
+ several CEs. Bits beyond the first 32 specify a set of ports whose
+ use is reserved for the CE.
+
+ IPv4 traffic is automatically tunneled across the Domain, in either
+ mesh topology or hub-and-spoke topology [RFC4925]. By default, IPv4
+ traffic between two CEs follows a direct IPv6 route between them
+ (mesh topology). If the ISP configures the hub-and-spoke option,
+ each IPv4 packet from one CE to another is routed via a BR.
+
+ During Domain traversal, each tunneled TCP/UDP IPv4 packet looks like
+ a valid TCP/UDP IPv6 packet. Thus, TCP/UDP access control lists that
+ apply to IPv6, and possibly some other functions using deep packet
+ inspection, also apply to IPv4.
+
+ In order for IPv4 anti-spoofing protection in CEs and BRs to remain
+ effective when combined with 4rd tunneling, ingress filtering
+ [RFC3704] has to be in effect in IPv6 (see R-12 and Section 5).
+
+ If an ISP wishes to support dynamic IPv4 address sharing in addition
+ to or in place of 4rd stateless address sharing, it can do so by
+ means of a stateful NAT64. By upgrading this NAT to add support for
+ 4rd tunnels, which makes it a NAT64+, CEs that are assigned no static
+ IPv4 space can benefit from complete IPv4 transparency between the CE
+ and the NAT64. (Without this NAT64 upgrade, IPv4 traffic is
+ translated to IPv6 and back to IPv4, during which time the DF =
+ MF = 1 combination for IPv4, as recommended for host fragmentation in
+ Section 8 of [RFC4821], is lost.)
+
+ IPv4 packets are kept unchanged by Domain traversal, except that:
+
+ o The IPv4 Time To Live (TTL), unless it is 1 or 255 at Domain
+ entry, decreases during Domain traversal by the number of
+ traversed routers. This is acceptable because it is undetectable
+ end to end and also because TTL values that can be used with some
+ protocols to test the adjacency of communicating routers are
+ preserved [RFC4271] [RFC5082]. The effect on the traceroute
+ utility, which uses TTL expiry to discover routers of end-to-end
+ paths, is noted in Section 4.3.
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 8]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ o IPv4 packets whose lengths are <= 68 octets always have their
+ "Don't Fragment" (DF) flags set to 1 at Domain exit even if they
+ had DF = 0 at Domain entry. This is acceptable because these
+ packets are too short to be fragmented [RFC791] and so their DF
+ bits have no meaning. Besides, both [RFC1191] and [RFC4821]
+ recommend that sources always set DF to 1.
+
+ o Unless the Tunnel Traffic Class option applies to a Domain
+ (Section 4.2), IPv4 packets may have their Type of Service (TOS)
+ fields modified after Domain traversal (Section 4.7).
+
+4. Protocol Specifications
+
+ This section describes detailed 4rd protocol specifications. They
+ are mainly organized by functions. As a brief summary:
+
+ o A 4rd CE MUST follow R-1, R-2, R-3, R-4, R-6, R-7, R-8, R-9, R-10,
+ R-11, R-12, R-13, R-14, R-16, R-17, R-18, R-19, R-20, R-21, R-22,
+ R-23, R-24, R-25, R-26, and R-27.
+
+ o A 4rd BR MUST follow R-2, R-3, R-4, R-5, R-6, R-9, R-12, R-13,
+ R-14, R-15, R-19, R-20, R-21, R-22, and R-24.
+
+4.1. NAT44 on CE
+
+ R-1: A CE node that is assigned a shared public IPv4 address MUST
+ include a NAT44 [RFC3022]. This NAT44 MUST only use external
+ ports that are in the CE-assigned port set.
+
+ NOTE: This specification only concerns IPv4 communication between
+ IPv4-capable endpoints. For communication between IPv4-only
+ endpoints and IPv6-only remote endpoints, the "Bump-in-the-Host"
+ (BIH) specification [RFC6535] can be used. It can coexist in a node
+ with the CE function, including scenarios where the IPv4-only
+ function is a NAT44 [RFC3022].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 9]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+4.2. Mapping Rules and Other Domain Parameters
+
+ R-2: CEs and BRs MUST be configured with the following Domain
+ parameters:
+
+ A. One or several Mapping rules, each one comprising the
+ following:
+
+ 1. Rule IPv4 prefix
+
+ 2. EA-bits length
+
+ 3. Rule IPv6 prefix
+
+ 4. Well-Known Ports (WKPs) authorized (OPTIONAL)
+
+ B. Domain Path MTU (PMTU)
+
+ C. Hub-and-spoke topology (Yes or No)
+
+ D. Tunnel Traffic Class (OPTIONAL)
+
+ "Rule IPv4 prefix" is used to find, by a longest match, which Mapping
+ rule applies to a 4rd IPv4 address (Section 4.5). A Mapping rule
+ whose Rule IPv4 prefix is longer than /0 is a CE Mapping rule. BR
+ and NAT64+ Mapping rules, which must apply to all off-domain IPv4
+ addresses, have /0 as their Rule IPv4 prefixes.
+
+ "EA-bits length" is the number of bits that are common to 4rd IPv4
+ addresses and 4rd IPv6 addresses derived from them. In a CE Mapping
+ rule, it is also the number of bits that are common to a CE-delegated
+ IPv6 prefix and the 4rd IPv4 prefix derived from it. BR and NAT64+
+ Mapping rules have EA-bits lengths equal to 32.
+
+ "Rule IPv6 prefix" is the prefix that is used as a substitute for the
+ Rule IPv4 prefix when a 4rd IPv6 address is derived from a 4rd IPv4
+ address (Section 4.5). In a BR Mapping rule or a NAT64+ Mapping
+ rule, it MUST be a /80 prefix whose bits 64-79 are the 4rd Tag.
+
+ "WKPs authorized" may be set for Mapping rules that assign shared
+ IPv4 addresses to CEs. (These rules are those whose length of the
+ Rule IPv4 prefix plus the EA-bits length exceeds 32.) If set,
+ well-known ports may be assigned to some CEs having particular IPv6
+ prefixes. If not set, fairness is privileged: all IPv6 prefixes
+ concerned with the Mapping rule have port sets having identical
+ values (no port set includes any of the well-known ports).
+
+
+
+
+
+Despres, et al. Experimental [Page 10]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ "Domain PMTU" is the IPv6 Path MTU that the ISP can guarantee for all
+ of its IPv6 paths between CEs and between BRs and CEs. It MUST be at
+ least 1280 octets [RFC2460].
+
+ "Hub-and-spoke topology", if set to Yes, requires CEs to tunnel all
+ IPv4 packets via BRs. If set to No, CE-to-CE packets take the same
+ routes as native IPv6 packets between the same CEs (mesh topology).
+
+ "Tunnel Traffic Class", if provided, is the IPv6 traffic class that
+ BRs and CEs MUST set in Tunnel packets. In this case, evolutions of
+ the IPv6 traffic class that may occur during Domain traversal are not
+ reflected in TOS fields of IPv4 packets at Domain exit (Section 4.7).
+
+4.3. Reversible Packet Translations at Domain Entries and Exits
+
+ R-3: Domain-entry nodes that receive IPv4 packets with IPv4 options
+ MUST discard these packets and return ICMPv4 error messages to
+ signal IPv4-option incompatibility (Type = 12, Code = 0,
+ Pointer = 20) [RFC792]. This limitation is acceptable because
+ there are a lot of firewalls in the current IPv4 Internet that
+ also filter IPv4 packets with IPv4 options.
+
+ R-4: Domain-entry nodes that receive IPv4 packets without IPv4
+ options MUST convert them to Tunnel packets, with or without
+ IPv6 fragment headers, depending on what is needed to ensure
+ IPv4 transparency (Figure 2). Domain-exit nodes MUST convert
+ them back to IPv4 packets.
+
+ An IPv6 fragmentation header MUST be included at tunnel entry
+ (Figure 2) if and only if one or several of the following
+ conditions hold:
+
+ * The Tunnel Traffic Class option applies to the Domain.
+
+ * TTL = 1 OR TTL = 255.
+
+ * The IPv4 packet is already fragmented, or may be fragmented
+ later on, i.e., if MF = 1 OR offset > 0 OR (total length >
+ 68 AND DF = 0).
+
+ In order to optimize cases where fragmentation headers are
+ unnecessary, the NAT44 of a CE that has one SHOULD send packets
+ with TTL = 254.
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 11]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ R-5: In Domains whose chosen topology is hub-and-spoke, BRs that
+ receive 4rd IPv6 packets whose embedded destination IPv4
+ addresses match a CE Mapping rule MUST do the equivalent of
+ reversibly translating their headers to IPv4 and then
+ reversibly translate them back to IPv6 as though packets would
+ be entering the Domain.
+
+ (A) Without IPv6 fragment header
+ IPv4 packet Tunnel packet
+ +--------------------+ : : +--------------------+
+ 20| IPv4 Header | : <==> : | IPv6 Header | 40
+ +--------------------+ : : +--------------------+
+ | IP Payload | <==> | IP Payload |
+ | | Layer 4 | |
+ +--------------------+ unchanged +--------------------+
+
+
+ (B) With IPv6 fragment header
+ Tunnel packet
+ : +--------------------+
+ IPv4 packet : | IPv6 Header | 40
+ +--------------------+ : : +--------------------+
+ 20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+ +--------------------+ : : +--------------------+
+ | IP Payload | <==> | IP Payload |
+ | | Layer 4 | |
+ +--------------------+ unchanged +--------------------+
+
+ Figure 2: Reversible Packet Translation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 12]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ R-6: Values to be set in IPv6 header fields at Domain entry are
+ detailed in Table 1 (no fragment header) and Table 2 (with
+ fragment header). Those to be set in IPv4 header fields at
+ Domain exit are detailed in Table 3 (no fragment header) and
+ Table 4 (with fragment header).
+
+ To convey IPv4 header information that has no equivalent in
+ IPv6, some ad hoc fields are placed in IPv6 flow labels and in
+ Identification fields of IPv6 fragment headers, as detailed in
+ Figure 3.
+
+ |0 |4 19|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | Addr_Prot_Cksm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IPv6 Flow Label
+
+ 0 1 2 |8 |16 31|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |.|.|.| 0 | IPv4_TOS | IPv4_ID |
+ /-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / \ TTL_255 IPv6 Identification Field
+ IPv4_DF TTL_1 (in fragment header if needed)
+
+ Figure 3: 4rd Identification Fields of IPv6 Fragment Headers
+
+
+ +---------------------+----------------------------------------+
+ | IPv6 Field | Value (fields from IPv4 header) |
+ +---------------------+----------------------------------------+
+ | Version | 6 |
+ | Traffic Class | TOS |
+ | Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
+ | Payload length | Total length - 20 |
+ | Next header | Protocol |
+ | Hop limit | Time to Live |
+ | Source address | See Section 4.5 |
+ | Destination address | See Section 4.5 |
+ +---------------------+----------------------------------------+
+
+ Table 1: IPv4-to-IPv6 Reversible Header Translation
+ (without Fragment Header)
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 13]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ +-----------------+----------------------------------------------+
+ | IPv6 Field | Value (fields from IPv4 header) |
+ +-----------------+----------------------------------------------+
+ | Version | 6 |
+ | Traffic Class | TOS OR Tunnel Traffic Class (Section 4.7) |
+ | Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
+ | Payload length | Total length - 12 |
+ | Next header | 44 (fragment header) |
+ | Hop limit | IF Time to Live = 1 or 255 THEN 254 |
+ | | ELSE Time to Live (Note 2) |
+ | Source address | See Section 4.5 |
+ | Dest. address | See Section 4.5 |
+ | 2nd next header | Protocol |
+ | Fragment offset | IPv4 fragment offset |
+ | M | More Fragments flag (MF) |
+ | IPv4_DF | Don't Fragment flag (DF) |
+ | TTL_1 | IF Time to Live = 1 THEN 1 ELSE 0 (Note 2) |
+ | TTL_255 | IF Time to Live = 255 THEN 1 ELSE 0 (Note 2) |
+ | IPv4_TOS | Type of Service (TOS) |
+ | IPv4_ID | Identification |
+ +-----------------+----------------------------------------------+
+
+ Table 2: IPv4-to-IPv6 Reversible Header Translation
+ (with Fragment Header)
+
+
+ +-----------------+------------------------------------+
+ | IPv4 Field | Value (fields from IPv6 header) |
+ +-----------------+------------------------------------+
+ | Version | 4 |
+ | Header length | 5 |
+ | TOS | Traffic Class |
+ | Total length | Payload length + 20 |
+ | Identification | 0 |
+ | DF | 1 |
+ | MF | 0 |
+ | Fragment offset | 0 |
+ | Time to Live | Hop count |
+ | Protocol | Next header |
+ | Header checksum | Computed as per [RFC791] (Note 3) |
+ | Source address | Bits 80-111 of source address |
+ | Dest. address | Bits 80-111 of destination address |
+ +-----------------+------------------------------------+
+
+ Table 3: IPv6-to-IPv4 Reversible Header Translation
+ (without Fragment Header)
+
+
+
+
+
+Despres, et al. Experimental [Page 14]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ +-----------------------+-----------------------------------------+
+ | IPv4 Field | Value (fields from IPv6 header) |
+ +-----------------------+-----------------------------------------+
+ | Version | 4 |
+ | Header length | 5 |
+ | TOS | Traffic Class OR IPv4_TOS (Section 4.7) |
+ | Total length | Payload length + 12 |
+ | Identification | IPv4_ID |
+ | DF | IPv4_DF |
+ | MF | M |
+ | Fragment offset | Fragment offset |
+ | Time to Live (Note 2) | IF TTL_255 = 1 THEN 255 |
+ | | ELSEIF TTL_1 = 1 THEN 1 |
+ | | ELSE hop count |
+ | Protocol | 2nd next header |
+ | Header checksum | Computed as per [RFC791] (Note 3) |
+ | Source address | Bits 80-111 of source address |
+ | Destination address | Bits 80-111 of destination address |
+ +-----------------------+-----------------------------------------+
+
+ Table 4: IPv6-to-IPv4 Reversible Header Translation
+ (with Fragment Header)
+
+ NOTE 1: The need to save in the IPv6 header a checksum of both IPv4
+ addresses and the IPv4 protocol field results from the following
+ facts: (1) header checksums, present in IPv4 but not in IPv6, protect
+ addresses or protocol integrity; (2) in IPv4, ICMP messages and
+ null-checksum UDP datagrams depend on this protection because, unlike
+ other datagrams, they have no other address-and-protocol integrity
+ protection. The sum MUST be performed in ordinary two's complement
+ arithmetic.
+
+ IP-layer Packet length is another field covered by the IPv4 header
+ checksum. It is not included in the saved checksum because (1) doing
+ so would have conflicted with [RFC6437] (flow labels must be the same
+ in all packets of each flow); (2) ICMPv4 messages have good enough
+ protection with their own checksums; (3) the UDP length field
+ provides to null-checksum UDP datagrams the same level of protection
+ after Domain traversal as without Domain traversal (consistency
+ between IP-layer and UDP-layer lengths can be checked).
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 15]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ NOTE 2: TTL treatment has been chosen to permit adjacency tests
+ between two IPv4 nodes situated at both ends of a 4rd tunnel. TTL
+ values to be preserved for this are TTL = 255 and TTL = 1. For other
+ values, TTL decreases between two IPv4 nodes as though the traversed
+ IPv6 routers were IPv4 routers.
+
+ The effect of this TTL treatment on IPv4 traceroute is specific:
+ (1) the number of routers of the end-to-end path includes traversed
+ IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4
+ routers of Domain entry and exit; (3) the IPv4 address shown for an
+ IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8);
+ (4) the response time indicated for an IPv6 router is that of the
+ next router.
+
+ NOTE 3: Provided the sum of obtained IPv4 addresses and protocol
+ matches Addr_Prot_Cksm. If not, the packet MUST be silently
+ discarded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 16]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4 Prefixes
+
+ +--------------------------------------+
+ | CE IPv6 prefix |
+ +--------------------------+-----------+
+ : Longest match : :
+ : with a Rule IPv6 prefix : :
+ : || : EA-bits :
+ : \/ : length :
+ +--------------------------+ | :
+ | Rule IPv6 prefix |<----'---->:
+ +--------------------------+ :
+ || : :
+ \/ : :
+ +-----------------+-----------+
+ |Rule IPv4 prefix | EA bits |
+ +-----------------+-----------+
+ : :
+ +-----------------------------+
+ | CE 4rd IPv4 prefix |
+ +-----------------------------+
+ ________/ \_________ :
+ / \ :
+ : ____:________________/ \__
+ : / : \
+ : <= 32 : : > 32 :
+ +----------------+ +-----------------+----+
+ |IPv4 prfx or add| OR | IPv4 address |PSID|
+ +----------------+ +-----------------+----+
+ : 32 : || :
+ \/
+ (by default) (If WKPs authorized)
+ : : : :
+ +---+----+---------+ +----+-------------+
+ Ports in |> 0|PSID|any value| OR |PSID| any value |
+ the CE port set +---+----+---------+ +----+-------------+
+ : 4 : 12 : : 16 :
+
+ Figure 4: From CE IPv6 Prefix to 4rd IPv4 Address and Port Set
+
+ R-7: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix
+ of one or several Mapping rules MUST select the CE Mapping rule
+ for which the match is the longest. It then derives its 4rd
+ IPv4 prefix as shown in Figure 4: (1) The CE replaces the Rule
+ IPv6 prefix with the Rule IPv4 prefix. The result is the CE
+ 4rd IPv4 prefix. (2) If this CE 4rd IPv4 prefix has less than
+ 32 bits, the CE takes it as its assigned IPv4 prefix. If it
+ has exactly 32 bits, the CE takes it as its IPv4 address. If
+
+
+
+Despres, et al. Experimental [Page 17]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ it has more than 32 bits, the CE MUST take the first 32 bits as
+ its shared public IPv4 address and bits beyond the first 32 as
+ its Port-Set identifier (PSID). Ports of its restricted port
+ set are by default those that have any non-zero value in their
+ first 4 bits (the PSID offset), followed by the PSID, and
+ followed by any values in remaining bits. If the WKP
+ authorized option applies to the Mapping rule, there is no
+ 4-bit offset before the PSID so that all ports can be assigned.
+
+ NOTE: The choice of the default PSID position in port fields
+ has been guided by the following objectives: (1) for fairness,
+ avoid having any of the well-known ports 0-1023 in the port set
+ specified by any PSID value; (2) for compatibility with RTP/
+ RTCP [RFC4961], include in each port set pairs of consecutive
+ ports; (3) in order to facilitate operation and training, have
+ the PSID at a fixed position in port fields; (4) in order to
+ facilitate documentation in hexadecimal notation, and to
+ facilitate maintenance, have this position nibble-aligned.
+ Ports that are excluded from assignment to CEs are 0-4095,
+ instead of just 0-1023, in a trade-off to favor nibble
+ alignment of PSIDs and overall simplicity.
+
+ R-8: A CE whose delegated IPv6 prefix has its longest match with the
+ Rule IPv6 prefix of the BR Mapping rule MUST take as its IPv4
+ address the 32 bits that, in the delegated IPv6 prefix, follow
+ this Rule IPv6 prefix. If this is the case while the hub-and-
+ spoke option applies to the Domain, or if the Rule IPv6 prefix
+ is not a /80, there is a configuration error in the Domain. An
+ implementation-dependent administrative action MAY be taken.
+
+ A CE whose delegated IPv6 prefix does not match the Rule IPv6
+ prefix of either any CE Mapping rule or the BR Mapping rule,
+ and is in a Domain that has a NAT64+ Mapping rule, MUST be
+ noted as having the unspecified IPv4 address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 18]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+4.5. Address Mapping from 4rd IPv4 Addresses to 4rd IPv6 Addresses
+
+ : 32 : : 16 : \
+ +----------------------------+ +---------------+ |
+ | IPv4 address | |Port_or_ICMP_ID| | Shared-address
+ +----------------------------+ +---+------+----+ | case
+ : Longest match : : 4 : PSID : | (PSID length
+ : with a Rule IPv4 prefix : :length: | of the rule > 0)
+ : || : : : | with WKPs
+ : \/ : : : | not authorized
+ +----------------+-----------+ +------+ | (PSID offset = 4)
+ |Rule IPv4 prefix|IPv4 suffix| | PSID | |
+ +----------------+-----------+ +------+ |
+ : || \_______ \____ | | |
+ : \/ \ \| / |
+ +--------------------------+--------+-----+ /
+ | Rule IPv6 prefix | EA bits |
+ +--------------------------+--------------+
+ : :
+ +-----------------------------------------+
+ | IPv6 prefix |
+ +-----------------------------------------+
+ :\_______________________________ / \
+ : ___________________\______/ \_______________
+ : / \ \
+ : / (CE Mapping rule) \ (BR Mapping rule) \
+ : <= 64 : : 112 :
+ +----------+---+---+------+---+ +--------------+---+------+---+
+ |CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP|
+ +----------+-|-+---+------+---+ +--------------+---+------+---+
+ : <= 64 : | :16 : 32 :16 : : 64 :16 : 32 :16 :
+ |
+ Padding to /64
+
+ Figure 5: From 4rd IPv4 Address to 4rd IPv6 Address
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 19]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ R-9: BRs, and CEs that are assigned public IPv4 addresses, shared or
+ not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses via
+ the steps below or their functional equivalent (Figure 5
+ details the shared public IPv4 address case):
+
+ NOTE: The rules for forming 4rd-specific Interface Identifiers
+ (IIDs) are to obey [RFC7136]:
+
+ "Specifications of other forms of 64-bit IIDs MUST specify how
+ all 64 bits are set."
+
+ and
+
+ "the whole IID value MUST be viewed as an opaque bit string by
+ third parties, except possibly in the local context."
+
+ (1) If hub-and-spoke topology does not apply to the Domain, or
+ if it applies but the IPv6 address to be derived is a
+ source address from a CE or a destination address from a
+ BR, find the CE Mapping rule whose Rule IPv4 prefix has
+ the longest match with the IPv4 address.
+
+ If no Mapping rule is thus obtained, take the BR Mapping
+ rule.
+
+ If the obtained Mapping rule assigns IPv4 prefixes to CEs,
+ i.e., if the length of the Rule IPv4 prefix plus EA-bits
+ length is 32 - k, with k >= 0, delete the last k bits of
+ the IPv4 address.
+
+ Otherwise, if the length of the Rule IPv4 prefix plus the
+ EA-bits length is 32 + k, with k > 0, take k as the PSID
+ length and append to the IPv4 address the PSID copied from
+ bits p to p+3 of the Port_or_ICMP_ID field where (1) p,
+ the PSID offset, is 4 by default and 0 if the WKPs
+ authorized option applies to the rule; (2) the
+ Port_or_ICMP_ID field is in bits of the IP payload that
+ depend on whether the address is source or destination, on
+ whether the packet is ICMP or not, and, if it is ICMP,
+ whether it is an error message or an Echo message. This
+ field is:
+
+ a. If the packet Protocol is not ICMP, the port field
+ associated with the address (bits 0-15 for a source
+ address and bits 16-31 for a destination address).
+
+ b. If the packet is an ICMPv4 Echo or Echo reply message,
+ the ICMPv4 Identification field (bits 32-47).
+
+
+
+Despres, et al. Experimental [Page 20]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ c. If the packet is an ICMPv4 error message, the port
+ field associated with the address in the returned
+ packet header (bits 240-255 for a source address and
+ bits 224-239 for a destination address).
+
+ NOTE 1: Using Identification fields of ICMP messages as
+ port fields permits the exchange of Echo requests and Echo
+ replies between shared-address CEs and IPv4 hosts having
+ exclusive IPv4 addresses. Echo exchanges between two
+ shared-address CEs remain impossible, but this is a
+ limitation inherent in address sharing (one reason among
+ many to use IPv6).
+
+ NOTE 2: When the PSID is taken in the port fields of the
+ IPv4 payload, implementation is kept independent from any
+ particular Layer 4 protocol having such port fields by not
+ checking that the protocol is indeed one that has such
+ port fields. A packet may consequently go, in the case of
+ a source mistake, from a BR to a shared-address CE with a
+ protocol that is not supported by this CE. In this case,
+ the CE NAT44 returns an ICMPv4 "protocol unreachable"
+ error message. The IPv4 source is thus appropriately
+ informed of its mistake.
+
+ (2) In the result, replace the Rule IPv4 prefix with the Rule
+ IPv6 prefix.
+
+ (3) If the result is shorter than a /64, append to the result
+ a null padding up to 64 bits, followed by the 4rd Tag
+ (0x0300), and followed by the IPv4 address.
+
+ NOTE: The 4rd Tag is a 4rd-specific mark. Its function is
+ to ensure that 4rd IPv6 addresses are recognizable by CEs
+ without any interference with the choice of subnet
+ prefixes in CE sites. (These choices may have been done
+ before 4rd is enabled.)
+
+ For this, the 4rd Tag has its "u" and "g" bits [RFC4291]
+ both set to 1, so that they maximally differ from these
+ existing IPv6 address schemas. So far, u = g = 1 has not
+ been used in any IPv6 addressing architecture.
+
+ With the 4rd Tag, IPv6 packets can be routed to the 4rd
+ function within a CE node based on a /80 prefix that no
+ native IPv6 address can contain.
+
+
+
+
+
+
+Despres, et al. Experimental [Page 21]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ (4) Add to the result a Checksum Neutrality Preserver (CNP).
+ Its value, in one's complement arithmetic, is the opposite
+ of the sum of 16-bit fields of the IPv6 address other than
+ the IPv4 address and the CNP themselves (i.e., five
+ consecutive fields in address bits 0-79).
+
+ NOTE: The CNP guarantees that Tunnel packets are valid
+ IPv6 packets for all Layer 4 protocols that use the same
+ checksum algorithm as TCP. This guarantee does not depend
+ on where the checksum fields of these protocols are placed
+ in IP payloads. (Today, such protocols are UDP [RFC768],
+ TCP [RFC793], UDP-Lite [RFC3828], and the Datagram
+ Congestion Control Protocol (DCCP) [RFC5595]. Should new
+ ones be specified, BRs will support them without needing
+ an update.)
+
+ R-10: A 4rd-capable CE SHOULD, and a 4rd-enabled CE MUST, always
+ prohibit all addresses that use its advertised prefix and have
+ an IID starting with 0x0300 (4rd Tag), by using Duplicate
+ Address Detection [RFC4862].
+
+ R-11: A CE that is assigned the unspecified IPv4 address (see
+ Section 4.4) MUST use, for packets tunneled between itself and
+ the Domain NAT64+, addresses as detailed in Figure 6: part (a)
+ for its IPv6 source, and part (b) as IPv6 destinations that
+ depend on IPv4 destinations. A NAT64+, being NAT64 conforming
+ [RFC6146], MUST accept IPv6 packets whose destination conforms
+ to Figure 6(b) (4rd Tag instead of "u" and 0x00 octets). In
+ its Binding Information Base, it MUST remember whether a
+ mapping was created with a "u" or 4rd-tag destination. In the
+ IPv4-to-IPv6 direction, it MUST use 4rd tunneling, with source
+ address conforming to Figure 6(b), when using a mapping that
+ was created with a 4rd-tag destination.
+
+ +---------------------+---------+-------+-------------+------+
+ (a) | CE IPv6 prefix | 0 |4rd Tag| 0 | CNP |
+ +---------------------+---------+-------+-------------+------+
+ : <= 64 : >= 0 : 16 : 32 : 16 :
+ 4rd IPv6 address of a CE having no public IPv4 address
+
+ <----------- Rule IPv6 prefix --------->:
+ +-------------------------------+-------+-------------+------+
+ (b) | NAT64+ IPv6 prefix |4rd Tag|IPv4 address | CNP |
+ +-------------------------------+-------+-------------+------+
+ : 64 : 16 : 32 : 16 :
+ 4rd IPv6 address of a host reachable via a NAT64+
+
+ Figure 6: Rules for CE and NAT64+
+
+
+
+Despres, et al. Experimental [Page 22]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ R-12: For anti-spoofing protection, CEs and BRs MUST check that the
+ IPv6 source address of each received Tunnel packet is that
+ which, according to R-9, is derived from the source 4rd IPv4
+ address. For this, the IPv4 address used to obtain the source
+ 4rd IPv4 address is that embedded in the IPv6 source address
+ (in its bits 80-111). (This verification is needed because
+ IPv6 ingress filtering [RFC3704] applies only to IPv6 prefixes,
+ without any guarantee that Tunnel packets are built as
+ specified in R-9.)
+
+ R-13: For additional protection against packet corruption at a link
+ layer that might be undetected at this layer during Domain
+ traversal, CEs and BRs SHOULD verify that source and
+ destination IPv6 addresses have not been modified. This can be
+ done by checking that they remain checksum neutral (see the
+ Note above regarding the CNP).
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 23]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 24]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ +-----------------------------+---+---+---+---+---+---+---+---+
+ | - 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 25]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+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.
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 26]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+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.
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 27]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 28]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 29]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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.
+
+
+
+
+Despres, et al. Experimental [Page 30]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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)
+
+
+
+Despres, et al. Experimental [Page 31]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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)
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 32]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+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>.
+
+
+
+
+
+Despres, et al. Experimental [Page 33]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ [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>.
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 34]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ [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>.
+
+
+
+
+Despres, et al. Experimental [Page 35]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 36]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+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 topology
+
+Appendix 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.
+
+
+
+
+
+Despres, et al. Experimental [Page 37]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 38]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 39]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 40]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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 CNP
+
+C.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.
+
+
+
+
+
+Despres, et al. Experimental [Page 41]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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.
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 42]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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.
+
+
+
+
+
+
+Despres, et al. Experimental [Page 43]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 44]
+
+RFC 7600 Stateless IPv4 Residual Deployment (4rd) July 2015
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Despres, et al. Experimental [Page 45]
+