Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Informational December 29, 2011 Expires: July 1, 2012 IPv4 Residual Deployment via IPv6 - Unified Stateless Solution (4rd-U) draft-despres-softwire-4rd-u-02 Abstract This document specifies an automatic tunneling mechanism tailored for residual deployment of public IPv4 via IPv6 networks (the reverse of 6rd whose purpose is rapid deployment of IPv6 via IPv4). In order to deal with the IPv4-address shortage, customers can be assigned shared IPv4 addresses with statically assigned restricted port sets. Operation is stateless, with no per-customer state in network nodes. 4rd-U unifies in a synthesis features of double-translation-based solutions (in particular compatibility with some IPv6-only middle-box tools inside IPv6 networks), and those of IP-in-IP encapsulation solutions (in particular complete end-to-end transparency to IPv4 packets). It is proposed as a unified standard replacing the two standards that are otherwise envisaged. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 1, 2012. Copyright Notice Copyright (c) 2011 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 Despres Expires July 1, 2012 [Page 1] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The 4rd-U Model . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 5.1. Reversible Header Mapping from IPv4 to IPv6 . . . . . . . 6 5.2. Mappings Rules . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Mappings from IPv6 prefix to Residual-IPv4 prefix . . . . 10 5.4. Mapping from Residual-IPv4 address to IPv6 address . . . . 12 5.4.1. From Residual-IPv4 address to IPv6 prefix . . . . . . 12 5.4.2. From IPv6 prefix to IPv6 address . . . . . . . . . . . 14 5.5. Fragmentation Considerations . . . . . . . . . . . . . . . 16 5.5.1. Ports of Fragments sent to Shared-Address CEs . . . . 17 5.5.2. Datagram-Identification Updates in BRs . . . . . . . . 17 5.6. Translating Tunnel-Generated ICMPv6 into ICMPv4 . . . . . 17 5.7. Provisioning 4rd-U parameters to CEs . . . . . . . . . . . 18 5.8. BR and CE Behaviors . . . . . . . . . . . . . . . . . . . 19 6. Use-Case Examples . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Moving from IPv4-only to IPv6 and Residual IPv4 . . . . . 25 6.2. Residual-IPv4 Service via a Third-Party IPv6 Network . . . 27 6.3. Adding Residual IPv4 to an IPv6-only network . . . . . . . 28 6.4. IPv6 and Residual-IPv4 added to a net-10 network . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Despres Expires July 1, 2012 [Page 2] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 1. Introduction This specification addresses the need for a stateless solution permitting deployments of residual IPv4 service via IPv6 networks (ref. [I-D.ietf-softwire-stateless-4v6-motivation]). The solution, 4rd-U, is stateless in that no per-customer state is needed in network nodes. It does it with an approach reversed from that of 6rd [RFC5969], i.e. with IPv4 tunneled via IPv6 instead of IPv6 tunneled via IPv4. In order to deal with the IPv4-address shortage, customers can be assigned shared IPv4 addresses with statically assigned restricted port sets. The design of 4rd-U builds on previous proposals made for IPv4-via- IPv6 transition technologies, in particular for encapsulation approaches ([I-D.despres-sam][I-D.murakami-softwire-4rd]), for double translation approaches ([RFC6219] [I-D.xli-behave-divi] [I-D.murakami-softwire-4v6-translation] [I-D.xli-behave-divi-pd]), and for attempts at unifying address mappings of the two ([I-D.mdt-softwire-mapping-address-and-port] [I-D.despres-softwire-4rd-addmapping]). It can be viewed as a synthesis that is neither double translation (IP payloads are kept unchanged at tunnel entry and exit), nor encapsulation (there is no IPv4 header between the IPv6 header and the IP payload), but has positive features of both. Implementations may differ depending on whether they start from developments previously made for double translation or for encapsulation, or start from neither, but interworking does not depend on it. ISPs that provide their own CPEs know may implement significantly simplified versions of 4rd-U, taking advantage that they know which 4rd-U parameters apply to their networks. Terminology is defined in Section 3. How the 4rd-U model fits in the Internet architecture is summarized in Section 4. The protocol specification is detailed in Section 5. Section 6 illustrates a few typical 4rd-U use cases. Section 7 and Section 8 respectively deal with security and IANA considerations. 2. Requirements Language 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]. Despres Expires July 1, 2012 [Page 3] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 3. Terminology Residual IPv4: A extension of the IPv4 service where public-IPv4 addresses can be statically shared between some customers. Residual-IPv4 prefix: A prefix that may be an IPv4 prefix, an IPv4 address or an IPv4 address followed the identifier of a restricted port set. Residual-IPv4 address: A non-shared IPv4 address or a shared IPv4 address plus a transport-layer port. Port-set Identifier (PSID): A flexible-length number that algorithmically identifies a set of ports. ISP: Internet-Service Provider. In this document, the offered service can be DSL, fiber-optics, cable, or mobile. The ISP can also be a private-network operator. 4rd-U domain: An ISP-operated IPv6 network in which Residual-IPv4 service is offered according to the present specification. Border Relay (BR): A 4rd-U-capable node at the border between a 4rd-U domain and the IPv4 Internet. Because its operation is stateless, it can, for scalability, be replicated in as many instances as needed. Customer Edge node (CE): A 4rd-U-capable customer node attached to a 4rd-U domain. It can be a host, a router, or both. For Residual IPv4, it includes a NAT44 which maps internal ports used within the CE site into external ports (ref. [RFC1631]). These ports may belong to a restricted port set. IPv4-mapped IPv6 packet: An IPv6 packet used to transparently tunnel an IPv4 packet across a 4rd-U domain. Its payload is the original IPv4 payload. Its addresses are IPv4-mapped IPv6 addresses. Mapping rule: A set of parameters used by BRs and CEs to derive destinations of IPv4-mapped IPv6 packets from IPv4 destinations and port fields of tunneled IPv4 packets, and used by CEs to derive their Residual-IPv4 prefixes from their IPv6 prefixes. Embedded Address bits (EA bits): Bits that are common to a Residual- IPv4 address and the IPv6 address derived from it. Despres Expires July 1, 2012 [Page 4] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 4. The 4rd-U Model How the 4rd-U model fits in the Internet architecture is represented in Figure 1. Border-relay(s) (No per-connexion state) (No per customer state) | 4rd-U DOMAIN | - IPv6 routing (native or 6rd) v - Enforced ingress filtering +-------------------------------+ | | +---------- | | | ... | | | | +----+ IPv4 Customer site | | BR | Internet +--------------------+ | +----+ |CE Residual-IPv4 | | | | | prefix +----+ | | | | statelessly | CE +-+ <-- IPv6 prefix | +---------- | derived from +----+ | | | the CE IPv6 prefix | | +------------ +--------------------+ | | |- CE-CE IPv4 tunnels | ... | follow CE-CE IPv6 routes | IPv6 | (mesh or hub-and-spoke) | Internet |- Some middle-boxes can treat | | tunneled IPv4 packets | | as native IPv6 packets +------------ +-------------------------------+ <== Mapping rules announced to CEs (e.g. in stateless DHCPv6) The 4rd-U Model Figure 1 Despres Expires July 1, 2012 [Page 5] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 5. Protocol Specification 5.1. Reversible Header Mapping from IPv4 to IPv6 At domain entry, IPv4 headers that have no IPv4 option are reversibly mapped into IPv6 headers as shown in Figure 2. Those that have options are discarded with the ICMPv4 error message specified for this in [RFC0792] returned to their sources (Type = 12, Code = 0, Pointer = 20). At domain exit, IPv6 headers are mapped back to original IPv4 headers. Source and destination addresses of IPv6 headers are derived from Residual-IPv4 addresses contained in IPv4 packets as specified in Section 5.4. Reversible IPv4 packet mapping IPv6-mapped IPv4 packet +--------------------+ _ _ +--------------------+ | IPv4 Header | _| =(1)=> | | IPv6 Header | +--------------------+ <=(2)= | +--------------------+ | IP Payload | |_ |IPv6 Fragment Header| +--------------------+ +--------------------+ | IP Payload | +--------------------+ Figure 2 For full transparency to the DF bit of IPv4 (the bit which forbids fragmentation within the network if set to 1), a specific technique is needed because there is no DF bit in IPv6 (fragmentation within the network is always forbidden). For this, an IPv6 Fragment header is systematically present after the IPv6 header, and IPv4 DF bit is copied in one of the 16 unused bits of its Identification field contained in this header. These unused bits exist because the Identification field used for reassembly of fragmented datagrams has 32 bits in IPv6, while it has 16 bits in IPv4. In order to support the two variants of the explicit-congestion- notification mechanism specified in [RFC6040] for tunnels, the IPv4 DSCP and IPv4 ECN are also copied in eight other unused bits of the IPv6 Identification field of the Fragment header. Other than that, the logic of the IPv4 to IPv6 reversible header mapping is straightforward. It is detailed in Table 1, with field names and locations of Figure 3. The reverse header mapping from IPv6 to IPv4 is detailed in Table 1. Despres Expires July 1, 2012 [Page 6] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers=4 |HeadL=5| DSCP |ECN| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Identification |0|D|M| IPv4 Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /\ || \/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers=6 | DSCP |ECN| Flow Label = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length |Next Header=44 | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2nd Next Header| Reserved = 0 | IPv6 Fragment Offset | 0 |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Reserved = 0| IPv4 DSCP | . | IPv4 Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 ECN IP Fields used in the 4rd-U Reversible Header Mapping Figure 3 Despres Expires July 1, 2012 [Page 7] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 +--------+-------------------+--------------------------------------+ | | IPv6 field name | Value (with reference to IPv4 field | | | | names) | +--------+-------------------+--------------------------------------+ | 1 | DSCP | DSCP or ISP parameter | | ------ | ----------------- | ------------------------------------ | | 2 | ECN | ECN or 0 per [RFC6040] (NOTE 1) | | ------ | ----------------- | ------------------------------------ | | 3 | Payload length | Total_ Length - 20 | | ------ | ----------------- | ------------------------------------ | | 4 | Hop limit | Time_to_live | | ------ | ----------------- | ------------------------------------ | | 5 | Source address | AddMapping4to6(Source address) | | ------ | ----------------- | ------------------------------------ | | 6 | Dest. address | AddMapping4to6(Destination address) | | ------ | ----------------- | ------------------------------------ | | 7 | 2nd Next header | Protocol | | ------ | ----------------- | ------------------------------------ | | 8 | Frag. offset | Frag. offset | | ------ | ----------------- | ------------------------------------ | | 9 | M | MF | | ------ | ----------------- | ------------------------------------ | | 10 | D | DF | | ------ | ----------------- | ------------------------------------ | | 11 | IPv4 DSCP | DSCP or 4rd-U-domain parameter | | ------ | ----------------- | ------------------------------------ | | 12 | IPv4 ECN | ECN | | ------ | ----------------- | ------------------------------------ | | 13 | IPv4 | Identification | | | Identification | | +--------+-------------------+--------------------------------------+ Table 1: Header Mapping from IPv4 to IPv6 NOTE 1: [RFC6040] specifies how to process ECNs of IP-in-IP tunnels at their entry and exit endpoints. Whatever applies to "outer- header ECN" and "inner-header ECN" in this RFC applies here to "ECN" and "IPv4 ECN" of IPv4-mapped IPv6 packets. Despres Expires July 1, 2012 [Page 8] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 NOTE 2: Compared to IP-in-IP tunneling of [RFC2473]), 4rd-U has the advantage that tunneled packets look like native IPv6 packets, at least as far as their UDP/TCP port fields are concerned. Thus, IPv6 middle-boxes that check port numbers for access-control have their applicability extended to tunneled IPv4 packets. With the additional precaution of Section 5.4 that IPv6-converted headers have the same contribution to TCP checksums as IPv4 addresses from which they are derived, tunneled TCP/IPv4 packets are also valid as TCP/IPv6 packets. Applicability of IPv6 web caches is thus extended to tunneled IPv4 packets. This is how 4rd-U achieves both the end-to- end transparency of IP-in-IP encapsulation solutions and the compatibility with some IPv6-only middle boxes of double-translation solutions. +--------+-------------------+--------------------------------------+ | | IPv4 field name | Value (with reference to IPv6 field | | | | names) | +--------+-------------------+--------------------------------------+ | 1 | DSCP | IPv4 DSCP | | ------ | ----------------- | ------------------------------------ | | 3 | ECN | Per [RFC6040] (NOTE 1) | | ------ | ----------------- | ------------------------------------ | | 4 | Total Length | Payload length + 20 | | ------ | ----------------- | ------------------------------------ | | 5 | Identification | Bits_16-31(Identification) | | ------ | ----------------- | ------------------------------------ | | 6 | Reserved (1 bit) | 0 | | ------ | ----------------- | ------------------------------------ | | 7 | DF flag | Bit_0(Identification) | | ------ | ----------------- | ------------------------------------ | | 8 | MF flag | M | | ------ | ----------------- | ------------------------------------ | | 9 | Frag. offset | Fragment offset | | ------ | ----------------- | ------------------------------------ | | 10 | Time to live | Hop limit | | ------ | ----------------- | ------------------------------------ | | 11 | Protocol | Next_header(Fragment header) | | ------ | ----------------- | ------------------------------------ | | 12 | Header checksum | 1's complement of the 9 other 16-bit | | | | words of the IPv4 header | | ------ | ----------------- | ------------------------------------ | | 13 | Source address | AddMapping6to4(Source address) | | ------ | ----------------- | ------------------------------------ | | 14 | Dest. address | AddMapping6to4(Destination address) | +--------+-------------------+--------------------------------------+ Table 2: Header Mapping from IPv6 to IPv4 Despres Expires July 1, 2012 [Page 9] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 5.2. Mappings Rules A 4rd-U domain has one or several Mapping rules, each one having the following parameters: o Rule IPv4 prefix o Rule IPv6 prefix o EA-bits length o Rule IPv6 suffix (optional, default ::/0) BRs of a 4rd-U domain are administratively configured with Mapping rules of the domain. CEs are informed of Mapping rules by some automatic tool (see Section 5.7). The first three parameters determine how Residual-IPv4 addresses are mapped into IPv6 addresses, as detailed in Section 5.4. They are also used, in the reverse direction, by each CE to derive its Residual-IPv4 prefix from its delegated IPv6 prefix, as detailed in Section 5.3. Rule IPv6 suffixes are only used in particular cases where CEs are placed behind third-party CPEs, and where these CPEs use some address bits to route packets among their physical ports (see Section 6.2). Where applicable, these suffixes are appended to customer-site IPv6 prefixes to obtain CE-delegated IPv6 prefixes, as detailed in Section 5.3. For IPv4 packets that go from CEs to the IPv4 Internet to always have an IPv6 address derived fro their IPv4 destinations, one Mapping rule MUST apply to IPv4 address whose first bits are arbitrary. This rule is characterized by a Rule IPv4 prefix equal to 0.0.0.0/0. It MUST be unique. 5.3. Mappings from IPv6 prefix to Residual-IPv4 prefix How each CE derives its Residual-IPv4 prefix from its delegated IPv6 prefix is detailed in Figure 4. The first step consists in finding the Mapping rule whose IPv6 prefix has the the longest match with the CE delegated prefix. Despres Expires July 1, 2012 [Page 10] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 +--------------------------------------------+ | CE delegated IPv6 prefix | +--------------------------+-----------+-----+ : Longest match : :<-.->: : || : : \ : \/ : : Length of the +--------------------------+ : Rule IPv6 suffix | Rule IPv6 prefix | : +--------------------------+ : Rule-based substitution : : || : : \/ : : +-----------------+-----------+ |Rule IPv4 prefix | EA bits | +-----------------+-----------+ / \ \ / \ / \ \ / \ / \ \ / \ / \ \ / \ / \ \ / \ / \ / \ / \ / \ \ / \ / \ \ / \ / : \ / \ / : \ : \ / : \ : SHORT CASE \ / LONG CASE \ : \ / : \ : \ / +---------+------+ : / | | | : / \ +---------+------+ : / \ : :\ PSID \ : / : : : :length\ : / : : : : || \ : : : : :4: \/ : +--------------------+--+ +--------+---------+-+-------+---+ | IPv4 address | OR | IPv4 address | Port set | +--------------------+|-+ +--------+---------+|+-------+-|-+ : 32 | : : 32 :| 16 | : | | | any value > 0 any value Mapping between IPv6 prefix and set of Residual-IPv4 addresses Figure 4 Despres Expires July 1, 2012 [Page 11] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 Whether the resulting Residual-IPv4 prefix defines a set of exclusive IPv4 addresses (the SHORT CASE) or a shared IPv4 address with a set of exclusive ports (the LONG CASE), depends on the length of this prefix. Once the Mapping rule that has the longest match is found, this length is determined (it is the sum of the Rule-IPv4-prefix length and the EA-bits length). The LONG CASE applies if this length exceeds 32 bits, the SHORT CASE otherwise. In the LONG CASE, the restricted port set assigned to each CE is specified by the PSID as shown on the Figure 4. The NAT44 of the CE MUST only use ports that belong to this set. NOTE: The choice of the PSID position in Port fields has been guided by the following objectives: (1) for fairness, have the first 1024 ports (the well-known ports) excluded from port sets defined by all PSID value; (2) have in each each port set the two consecutive ports that are required for RTP/RTCP [RFC4961] (for this, PSID length MUST be limited to 11); (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. With the first 4 bits of ports required not to be 0, the first 4096 ports are all excluded instead of just the first 1024; this is a trade-off due to other objectives, in particular nibble alignment. 5.4. Mapping from Residual-IPv4 address to IPv6 address CEs and BRs derive IPv6 destinations of tunneled IPv4 packets in two steps: (1) derivation of the IPv6 prefix from the Residual-IPv4 address found in the IPv4 packet, as detailed in Section 5.4.1; (2) derive from this prefix an IPv6 address, as detailed in Section 5.4.2. 5.4.1. From Residual-IPv4 address to IPv6 prefix The first action consists in finding the Mapping rule whose IPv4 prefix has the the longest match with the IPv4 address. Next actions, detailed in Figure 5, depend on the Rule-IPv4-prefix length plus the EA-bits length. If this sum exceeds 32, the LONG CASE applies, the SHORT CASE otherwise. Despres Expires July 1, 2012 [Page 12] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 +-------------------------------------------+ | IPv6 prefix | +-------------------------------------------+ : : +--------------------------+-----------+----+ | Rule IPv6 prefix | EA bits | | +--------------------------+-----------+----+ /\ : : /\ || : : || Rule-based substitution : : Rule +-----------------+-----------+ IPv6 | Rule IPv4 prefix| EA bits | suffix +-----------------+-----------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / / \ / \ / / \ \ / \ / / : \ / \ / : \ / / \ / : \ : / \ / : \ : SHORT CASE \ / LONG CASE \ : / \ / : \ : / \ / +----------+------+ : : / |IPv4 infix| PSID | : : / \ +----------+------+ : : /\ / \ /\ : :\ /\ \ : /\ : || / : || : : : || \ : || :EA-bits/ :longest: : : PSID \ :longest match:length: : match: :4:length : +-------------+------+--+ +-------+----------+-+--------+---+ | IPv4 address | OR | IPv4 address | Port field | +-------------+------+--+ +-------+----------+-+--------+---+ : 32 : : 32 : 16 : Mapping between Residual-IPv4 address and IPv6 address Figure 5 Despres Expires July 1, 2012 [Page 13] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 In the LONG CASE, the Port field is found in the IPv4-packet payload as follows: o If the packet Protocol is not ICMP, the Port field is where UDP/ TCP have their port numbers (bits 0-15 for an IPv4 source address; bits 16-31 for a destination address). o If the packet is an ICMPv4 error message, the Port field is where TCP has its port number in the returned part of the erroneous packet, with due reversal of source and destination (bits 240-255 for a source address; bits 224-239 for a destination address). o If the packet is an ICMPv4 echo or echo-reply message, the Port field is the ICMPv4 Identification field (bits 32-47). NOTE: For CEs to be able to send Echo-requests across the IPv4 Internet ICMP Identifier fields are used as substitute to transport- layer port fields. CEs can thus send Echo requests to any remote host that has exclusive IPv4 addresses, and receive its response, both if the host is accessible via the IPv4 Internet or if it is in the 4rd-U domain itself. This does not permit however to exchange Echo requests between two hosts having each one a shared address. (This limitation is due to address sharing, not to 4rd-U in particular. Dynamic address sharing schemes such as NAT64 of [RFC6146] have it too.) 5.4.2. From IPv6 prefix to IPv6 address Derivation from IPv6 prefix to IPv6 address has two variants which depend on the IPv6-prefix length (see Figure 6): o If the IPv6 prefix is /64 or shorter, variant (A) is used. o If the IPv6 prefix is a /80, variant (B) is used. In this case, the Rule is necessarily that that which applies to off-domain IPv4 addresses). Despres Expires July 1, 2012 [Page 14] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 (A):<-- IPv6 prefix =< /64 -->: : : : 8 : 8 : 32 : 16 : +---------------------------+---+---+---+---------------+-------+ | CE or BR prefix | 0 | V | 0 | IPv4 address | CNP | +---------------------------+-|-+---+-|-+---------------+--|----+ : Padding: : Reserved Checksum- : : : : neutrality : :<-- 4rd-U-specific prefix in CE -->: preserver : : : :<----- Interface-ID field ---->: (B):<------------------ IPv6 prefix /112 ----------------->: :<------- Rule IPv6 prefix /80 ------->:<-- EA bits -->: : : : : 64 : 8 : 8 : 32 : 16 : +-------------------------------+---+---+---------------+-------+ | BR prefix | V | 0 | IPv4 address | CNP | +-------------------------------+---+---+---------------+-------+ : : : : :<-- 4rd-U specific prefix in BR -->: : : :<----------- 4rd-U specific prefix in CE ------------>: : : : : :<----- Interface-ID field ---->: Mapping from IPv6 prefix to IPv6 Address Figure 6 THE V OCTET A design objective is that CE or BR IPv6 prefixes that are used for IPv4 tunneling can be those that are delegated have for native IPv6, without any constraint native-IPv6 addresses. For this, IPv4-mapped IPv6 addresses are made distinguishable from any valid native IPv6 address. (This can also facilitates maintenance of 4rd-U domains, by making IPv4 tunneled packets recognizable without knowledge of mapping rules, which this is a bonus side effect.) Technically, this is achieved with a 4rd-U specific mark (V) in the first octet of Interface-ID fields. Its "u" and "g" bits of [RFC4291] have to be both set to 1 to differ from their values in native IPv6 unicast addresses. The proposed value of other bits of this octet is 0, giving V = 3 (a value to be endorsed by IANA). Despres Expires July 1, 2012 [Page 15] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 NOTE 1: Both "u" and "g" = 1 is an escape value from native IPv6 addresses because [RFC4291] specifies that: (1) "u" = 0 is reserved for local-scope Interface IDs; (2) "u" = 1 is reserved for addresses that conform to the modified EUI-64 format. These addresses always have "g"=0 because they are unicast while this bit set to 1 would mean "group" address. Using this escape value amounts to a backward compatible update of [RFC2460]. If approved in Softwire, it should therefore to be submitted to the 6man working group for endorsement. NOTE 2: The name V is chosen to evoke its being different the u octet of IPv4-embedded IPv6 addresses specified for NAT64s in [RFC6146]. These IPv4-embedded addresses also contain IPv4 addresses but do not meet the above-mentioned design objective: their Interface IDs are not distinguishable from those of valid private-scope IPv6 addresses. CHECKSUM NEUTRALITY In order to ensure that IPv4 payloads are also valid as IPv6 payloads for transport-layer protocols that have TCP-like checksums (TCP, UDP, DCCP, possibly some others in the future), IPv4-mapped IPv6 addresses MUST have the same contribution to these checksums as their contained IPv4 addresses. For this, a 16-bit Checksum-neutrality-preserver field (CNP) is placed in the end of these IPv6 addresses. With IPv4 addresses themselves copied in address bits 72-103, i.e. at 16-bit word boundaries, the CNP value needs only to be the opposite of the checksum of other address bits. 5.5. Fragmentation Considerations Absent more specific information, the path MTU of a 4rd Domain SHOULD be set to 1280 (the value all IPv6 networks MUST support according to [RFC2460]). ISPs that know that a larger PMTU applies everywhere in 4rd-U domain SHOULD announce it to CEs to achieve better performance. If an IPv4 packet enters a CE or BR with a size that exceeds the Domain PMTU minus 28, the size of the IPv4-mapped IPv6 packet derived from it would exceed the PMTU. If the packet has DF=1, it MUST be discarded, with an ICMP error message returned to the source. Otherwise, fragmentation is necessary. It is part of BR and CE behaviors specified in Section 5.8. Combining fragmentation processing with shared-address processing imposes two specific precautions, as detailed below. (Note: this is due to stateless address sharing, independently from whether the technology used for IPv6-network traversal is 4rd-U, or encapsulation-based, or double-translation based). Despres Expires July 1, 2012 [Page 16] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 5.5.1. Ports of Fragments sent to Shared-Address CEs Because ports are available only in first fragments of fragmented datagrams, a BR or CE needs a mechanism to send all fragments of a fragmented datagrams to the right shared-address CEs. This can be done by systematically reassembling fragmented IPv4 datagrams destined to shared-address CEs before tunneling them. However, for less memory space consumption, for less sensitivity to denial of service attacks, and for less forwarding delays, all fragments SHOULD preferably be forwarded on the fly. For this, the BR or CE SHOULD note which destination port applies to which partially transmitted datagram, and use this information to address all fragments to the right CE. BR and CE behaviors of Section 5.8 include this function. (Note: this need is due to stateless address sharing, independently from whether the technology used for IPv6-network traversal is 4rd-U or another). 5.5.2. Datagram-Identification Updates in BRs When a BR forwards IPv4 packets that come from two CEs sharing the same IPv4 address, and that go to the same destination, it has to guarantee that their Identifications have different values. Otherwise, the reassembly process, which is based on source address, destination address, and Identification, can be confused in the destination. (Note: this also is due to stateless address sharing, independently from whether the technology used for IPv6-network traversal is 4rd-U, or encapsulation-based, or double-translation based). This need applies even to forwarded IPv4 packets that are not fragmented because they may be fragmented farther on their way to their destinations. Section 5.8 describes a particular way to do it. 5.6. Translating Tunnel-Generated ICMPv6 into ICMPv4 If an IPv4-mapped IPv6 packet is discarded on its way across a 4rd-U domain, an ICMPv6 error message is returned to the IPv6 source, i.e. to the BR anycast address or to a CE address. For the source of the IPv4 packet to be informed, an ICMPv4 packet MUST be sent to it. Type, or Type and Code, of the ICMPv4 packet MUST be for this translated from those the ICMPv6 message, and the ICMP checksum MUST be updated, according to what is specified for error messages in Section 5.2 of [RFC6145]. Despres Expires July 1, 2012 [Page 17] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 A source IPv4 address is needed for such ICMPv4 packets. The proposed value is 192.70.192.254. (It is taken in the /24 range proposed in [I-D.xli-behave-icmp-address] for a similar purpose). 5.7. Provisioning 4rd-U parameters to CEs CEs MUST be configured with Mapping rules of their domain (ref. Section 5.2). In addition they SHOULD be configurable with the following optional parameters: 1. Domain path MTU (16 bits, default = 1280) 2. ECN compatibility mode (1 bit, default = No) - ref. Section 5.1 3. Tunnel DSCP (6 bits, default N/A) In order to guarantee that all independently provisioned CEs can work on all 4rd-U domain, the a number of Mapping rules every CEs must support has to be standardized. The proposed value is 32, a tradeoff between flexibility, maximum processing times, and volume of parameters to be provisioned to CEs. (Editor's note: this number is neither critical nor easy to change, a working-group consensus for another value wouldn't be a problem.) 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_4RD_RULE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix4-len | prefix6-len | ea-len | suffix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv4-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ipv6-prefix + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rule-ipv6-suffix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv6 format for Mapping rules Figure 7 This document describes how to configure the necessary parameters with DHCPv6 options. Despres Expires July 1, 2012 [Page 18] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 CEs may also be configured in a variety of other manners, including provisioning methods such as the Broadband Forum's "TR-69" [TR069] Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration by an administrator. For consistency and convenience of implementation on CEs that support multiple configuration methods, these other configuration and management methods may use formats chose for DHCPv6. The proposed format for Mapping-rule parameters is presented in Figure 7. If the prefix6-len is less than 64, the provided ip-v6-prefix is taken as Rule IPv6 prefix. If this length is 64, the Rule IPv6 prefix has format B in Figure 6, i.e. is a /80. It is built by appending to the provided ip-v6-prefix a V octet and a null octet. In this case, the rule IPv4 prefix is 0.0.0.0/0, and EA-bits length is 32. If provided values are different, they SHOULD be ignored. The proposed format for other parameters is presented in Figure 8. 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_4RD_PARAM | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | path-mtu |C| reserved = 0| tunnel-dscp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+|+-+-+-+-+ | | Compatibility mode of RFC6040 (= -1 if non applicable) (= 1 if applicable) DHCPv6 format for 4rd-U-domain parameters Figure 8 5.8. BR and CE Behaviors BRs and CEs MUST have the behaviors that, as far as CE-BR and CE-CE protocols are concerned, are equivalent to what follows. Despres Expires July 1, 2012 [Page 19] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 BR INITIALIZATION When a BR is configured with 4rd-U parameters, it MUST note, for anti-spoofing and anti-routing-loop protection, the set of its incoming IPv4 prefixes from the Internet. Also, it SHOULD compute the first 80 bits and the CNP part of its IPv4-mapped IPv6 addresses to avoid doing it repeatedly. If at least one Mapping rule concerns CE shared IPV4 addresses, i.e. if the sum of its Rule-IPv4-prefix length and EA-bits length exceeds 32, the BR MUST initialize an "IPv6-ID table" and an "IPv4-ID table" to be used for fragmentation processing (see Section 5.5). These tables are initially empty. Each record of the IPv6-ID table is specific of a shared-address CE that is currently transmitting a fragmented datagram. It contains: o The CE IPv6 prefix. o A CE IP identification. This is the IPv4 Identification provided by the CE for the current fragmented datagram. o A BR IP identification or NIL. This is the IPv4 Identification provided by the BR to replace the CE IP Identification Section 5.5. It is NIL for a fragmented datagram that the BR is currently discarding because a fragment has been found to be missing. The BR also initializes a generator of BR IP identifications. It provides different values at each request, with a time between value re-use much longer than any realistic time for any fragmented datagram reception. Each record of the IPv4-ID table is specific of a fragmented datagram whose fragments are currently being relayed toward a shared address CE. It contains: o The IPv4 source address. o The IP identification. o The Destination port. A garbage collection has to be set up for records of the two tables that remain unchanged for much more than the maximum time a fragmented-datagram reception may take. This value, which is not critical, MAY be set to 30 seconds. Despres Expires July 1, 2012 [Page 20] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 BR RECEPTION OF AN IPv4 PACKET When a BR receives an IPv4 packet: 1. For anti-spoofing protection, the BR checks that the source address of the IPv4 packet does not start with one of BR incoming prefixes from the Internet. If the check fails, the packet is silently discarded. Otherwise, the BR completes the IPv4-mapped IPv6 address to be used as IPv6 source address by including in it the IPv4 source address. 2. If the IPv4 packet is longer than the 4rd-U-domain PMTU minus 28, and has its DF bit set, the packet is silently discarded, and its processing is terminated. 3. If the packet is not a complete datagram (i.e. has MF=1 or Offset > 0), and if the Mapping rule whose Rule IPv4 prefix matches the IPv4 source address is one of shared-address CEs (i.e. if Rule- IPv4-prefix length plus EA-bits length exceeds 32), the the BR searches the IPv4-ID table for a record whose IPv4 source address and IP identification match those of the received packet. It then does the following: * If NO matching record is found: + If the packet is a first fragment (i.e. has Offset = 0), a new record is created with values found in the packet. + If the packet is an intermediate or last fragment (i.e. has Offset > 0), it is discarded, and packet processing is terminated. * If a matching record is found: + If the packet is a first fragment (i.e. has Offset = 0): it is discarded; the record is deleted, and packet processing is terminated. + If the packet is an intermediate or last fragment (i.e. has Offset > 0), the Destination port of the record is taken a the port of this packet to be used to derive the destination IPv6 address. + If the packet is a last fragment (i.e. has Offset > 0 and MF = 0): the record is deleted. Despres Expires July 1, 2012 [Page 21] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 4. The BR derives the destination IPv4-mapped IPv6 address from the Residual-IPv4 destination of the IPv4 packet according to Section 5.4. 5. The BR derives the IPv6 header and its Fragment extension from the IPv4 header according to Section 5.1, and forwards the resulting packet in IPv6, fragmented if necessary. BR RECEPTION OF AN IPv6 PACKET When a BR receives an IPv6 packet, it does the following steps: 1. If the packet is an ICMPv6 packet, the BR translates it to an ICMPv4 packet according to Section 5.6, and forwards it in IPv4. 2. If the Mapping rule whose Rule IPv6 prefix matches the IPv6 source address is one of shared-address CEs (i.e. if Rule-IPv4- prefix length plus EA-bits length exceeds 32), the BR searches the IP-identification table for a record whose CE IPv6 prefix matches the IPv6 source address, and does the following: * If NO matching record is found: + If the packet is a complete datagram (i.e. has Offset = 0 and MF = 0), a new BR IP identification is obtained from the generator; the CE replaces the IPv4 identification by the new one. + If the packet is a first fragment (i.e. has Offset = 0 and MF = 1), a new BR IP identification is obtained from the generator; the CE replaces the IPv4 identification by the new one; a record is created containing, (1) the CE IPv6 prefix (the Rule IPv6 prefix followed by EA bits whose length is found in the Mapping rule), (2) the received IPv4 identification as CE IP identification, (3) the new BR IP identification. + If the packet is an intermediate or last fragment (i.e. has Offset > 0), it is discarded, and packet processing is terminated. Despres Expires July 1, 2012 [Page 22] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 * If a matching record is found: + If the packet is a complete datagram (i.e. has Offset = 0 and MF = 0), a new BR IP identification is obtained from the generator; the CE replaces the IPv4 identification by the new one; the record is deleted. + If the packet is a first fragment (i.e. has Offset = 0 and MF = 1), a new BR IP identification is obtained from the generator; the CE replaces the IPv4 identification by the new one; the record is updated with it. + If the packet is an intermediate fragment (i.e. has Offset > 0 and MF = 1), it is discarded if the record has NIL as BR IP identification. It is also discarded, and BR IP identification is set to NIL, if the received CE IP identification differs from that of the record. Otherwise, the CE replaces the IPv4 identification by the BR IP identification of the record. + If the packet is a last fragment (i.e. has Offset > 0 and MF = 0): if the record has NIL as BR IP identification, or if the received CE IP identification differs from that of the record, the record is deleted, the packet is discarded, and packet processing is terminated. Otherwise, the the CE replaces the IPv4 identification by the BR IP identification of the record, and the record is deleted. 3. The BR checks that the IPv6 source address of the received packet matches the IPv6 prefix that is derived from the source Residual- IPv4 address (this Residual-IPv4 address is the IPv4 address found in the source IPv6 address followed by the port field of the IP payload). It also checks, for anti-routing-loop protection, that the destination IPv4 address does not start with one of the list of incoming prefixes from the Internet. In case of failure of either check, the packet is silently discarded and packet processing is terminated. 4. The IPv6 header and its Fragment extension are mapped back to the original IPv4 header. The packet is forwarded in IPv4. Despres Expires July 1, 2012 [Page 23] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 CE INITIALIZATION When a CE receives 4rd-U parameters, it checks that there is one and only one rule that has a 0.0.0.0/0 as Rule IPv4 prefix. If yes, it computes its CE Residual-IPv4 prefix according to Section 5.4, and activates its 4rd-U function. It informs its NAT44 of the IPv4 prefix, or IPv4 address, or IPv4 address plus restricted port set, which is specified by this Residual-IPv4 prefix. If this prefix is a /32 or longer, the CE derives from it its IPv4-mapped IPv6 address. If it is shorter, the CE computes the first 80 bits and the CNP part of its multiple IPv4-mapped IPv6 addresses. CE TRANSMISSION OF AN IPv6 PACKET When a CE has an IPv4 packet to transmit, coming from its NAT44: 1. If the IPv4 packet is longer than the 4rd-U-domain PMTU minus 28, and has its DF bit set, the packet is silently discarded, and its processing is terminated. 2. If the CE has a Residual-IPv4 prefix shorter than /32, it completes the IPv4-mapped IPv6 address to be used as source by copying in it the IPv4 source of the packet. 3. The CE derives the destination IPv4-mapped IPv6 address from the Residual-IPv4 destination of the IPv4 packet. 4. The CE derives an IPv6 header and it Fragment extension from the IPv4 header. The resulting packet is forwarded in IPv6. CE RECEPTION OF AN IPv6 PACKET When a CE receives an IPv6 packet: 1. If the packet is an ICMPv6 packet, it translates it to an ICMPv4 packet according to Section 5.6, and forwards it in IPv4. 2. If the packet contains a fragment of an incomplete datagram: the CE submits the fragment to IPv6 reassembly; if the datagram is the last one needed to reassemble a datagram the CE proceeds to the next step with the completed datagram; if not this terminates packet processing. Despres Expires July 1, 2012 [Page 24] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 3. The CE checks that the IPv6 source address of the received packet matches the IPv6 prefix that is derived from the source Residual- IPv4 address (this Residual-IPv4 address is the IPv4 address found in the source IPv6 address followed by the port field of the IP payload). 4. The IPv6 header and its Fragment extension are mapped back to the original IPv4 header. The packet is forwarded in IPv4. 6. Use-Case Examples Examples presented in this section are selected to illustrate a few reference use cases from which real ones can be inspired. Looking at details of each of these use case, or even to one of them, is not necessary to understand how 4rd-U works. This may however be useful to check one's understanding, and to get an idea of the diversity of possible use cases. Mapping rules of examples of this section are noted as follows: {Rule IPv6 prefix, Rule IPv4 prefix, EA-bits length, Rule IPv6 suffix}. The Rule IPv6 suffix can be omitted if it has its ineffective value ::/0. Examples: {198.32.0.0/13, 2001:db8::/33, 23, 5000::/4}, {198.32.0.0/13, 2001:db8::/33, 23} 6.1. Moving from IPv4-only to IPv6 and Residual IPv4 We consider an ISP that offers IPv4 service to its customers. Each customer is assigned an IPv4 address starting with one of the two following IPv4 prefixes: 198.32.0.0/13, 192.16.0.0/14. and wishes to assign to a new class of customers shared IPv4 addresses, using for this a distinct iPv4 prefix, 192.24.0.0/14, and 16 as sharing ratio. The ISP, because it provides its own CPEs to customers, can for this generalize 4rd-U. It also wants to switch from IPv4-only routing to IPv6-only routing, planning for this two phases: during the first one, all CPE's are updated to support IPv6 and 4rd-U, and the IPv6 routing plan that parallels the IPv4 routing plan is deployed; during the second phase, the IPv4 routing plan is deleted. The IPv6 prefix to be used by the ISP, its "common IPv6 prefix", is supposed to be 2001:db8::/32. Delegated IPv6 prefixes are chosen to be /56s. The IPv6 prefix assigned to BRs chosen to be 2001:db8:8000: 1::/64 Despres Expires July 1, 2012 [Page 25] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 Mapping rules for this network can then be the following. {192.32.0.0/13, 2001:db8:1800:/37, 19} {198.16.0.0/14, 2001:db8:1400::/38, 18} {198.24.0.0/14, 2001:db8:4000::/34, 22} (shared addresses) {0.0.0.0/, 2001:db8:8000:1::/64, 32} (domain exit) A CE that had IPv4 address 198.32.1.1 (0xc6200101) now derives its IPv4 address from its delegated IPv6 prefix 2001:db8:1801:100::/56 as follows: Useful bits in nibbles => First Last | | CE IPv6 prefix 2001 0DB8 1801 01 4 4 Rule IPv6 prefix 2001 0DB8 18 4 1 EA bits 001 01 3 4 Rule IPv4 prefix C6 20 4 1 (198.32.0.0/13) IPv4 address C6 2001 01 4 4 i.e. 198.32.1.1 The IPv6 address derived from IPv4 address 198.32.1.1 (0xC6200101); and any value 0xZZZZ in the port field is obtained as follows: Useful bits in nibbles => First Last | | Residual-IPv4 address C620 0101 ZZZZ 4 4 Rule IPv4 prefix C620 4 2 EA bits 0 0101 2 4 Rule IPv6 prefix 20 010D B818 4 2 Derived IPv6 prefix 20 010D B818 0101 4 4 Derived IPv6 address 2010 0DB8 1801 1000 0300 C620 0101 XXXX i.e. 2001:db8:1801:100:300:c618:0101:XXXX where XXXX = - UDP_Checksum(2001:db8:1801:100:300::/80) A new CE has shared IPv4 address 198.24.1.1 and PSID 0x2. It derives its IPv4 address and PSID from its delegated IPv6 prefix 2001:db8: 4010:1200::/56 as follows : Useful bits in nibbles => First Last | | CE IPv6 prefix 2001 0DB8 4010 12 4 4 Rule IPv6 prefix 2001 0DB8 4 4 1 IPv4 infix 0010 0 2 4 PSID 2 4 4 (0x2) Rule IPv4 prefix C61 8 4 2 (198.24.0.0/14) IPv4 address C61 8010 1 4 4 i.e. 198.24.1.1 Ports in set Y2XX with Y > 0, and XX any value Despres Expires July 1, 2012 [Page 26] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 The IPv6 address derived from IPv4 address 198.24.1.1 (0xC6180101) and 0x1200 in the port field is obtained as follows: Useful bits in nibbles => First Last | | Residual-IPv4 address C618 0101 1200 4 4 Rule IPv4 prefix C618 4 2 IPv4 infix 0 0101 2 4 PSID 2 4 4 Rule IPv6 prefix 2 0010 DB84 4 2 Derived IPv6 prefix 2 0010 DB84 0101 2 4 4 Derived IPv6 address 2001 0DB8 4010 1200 0300 C618 0101 XXXX i.e. 2001:db8:4010:1200:300:c618:0101:XXXX where XXXX = - UDP_Checksum(2001:db8:4010:1200:300::/80) 6.2. Residual-IPv4 Service via a Third-Party IPv6 Network An ISP wants to offer Internet service to its customers, both IPv4 and IPv6, using for this an IPv6-only service deployed by a third party. This third party provides its own CPEs and uses an hexadecimal digit to index their physical ports. This digit is appended to site IPv6 prefixes to build prefixes that reach CPE ports to which 4rd-U CEs are attached. On the third-party network, customer sites of the ISP are delegated /56 prefixes, all starting with 2001:db8::/32. The ISP supplies its own CEs to its customers, with NAT44s adapted to restricted port sets. All CEs are attached to CPEs at their ports whose index is 0x5. The IPv6 prefix routed to BRs sites is supposed to be 2001:db8:8080:8080::/56. To offer IPv4 connectivity to its potential 2^(56-32)=2^24 CEs, the ISP is supposed to have an IPv4 space of only 2^20 addresses. Each IPv4 address has thus to be shared among 16 customers. The IPv4 address space available is supposed to have three prefixes 198.32.0.0/13, 192.16.0.0/14, and 192.24.0.0/14, (the same as in Section 6.1). The following Mapping rules provide the desired Residual-IPv4 service: {192.32.0.0/13, 2001:DB8::/33, 23, 5000::/4} {c610::/14, 2001:DB8:8000::/34, 22, 5000::/4} {198.24.0.0/14, 2001:DB8:C000::/34, 22, 5000::/4} {0.0.0.0/, 2001:DB8:8080:8080::/56, 0, 5000::/4} Despres Expires July 1, 2012 [Page 27] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 With these Mapping rules, a CE whose IPv6 prefix is 2001:db8:d111: 1100::/56 derives its IPv4 address and its port set as follows: Useful bits in nibbles => First Last | | CE allocated prefix 2001 0DB8 C111 115 4 4 Rule IPv6 prefix 2001 0BB8 C 4 2 EA bits 0111 11 2 4 Rule IPv4 prefix C61 8 4 2 IPv4 address C61 8111 1 4 4 (192.24.33.33) PSID 1 4 4 Ports in port set Y1XX 4 4 (Y > 0, any xx) The IPv6 address that is derived from IPv4 address 192.24.33.33:4352 (0xC6181111), is obtained as follows: Useful bits in nibbles => First Last | | Residual-IPv4 address C618 1111 1100 4 4 Rule IPv4 prefix C618 4 2 IPv4 infix 0 1111 2 4 PSID 1 4 4 EA bits 0 1111 1 2 4 Rule IPv6 prefix 2 0010 DB8C 4 2 Derived IPv6 prefix 2 0010 DB8C 1111 15 4 4 Derived IPv6 address 2001 0DB8 C111 1150 0300 C618 1111 XXXX i.e. 2001:0db8:c111:1150:0300:c618:1111:XXXX in which XXXX = - UDP_Checksum(2001:0db8:c111:1150:0300::/80) 6.3. Adding Residual IPv4 to an IPv6-only network An ISP offers an IPv6-only service on one of its infrastructures. It wishes to also offer on it residual IPv4 connectivity, both outgoing and incoming. For this, it wishes to offer a simpler solution for that of NAT64/DNS64 and PCP [RFC6146][RFC6147][I-D.ietf-pcp-base]. It assigns /56 prefixes to its customers, all starting with 2001: db8::/32. The available IPv4 prefix is 192.16.0.0/16 (0xC620), so that a sharing ratio of 256 is needed. The ISP then installs one or several identical BRs at its border to the IPv4 Internet, accessible for example at IPv6 prefix 2001:db8:0: 100::/56, and can use the following Mapping rules: {192.16.0.0/16, 2001:db8::/32, 24} {0.0.0.0/, 2001:db8:0:100:/56, 0} Despres Expires July 1, 2012 [Page 28] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 6.4. IPv6 and Residual-IPv4 added to a net-10 network An ISP has deployed an IPv4 network with [RFC1918] addresses 10.x.x.x, and with one or several NAT44s at its border to the public IPv4 Internet. It wishes to add IPv6 service to this "net-10 network" but, because some of its network hardware is not ready for IPv6 yet, plans to deploy IPv6 with 6rd (xref target="RFC5969"/> It also wishes to offer incoming IPv4 connectivity to its customers with a simpler solution than that of PCP [I-D.ietf-pcp-base]. The IPv6 prefix to be used for 6rd is 2001:db8::/32, and the public IPv4 prefix to be used for shared addresses is 192.16.0.0/16 (0xc610). In conformance with [RFC5969], 6rd BRs are configured with the following parameters IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32; 6rdBRIPv4Address = 192.168.0.1 (0xC0A80001). 4rd-U is supported with one or several 4rd-U BRs, at the ISP border to the IPv4 Internet, which support both 6rd CE function in addition to their 4rd-U BR function. They are supposed to be reachable at the IPv4 anycast address 10.0.0.1. The following 4rd-U Mapping rules are then configured in BRs and announced to CEs: {192.16.0.0/16, 2001:db8::/32, 24} {0.0.0.0/, 2001:db8:c0a8:2:3000:/80, 32} Once this is done, any customer device that supports 4rd-U can freely use its assigned public-IPv4 address subject to its assigned restricted port set of 240 ports. Packets that use this address are mapped into IPv6 packets and encapsulated in IPv4 private-address packets. 7. Security Considerations Spoofing attacks With checks of Section 5.8 that Residual-IPv4 source addresses are consistent with IPv6 sources addresses, and that source IPv4 addresses coming from the Internet are not among those allocated to the 4rd-U domain, no opportunity for spoofing attacks in IPv4 is introduced by 4rd-U. Despres Expires July 1, 2012 [Page 29] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 Routing-loop attacks Routing-loop attacks that may exist in some automatic-tunneling scenarios are documented in [RFC6324]. They cannot exist in 4rd-U because of BRs checks that IPv4 destination of packets they forward to the IPv4 Internet do not start with IPv4 prefixes for which BRs have incoming routes from the Internet. Denial-of-service attacks As discussed in Section 5.5, BRs that support shared-address rules must maintain dynamic tables of fragmented datagrams that currently traverse them. * In the CE to Internet direction, this brings no new DOS-attack vulnerability because the table has at most one record per CE. * In the Internet to CE direction, a vulnerability remains: a single remote hosts may send a large number of first datagram fragments without sending the next ones, thus occupying many table records. Note however that the occupied space in memory is much lower than if datagrams should be reassembled before being forwarded, and that table overflow has no impact on non- fragmented datagrams, which normally are the vast majority in TCP. 8. IANA Considerations IANA is requested to allocate the following: o An IPv6 Interface-ID type reserved for 4rd-U (the V octet of Section 5.4, whose proposed value is 0x03). This value needs to belong to a new registry to be created, for Interface-ID types that have neither local scope nor Modified EUI-64 format (ref. [RFC4291]). o A reserved IPv4 address to be used as source of ICMPv4 messages translated from ICMPv6 error messages. Its proposed value is 192.70.192.254 (Section 5.6). o Two DHCPv6 option codes, to be defined, for the OPTION_4RD_RULE and OPTION_4RD_PARAM of Section 5.7. Despres Expires July 1, 2012 [Page 30] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 9. Contributors and Acknowledgements TBD. This version is expected to be discussed, on the Softwire mailing list or otherwise, and to be improved following remarks and suggestions from interested contributors. So far, it has benefited from productive discussions with Maoke Chen and Qiong Sun following IETF 82, in particular concerning the relationship between 4rd-U an [RFC6145]. 10. References 10.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 10.2. Informative References [I-D.despres-sam] Despres, R., "Stateless Address Mappings (SAMs) IPv6 & extended IPv4 via local routing domains - possibly multihomed", draft-despres-sam-01 (work in progress), November 2008. [I-D.despres-softwire-4rd-addmapping] Despres, R., Qin, J., Perreault, S., and X. Deng, Despres Expires July 1, 2012 [Page 31] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 "Stateless Address Mapping for IPv4 Residual Deployment (4rd)", draft-despres-softwire-4rd-addmapping-01 (work in progress), September 2011. [I-D.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-19 (work in progress), December 2011. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-softwire-stateless-4v6-motivation-00 (work in progress), September 2011. [I-D.mdt-softwire-mapping-address-and-port] Troan, O., "Mapping of Address and Port (MAP)", draft-mdt-softwire-mapping-address-and-port-02 (work in progress), November 2011. [I-D.murakami-softwire-4rd] Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-01 (work in progress), September 2011. [I-D.murakami-softwire-4v6-translation] Murakami, T., Chen, G., Deng, H., Dec, W., and S. Matsushima, "4via6 Stateless Translation", draft-murakami-softwire-4v6-translation-00 (work in progress), July 2011. [I-D.shirasaki-nat444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work in progress), July 2011. [I-D.xli-behave-divi] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03 (work in progress), July 2011. [I-D.xli-behave-divi-pd] Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun, "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation", draft-xli-behave-divi-pd-01 (work in progress), September 2011. Despres Expires July 1, 2012 [Page 32] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 [I-D.xli-behave-icmp-address] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", draft-xli-behave-icmp-address-04 (work in progress), May 2011. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Despres Expires July 1, 2012 [Page 33] Internet-Draft Unified IPv4 Residual Deployment (4rd-U) December 2011 Coexistence and Transition", RFC 6219, May 2011. [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, August 2011. Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Email: despres.remi@laposte.net Despres Expires July 1, 2012 [Page 34]