Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7600

IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)

Pages: 45
Part 1 of 2 – Pages 1 to 23
None   None   Next

Top   ToC   RFC7600 - Page 1
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
                                                                 G. Chen
                                                            China Mobile
                                                                 M. Chen
                                                              BBIX, Inc.
                                                               July 2015

     IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)


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
Top   ToC   RFC7600 - Page 2
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
   ( 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.
Top   ToC   RFC7600 - Page 3

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
Top   ToC   RFC7600 - Page 4

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
Top   ToC   RFC7600 - Page 5
   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.
Top   ToC   RFC7600 - Page 6
   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.
Top   ToC   RFC7600 - Page 7

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).
Top   ToC   RFC7600 - Page 8
   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.
Top   ToC   RFC7600 - Page 9
   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].
Top   ToC   RFC7600 - Page 10

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).
Top   ToC   RFC7600 - Page 11
   "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.
Top   ToC   RFC7600 - Page 12
   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
Top   ToC   RFC7600 - Page 13
   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)
Top   ToC   RFC7600 - Page 14
    | 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)
Top   ToC   RFC7600 - Page 15
    | 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

   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).
Top   ToC   RFC7600 - Page 16
   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
Top   ToC   RFC7600 - Page 17

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
Top   ToC   RFC7600 - Page 18
         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.
Top   ToC   RFC7600 - Page 19

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
Top   ToC   RFC7600 - Page 20
   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."


         "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

              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).
Top   ToC   RFC7600 - Page 21
              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.
Top   ToC   RFC7600 - Page 22
         (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+
Top   ToC   RFC7600 - Page 23
   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).

(page 23 continued on part 2)

Next Section