Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Informational January 28, 2012 Expires: July 31, 2012 IPv4 Residual Deployment via IPv6 - Unified Solution (4rd-U) draft-despres-softwire-4rd-u-03 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 neither per-connection nor per-customer state needed in network nodes. 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 31, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Despres Expires July 31, 2012 [Page 1] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The 4rd Model . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 4.1. 4rd Domain parameters . . . . . . . . . . . . . . . . . . 6 4.2. Headers of Encapsulation and Header-Mapping Variants . . . 8 4.3. From CE IPv6 Prefixes to IPv4 Addresses and Port sets . . 11 4.3.1. From CE IPv6 Prefix to CE 4rd Prefix . . . . . . . . . 11 4.3.2. From PSID to Port Set . . . . . . . . . . . . . . . . 12 4.4. From IPv4 addresses and Ports to IPv6 Addresses . . . . . 13 4.4.1. From 4rd Address to IPv6 Prefix . . . . . . . . . . . 13 4.4.2. From IPv6 Prefix to IPv6 Address . . . . . . . . . . . 15 4.5. Fragmentation Considerations . . . . . . . . . . . . . . . 17 4.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 4.5.2. Ports of Fragments sent to Shared-Address CEs . . . . 17 4.5.3. Datagram Identifications from Shared-Address CEs . . . 18 4.6. TOS and Traffic-Class Considerations . . . . . . . . . . . 20 4.7. Tunnel-Generated ICMPv6 Error Messages . . . . . . . . . . 20 4.8. Provisioning 4rd Parameters to CEs . . . . . . . . . . . . 21 5. Use-Case Examples . . . . . . . . . . . . . . . . . . . . . . 21 5.1. How to choose Mapping Rules . . . . . . . . . . . . . . . 21 5.2. Adding Shared IPv4 Addresses to an IPv6 Network . . . . . 22 5.2.1. IPv6 network of the ISP . . . . . . . . . . . . . . . 22 5.2.2. IPv6 Network of a Third-Party Provider . . . . . . . . 24 5.3. Replacing Dual-stack Routing by IPv6-only Routing . . . . 25 5.4. Adding IPv6 and 4rd Service to a Net-10 network . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. Relationship with Previous Works . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Despres Expires July 31, 2012 [Page 2] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 1. Introduction This specification addresses the need for a stateless solution permitting deployments of residual IPv4 service via IPv6 networks, as expressed in [I-D.ietf-softwire-stateless-4v6-motivation]. The solution, named 4rd for IPv4 residual deployment, needs neither per- connection nor per-customer states in network nodes. With it, IPv4 packets are tunneled across IPv6 networks in a design reverse of that of 6rd [RFC5969] whereby IPv6 packets are tunneled across IPv4 networks. 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 builds on a number of previous proposals made for IPv4-via-IPv6 transition technologies listed in Section 9. It includes in a common framework two formats of tunnel packets. The Header-mapping variant is similar to a double-translation solution based on the IPv6/IPv4 translation of [RFC6145]. Like them, it permits middle boxes to operate on tunneled IPv4 packets as though they would be native IPv6 packets, in particular for port-based access control lists, and for website redirects. In addition to these, it preserves complete network transparency to IPv4 packets, and is self contained. The Encapsulation variant does not have this middle-box compatibility but is algorithmically simpler. Terminology is defined in Section 2. How the 4rd model fits in the Internet architecture is summarized in Section 3. The protocol specification is detailed in Section 4. Section 5 illustrates a few typical 4rd use cases. Section 6 and Section 7 respectively deal with security and IANA considerations. Previous proposals that influenced this specification are listed in Section 9. 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]. 2. Terminology 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. Despres Expires July 31, 2012 [Page 3] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 4rd (IPv4 Residual Deployment): An extension of the IPv4 service where public-IPv4 addresses can be statically shared with restricted port sets assigned to customers. 4rd domain (or Domain): An ISP-operated IPv6 network in which 4rd service is offered according to the present specification. BR (Border Relay): A 4rd-capable node at the border between a 4rd domain and the IPv4 Internet. Because its operation is stateless, it can be replicated in as many instances as needed for scalability. CE (Customer Edge node): A 4rd-capable customer node attached to a 4rd domain. It can be a host, a router, or both. PSID (Port-Set Identifier): A flexible-length field that algorithmically identifies disjoint port sets. 4rd prefix: A flexible-length prefix that may be an IPv4 prefix, an IPv4 address, or an IPv4 address followed by a PSID. 4rd address: An IPv4 address or, in case of a shared IPv4 address, an IPv4 address plus a port number. Tunnel packet: An IPv6 packet that conveys an IPv4 packet across a 4rd domain. Its payload is either the original IPv4 payload (Header-mapping variant), or the complete IPv4 packet (Encapsulation variant). Mapping rule: A set of parameters that BRs and CEs use to derive IPv6 addresses from 4rd addresses. They are also used by CEs to derive their own 4rd prefixes from their IPv6 delegated prefixes. EA bits (Embedded Address bits): Bits that, in prefixes and addresses, are the same in 4rd and in IPv6. Default mapping rule: The mapping rule that applies to off-domain IPv4 addresses. CNP (Checksum Neutrality preserver): A field that, in the Header- mapping variant, ensures that contributions to UDP/TCP-like checksums of the transport layer remain valid despite replacements of IPv4 addresses by IPv6 addresses. Despres Expires July 31, 2012 [Page 4] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 3. The 4rd Model How the 4rd model fits in the Internet architecture is represented in Figure 1. A CE that is assigned a shared IPv4 address, or that that is assigned a single addresses and acts as router, MUST have a NAT44 function (IPv4 NAT of [RFC1631]). This NAT44 MUST only use external ports that belong to its assigned port set. It MUST treat external Identifications of Echo requests it sends as though they would be port numbers. and as Identifications of Echo requests it sends across the Domain. It MUST also avoid sending interleaved fragments of several datagrams (Section 4.5.3). Border-relay(s) (neither per-connection nor per-customer states) | 4rd DOMAIN | - IPv6 routing (native or 6rd) v - Enforced ingress filtering +-------------------------------+ | | +---------- | | | ... | | | | +----+ IPv4 Customer site | BR prefix --> | BR | Internet +--------------------+ | +----+ |CE 4rd prefix | | | | | statelessly +----+ | | | | derived from | CE +-+ <-- CE IPv6 prefix | +---------- | the CE +----+ | | | IPv6 prefix | | +------------ +--------------------+ | | | CE-CE tunnels follow | ... | CE-CE IPv6 routes | IPv6 | (mesh or hub-and-spoke) | Internet | | | | | +------------ +-------------------------------+ <== one or several Mapping rules announced to CEs (e.g. in stateless DHCPv6) Figure 1 Despres Expires July 31, 2012 [Page 5] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 4. Protocol Specification 4.1. 4rd Domain parameters CEs and BRs MUST be configured with the following Domain parameters: o Header variant (Header mapping or Encapsulation) o Topology variant (Mesh or Hub&Spoke) o Domain PMTU o Tunnel traffic class (optional) o Domain IPv6 suffix (optional) o Mapping rules, each one comprising: * Rule IPv4 prefix * EA-bits length * Rule IPv6 prefix In a Domain that supports shared-address CEs and has duplicated BRs, each BR MUST also have the following parameter: o BR packet-ID prefix These parameters are REQUIRED to comply with the following: R-1 "Header variant" determines whether Tunnel packets are built according to the Header-mapping variant or the Encapsulation variant (Section 4.2 to Section 4.4). R-2 "Topology variant" determines whether CEs address their Tunnel packets directly to IPv6 addresses of other CEs (Mesh variant), or whether they always address them to BR IPv6 addresses (Hub& spoke variant). R-3 "Domain PMTU" is the IPv6 path MTU that the ISP can guarantee for all its cross-domain paths. In accordance with [RFC2460], it MUST be at least 1280. Despres Expires July 31, 2012 [Page 6] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 R-4 "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. In this case, tunnel traversal is treated in IPv4 as a single-link traversal. Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations, and IPv4 Time to live values progress with the number of traversed IPv6 links. R-5 "Domain IPv6 suffix", which is optional, is only used in particular Domains where CEs are placed in customer sites behind third-party CPEs, and where these CPEs use some address bits to route packets among their physical ports. Its effect is detailed in Section 4.3.1 and Section 4.4.1. A use case where it applies is presented in Section 5.2.2. R-6 "BR datagram-ID prefix" is used to ensure that datagrams that go from CEs that share the same IPv4 address to a common destination via the IPv4 Internet have datagram Identifications that cannot be confused. If the Domain supports shared addresses, all BRs MUST have different values of this parameter, as detailed in Section 4.5.3. (If there is only one BR, or if the Domain supports only non-shared IPv4 addresses, this parameter is not needed, it can be by default a /0 to be ineffective.) R-7 "Rule IPv4 prefix" is used to find, with a longest match, which Mapping rule applies to a 4rd address. All Mapping rules MUST have different Rule IPv4 prefixes. R-8 "EA-bits length" of a Mapping rule specifies the number of bits of 4rd addresses that, if this rule applies, are embedded in IPv6 addresses. A rule that has the length of its Rule IPv4 prefix plus its EA-bits length larger than 32, is one that applies to shared-address CEs. The number of bits beyond 32, is the PSID length of the rule. It, determines its sharing ratio. R-9 "Rule IPv6 prefix" of a Mapping rule is the prefix that, in IPv6 addresses derived from 4rd addresses with this rule, replaces the Rule IPv4 prefix. All Mapping rules MUST have different Rule IPv4 prefixes. R-10 Each Domain MUST have one and only one "Default mapping rule". This rule MUST have Rule IPv4 prefix = 0.0.0/0, EA-bits length = 32. is Rule IPv6 prefix MUST be a /80 whose format is specified in Section 4.4.2. Despres Expires July 31, 2012 [Page 7] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 R-11 Rules other than the Default mapping rule MUST concern CE IPv6 prefixes that can be the same for native IPv6 and for 4rd, i.e. are at most /64s. (For length of the Rule IPv6-prefix plus EA- bits length, plus length of the Domain-IPv6-suffix if there is one MUST NOT exceed 64). R-12 Each CE and each BR MUST be capable to support up to 32 Mapping rules. (Note: this number, which is not critical, is easy to change, should a working-group consensus require another value.) ISPs that need Mapping rules for more than 32 IPv4 prefixes SHOULD split their networks into multiple Domains, with Domain to Domain communication driven by IPv4 addresses. R-13 ISPs that provide their own CPEs to all their customers MAY limit CE functions of these CPEs to those that are needed for parameter values they choose to deploy. (For example, they MAY support only an Encapsulation and Mesh variant, or only a Header-mapping and Hub&spoke variant, as applicable to their deployment choice). 4.2. Headers of Encapsulation and Header-Mapping Variants R-14 Domain-entry nodes MUST discard IPv4 packets they receive with one or several IPv4 options. (They MUST then return the ICMPv4 error message of [RFC0792] that signals such an IPv4-option incompatibility: Type = 12, Code = 0, Pointer = 20). Note: This limitation is made to privilege simplicity, and taking in consideration that IPv4 options, which are very rarely used, are not necessary for normal IPv4 operation. TUNNELED IPv4 PACKET +--------------------+ | IPv4 Header | +--------------------+ | IPv4 Payload | +--------------------+ TUNNEL PACKET Header-mapping variant Encapsulation variant +--------------------+ +--------------------+ | IPv6 Header | 40 OR | IPv6 Header | 40 +--------------------+ +--------------------+ | Fragment Header | 8 | IPv4 Header | 20 +--------------------+ +--------------------+ | IPv4 Payload | | IPv4 Payload | +--------------------+ +--------------------+ Despres Expires July 31, 2012 [Page 8] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 Figure 2 R-15 Domain-entry nodes MUST convert IPv4 packets they receive without any IPv4 option into Tunnel packets. Domain-exit nodes MUST convert back IPv6 packets into IPv4 packets. Headers of Tunnel packets have the two variants shown in (Figure 2): in the Header-mapping variant, the tunnel header comprises an IPv6 header followed by an IPv6 fragment header (total 48 octets); in the Encapsulation variant, it comprises an IPv6 header followed by an IPv4 header (total 60 octets). R-16 Domain-entry nodes MUST discard IPv4 packets received with one or several IPv4 options (and return ICMPv4 error message of [RFC0792] that signals such an IPv4-option incompatibility: Type = 12, Code = 0, Pointer = 20). Note: this limitation is introduced to privilege simplicity, and in view that IPv4 options, very rarely used, are unnecessary for normal IPv4 operation. R-17 In the Header-mapping variant, the IPv6 fragment header is used to convey fields of IPv4 headers that have no equivalents in IPv6 headers but have equivalents in IPv6 fragment headers, namely the More-fragment bit M and Offset. * The IPv6 fragment header MUST also be used to convey the DF bit, an IPv4 field that has no equivalent in IPv6 where the Don't-fragment condition holds by default [RFC2460]. * If the Domain has a configured Tunnel Traffic class, the IPv6 fragment header MUST also be used to convey the original IPv4 TOS so that it can be restored at Domain exit. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.| 0 | IPv4 TOS | IPv4 Identification | +|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 DF Identification field of the IPv6 Fragment header Figure 3 * For this to be possible, it is taken advantage of the fact that the Identification field of an IPv6 fragment headers has 32 bits while 16 bits are enough to contain a copy of that of an IPv4 header. Copies of the IPv4 DF bit and TOS MUST be placed as shown in Figure 3. Despres Expires July 31, 2012 [Page 9] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 +---------------------+------------------------------------+ | IPv6 FIELDS | VALUES SET AT DOMAIN ENTRYS | +---------------------+------------------------------------+ | Version | 6 | | Traffic class | TOS or parameter - see Section 4.6 | | Flow label | 0 | | Payload length | Total length - 12 | | Next header | 44 (Fragment header) | | Hop limit | Time to live | | Source address | See Section 4.4.1 & Section 4.4.2 | | Dest. address | See Section 4.4.1 & Section 4.4.2 | | 2nd next header | Protocol | | Frag. offset | Frag. offset | | M | More fragments (MF) | | IPv4 DF | Don't fragment (DF) | | IPv4 TOS | Type of service (TOS) | | IPv4 Identification | Identification | +---------------------+------------------------------------+ Table 1 +---------------------+-----------------------------------+ | IPv4 FIELDS | VALUES SET AT DOMAIN EXIT | +---------------------+-----------------------------------+ | Version | 4 | | Header length | 5 | | TOS | See Section 4.6 | | Total Length | Payload length + 12 | | DF | IPv4 DF | | MF | M | | Fragment offset | Fragment offset | | Time to live | Hop limit | | Protocol | 2nd Next header | | Header checksum | Computed as per [RFC0791] | | Source address | Bits 80-11 of source address | | Destination address | Bits 80-11 of destination address | +---------------------+-----------------------------------+ Table 2 * Other than that, field values that Domain-entry nodes MUST set in Tunnel-packet headers are straightforward. For reference, they are detailed in Table 1. Those that Domain- exit nodes MUST set in restored IPv4 headers are detailed in Table 2. Despres Expires July 31, 2012 [Page 10] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 R-18 In the Encapsulation variant, Domain-entry nodes MUST add an IPv6 header in front of IPv4 packets they have to forward. Its Next header MUST be set to 4 according to [RFC2003]. Domain- exit nodes MUST decapsulate IPv4 packets. If the Domain has no Tunnel traffic class parameter,they MUST replace TOS values of decapsulated packets by Traffic-class values received in IPv6 headers. 4.3. From CE IPv6 Prefixes to IPv4 Addresses and Port sets 4.3.1. From CE IPv6 Prefix to CE 4rd Prefix R-19 Each CE MUST derive its own 4rd prefix from its delegated IPv6 prefix as detailed in Figure 4. The first step MUST consist in finding the Mapping rule whose IPv6 prefix has the the longest match with the CE delegated prefix. If none is found, the IPv6 prefix is not one of 4rd. Another IPv6 prefix can be tried if the CE has been delegated are several. If still no rule is found, it is a sign that this CE is left out of 4rd service in this Domain. If a rule is found, the CE MUST replace the Rule IPv6 prefix by the Rule IPv4 prefix. It the Domain has a Domain IPv6 suffix, the CE MUST truncate the result by deleting its last k bits, where k is the Domain-IPv6-suffix length. The result is the CE 4rd prefix. +--------------------------------------------+ | CE IPv6 prefix | +--------------------------+-----------------+ : Longest match : : : with a Rule IPv6 prefix : : : || : : : \/ : : +--------------------------+ : | Rule IPv6 prefix | :<-.->: +--------------------------+ : \ || : : Length of the \/ : : Domain IPv6 suffix +-----------------+-----------+ (if there is one) |Rule IPv4 prefix | EA bits | +-----------------+-----------+ : : +-----------------------------+ | CE 4rd prefix | +-----------------------------+ Figure 4 Despres Expires July 31, 2012 [Page 11] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 R-20 If this CE 4rd prefix is longer than a /32, the CE MUST take its bits beyond the first 32 as the CE PSID. Ports of the PSID-specified port set MUST then be derived as specified in Section 4.3.2). If the 4rd prefix is a /32, the CE MUST take the 4rd prefix. If it is shorter than a /32, the CE MUST take it as its IPv4 prefix. +-------------------------------------+ | CE 4rd prefix longer than /32 | +-------------------------------------+ : || : : \/ : :<-------------- 32 ------------>: : +--------------------------------+----+ | IPv4 address |PSID| +--------------------------------+----+ Figure 5 4.3.2. From PSID to Port Set R-21 Each CE that has a PSID as a result of Section 4.3.1 MUST derive ports of its restricted as shown in Figure 6: non-zero value in their first 4 bits, followed by the PSID, and any value in the remaining bits. +-------+ | PSID | 12 - PSID-length +-------+ | : 4 : :<-----'----->: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > 0 | PSID | any value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port in the port set Figure 6 Despres Expires July 31, 2012 [Page 12] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 NOTE: The choice of the 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 (these ports have more value than others); (2) for compatibility RTP/RTCP [RFC4961], port sets need to include pairs of consecutive ports (for this, PSID length MUST be limited to 11, a negligible constraint in practice since a sharing ratio of 2048 is already beyond realistic needs); (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 port bits required to be > 0, excluded ports are 0-4095, i.e. more than the required 0-1023. This is a trade-off in view of other objectives, in particular nibble alignment. 4.4. From IPv4 addresses and Ports to IPv6 Addresses 4.4.1. From 4rd Address to IPv6 Prefix +----------------------------+--------------+ | IPv4 address |Port bits 4-15| +----------------------------+----+---------+ : Longest match : : : || : : : \/ :<-->: PSID length = L(RuleIPv4 prefix) +----------------+-----------+----+ + EA-bits length |Rule IPv4 prefix|IPv4 suffix|PSID| - 32 +----------------+-----------+----+ : : : : +----------------+----------------+ |Rule IPv4 prefix| EA bits | +----------------+----------------+ || \_______ \__ \/ \ \ +--------------------------+-----------+---+ | Rule IPv6 prefix | EA bits | . | +--------------------------+-----------+--\+ : \_Domain IPv6 suffix : : (if applicable) +------------------------------------------+ | IPv6 prefix | +------------------------------------------+ From 4rd address to IPv6 prefix (shared-address case) Figure 7 Despres Expires July 31, 2012 [Page 13] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 R-22 BRs, and CEs in the Mesh variant, MUST derive IPv6 addresses from a 4rd addresses with the following steps (or their functional equivalent): (1) Find the Mapping rule whose Rule IPv4 prefix has the longest match with the IPv4 address. (2) If the Rule IPv4 prefix plus EA-bits length of this rule is 32 + k with a positive k, append to the IPv4 address the PSID found in bits 4 to 4+k of the port field. (3) The port field to be used if a PSID is needed is found in the IPv4-packet payload at a location that depends on whether the address is a source or a destination address, on whether the packet is ICMP or not, and, if it is ICMP whether it is an error message or an echo message. Precise locations in IPv4 payloads are the following: + If the packet Protocol is not ICMP, bits 0-15 for an IPv4 source address, and bits 16-31 for a destination address. + If the packet is an ICMPv4 error message, bits 240-255 for a source address; bits 224-239 for a destination address. + If the packet is an ICMPv4 echo or echo-reply message, the Port field is the ICMPv4 Identification field (bits 32-47). (4) Replace in the result the Rule IPv4 prefix by the Rule IPv6 prefix. (5) If the Domain has a Domain IPv6 suffix (see Section 4.1), and if the rule is not the Default mapping rule, append it to the result to obtain an IPv6 prefix. Steps up to this one are illustrated in Figure 7, (6) Derive from this derived IPv6 prefix an IPv6 address according to Section 4.4.2. R-23 In the Hub&spoke variant, CEs MUST always use the Default- mapping rule to derive IPv6 prefixes of Tunnel-packet destinations. Despres Expires July 31, 2012 [Page 14] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 NOTE: Using Identification fields of ICMP messages as port fields permits to exchange Echo requests and Echo replies between shared- address CEs and and IPv4 hosts having exclusive IPv4 addresses. Echo exchanges between two shared-address CEs remain impossible. This limitation to is inherent to address sharing, independently of its being static or dynamic. Using IPv6 is the obvious way to avoid this limitation. 4.4.2. From IPv6 Prefix to IPv6 Address R-24 An IPv6 prefix derived from a Mapping rule than is not the Default mapping rule is, as specified in Section 4.1, at most a /64. In this case, the IPv6 address MUST be completed with a null padding field up to 64 bits, the V octet (see below), an empty octet, the IPv4 address, and a CNP or null 16-bit field depending on whether the applicable variant is Header mapping or Encapsulation. :<-- IPv6 prefix =< /64 -->: : : : 8 : 8 : 32 : 16 : +---------------------------+---+---+---+--------------+--------+ | CE IPv6 prefix | 0 | V | 0 | IPv4 address |CNP or 0| +---------------------------+/--+---+--|+--------------+--------+ Padding In the Hub&spoke variant, lowest bit replaced by a 1 in the CE to BR direction Figure 8 * The CNP is, in one's complement arithmetic, the opposite of the sum of the 5 first 16-bit words of the IPv6 address. This guarantees that, as far as UDP-like checksums of the transport layer are concerned, Tunnel packets are valid in IPv6. At this time, it applies to UDP, TCP and DCCP. It will also automatically apply to any protocols that may use the same checksums in the future (e.g. a SCTP with a simplified checksum, should it be found useful). * The V octet is a 4rd-specific mark. Its function is to ensure that 4rd does not interfere with the choice of subnet prefixes in CE sites. It can also facilitate maintenance by facilitating distinction between 4rd Tunnel packets and native-IPv6 packets. Within CEs, IPv6 packets can safely be routed to the 4rd function based on a /80 prefix because no internal route for native IPv6 can have a destination prefix that start with this one. For this, the V octet MUST have its "u" and "g" bits of [RFC4291] both set to 1. This is REQUIRED to avoid "u" = 0 (reserved for local-scope Despres Expires July 31, 2012 [Page 15] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 Interface IDs, in which case all other bits have any values), and to avoid "u" = 1 and "g"= 0 ("u" = 1 is reserved for Interface IDs using the EUI-64 format, in which case unicast addresses have "g" = 0). The proposed value of other bits of the octet is 0, giving V = 0x03. As indicated in Section 7, this value needs to be submitted to IANA. * In the Hub&spoke variant, a precaution is needed so that not only off-domain IPv4 addresses are mapped with the Default mapping rule, but also some CE-assigned IPv4 addresses (use case of Section 5.3). For addresses destined to such CEs to be routed differently in the BR-to-CE direction and in the CE-to-BR direction, CEs MUST set bit 79 to 1 (the last one before copied IPv4 addresses). Routes to BRs of the Hub& spoke variant MUST therefore have 80-bit prefixes whose last bit is a 1. R-25 An IPv6 prefix that is derived from a 4rd address with the Default mapping MUST, according to Section 4.1, be a /112 (80 bits of Rule IPv6 prefix plus 32 EA bits). In order to ensure that all Tunnel-packet addressed to BRs are as distinguishable from native IPv6 addresses as those addressed to CEs, the Rule IPv6 prefix of the Default mapping rule MUST have the V octet in bits 64-71. The following octet SHOULD be 0, with its last bit modified as above in the CE to BR direction of the Hub& spoke variant. Other than that, values of bit 71 and of the last last 16 bits are set as above for IPv6 prefixes limited to /64s ( :<------------------IPv6 prefix /112 ----------------->: : : 8 : 8 : 32 : 16 : +-------------------------------+---+---+--------------+--------+ | /64 of the BR IPv6 prefix | V | 0 | IPv4 address |CNP or 0| +-------------------------------+---+--|+--------------+--------+ Padding In the Hub&spoke variant, lowest bit replaced by a 1 in the CE to BR direction Figure 9 Despres Expires July 31, 2012 [Page 16] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 4.5. Fragmentation Considerations 4.5.1. General R-26 If an IPv4 packet enters a CE or BR with a size such that the size of a directly derived Tunnel packet would exceed the Domain PMTU the packet has to be either fragmented or discarded. The Domain-entry node MUST discard it if it has DF = 1 (with an ICMP error message returned to the source). It MUST fragment it otherwise. (The length of each payload fragment MUST be at most the Domain PMTU - k, where k is 48 in the Header-mapping variant, and k is 60 in the Encapsulation variant.) 4.5.2. Ports of Fragments sent to Shared-Address CEs Because ports are available only in first fragments of fragmented datagrams, a BR needs a mechanism to send to the right CEs all datagram fragments addressed to a shared-address CE. For this, a BR could systematically reassemble fragmented IPv4 datagrams before tunneling them, but this consumes large memory space, opens denial-of-service-attack opportunities, and can significantly increase forwarding delays. R-27 BRs SHOULD support an algorithm whereby it can forward IPv4 packets from the Internet on the fly, for example the following algorithm: (1) At BR initialization, if at least one CE mapping rule concerns shared IPV4 addresses (length of Rule IPv4 prefix + EA-bits length > 32), the BR initializes an empty "IPv4-datagram table" whose entries have the following items: - IPv4 source - IPv4 destination - IPv4 identification. - Destination port. (2) When the BR receives an IPv4 packet whose matching Mapping rule is one of shared addresses (length of Rule IPv4 prefix + EA-bits length > 32), the the BR searches the table for an entry whose IPv4 source, IPv4 destination, and IPv4 Identification, are those of the received packet. It then performs actions detailed in Table 3 depending on which conditions hold. Despres Expires July 31, 2012 [Page 17] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 +---------------------------+---+---+---+---+---+---+---+---+ | - CONDITIONS - | | | | | | | | | | First Fragment (offset=0) | Y | Y | Y | Y | N | N | N | N | | Last fragment (MF=0) | Y | Y | N | N | Y | Y | Y | N | | An entry has been found | Y | N | Y | N | Y | N | Y | N | | ------------------------- | | | | | | | | | | - RESULTING ACTIONS - | | | | | | | | | | Create a new entry | - | - | - | X | - | - | - | - | | Use the port of the entry | - | - | - | - | X | - | - | - | | Update port of the entry | - | - | X | - | - | - | X | - | | Delete the entry | X | - | - | - | X | - | - | - | | Forward the packet | X | X | X | X | X | - | X | - | +---------------------------+---+---+---+---+---+---+---+---+ Table 3 (3) BRs SHOULD operate garbage collection set up for table entries that remain unchanged for longer than a fragmented-datagram reception may take. This value, which is not critical, MAY be set to 15 seconds (ref [RFC0791]. R-28 CEs that are able to route public IPv4 addresses in their sites when assigned IPv4 prefixes (as opposed to always having NAT44s at site entrances), MUST have the same behavior as that described above for BRs. 4.5.3. Datagram Identifications from Shared-Address CEs When datagrams go from different shared-address CEs to a common off- domain destination, there is no guarantee that packet Identification values set by sources are different. Because datagram reassembly in the destination is based only on source address and packet Identification, fragments of different sources can be confused. Probability of this happening may in theory be very low but, in order to avoid creating new attack opportunities, a safe solution is needed. R-29 BRs SHOULD support an algorithm that ensures that datagram Identifications from shared address CEs never create reassembly ambiguity in common destinations, for example the following one: (1) At BR initialization, if at least one CE mapping rule concerns shared IPV4 addresses (i.e. if the sum of its Rule-IPv4-prefix length and EA-bits length exceeds 32), the BR initializes an empty table and a "Datagram-ID generator" whose characteristics are specified below. Entries of the table have the following items: Despres Expires July 31, 2012 [Page 18] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 - IPv6 prefix - CE packet ID - BR datagram ID (2) When a BR has an IPv4 packet to forward, it determines whether it comes from a shared-address CE (length of Rule IPv4 prefix + EA-bits length > 32). If yes, the BR searches the table for an entry whose IPv6 prefix is equal to the source IPv6 prefix, and takes actions detailed in Table 4. +---------------------------+---+---+---+---+---+---+---+---+---+---+ | - CONDITIONS - | | | | | | | | | | | | First Fragment (offset=0) | Y | Y | Y | Y | N | N | N | N | N | N | | Last fragment (MF=0) | Y | Y | N | N | Y | Y | Y | N | N | N | | An entry is found | Y | N | Y | N | Y | Y | N | Y | Y | N | | CE pkt ID = Entry pkt ID | ? | | ? | | Y | N | | Y | N | | | ------------------------- | | | | | | | | | | | | - RESULTING ACTIONS - | | | | | | | | | | | | Generate a new BR pkt ID | X | X | X | X | - | - | - | - | - | - | | Create a new entry | - | - | - | X | - | - | - | - | - | - | | Use BR pkt ID of entry | - | - | - | - | X | - | - | X | - | - | | Update pkt IDs of entry | - | - | X | - | - | - | - | - | - | - | | Delete the entry | X | - | - | - | X | X | - | - | X | - | | Forward the packet | X | X | X | X | X | - | - | - | - | - | +---------------------------+---+---+---+---+---+---+---+---+---+---+ Table 4 (3) The "Datagram-ID generator" provides Identification values that, for each possible CE IPv4 address, must comply with what applies to hosts in [RFC0791] ("the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet"). Since each BR has its own Datagram-ID generator, BRs should generate Identifications belonging to disjoint sets. This is the reason for having as BR parameter a BR datagram-ID prefix (Section 4.1). Having this parameter, each BR generates Identifications that start with this prefix. R-30 CEs that are able to route public IPv4 addresses in their sites when assigned IPv4 prefixes (as opposed to always having NAT44s at site entrances), MUST have the same behavior as that described above for BRs. Despres Expires July 31, 2012 [Page 19] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 4.6. TOS and Traffic-Class Considerations As specified in [RFC3168], the TOS of IPv4 headers and the Traffic class of IPv6 headers must have the same meanings in ECN-capable networks (networks supporting Explicit Congestion Notification). Their first 6 bits are a Differentiated Services CodePoint (DSCP). Their two last bits are an Explicit Congestion Notification (ECN). [RFC6040] details how the ECN field MAY evolve if a packet traverses a router that signals congestion condition before packets are dropped. R-31 4rd domains MUST support the ECN normal mode of [RFC6040] by default. For this, BRs and CEs MUST copy the IPv4 TOS into the IPv6 Traffic class at Domain entry, and copy back the IPv6 Traffic class, which may have a changed ECN, into the IPv4 TOS at Domain exit. R-32 A Domain where the ECN normal mode of [RFC6040] is not supported MUST have its Domain-traffic-class parameter set. In this case, BRs and CE's MUST take this parameter as IPv6 Traffic class of Tunnel packets, and MUST keep at Domain exit TOS values that were received at Domain entry. (In the Header- mapping variant, the TOS value is restored as detailed in Section 4.2.) 4.7. Tunnel-Generated ICMPv6 Error Messages R-33 If an Tunnel packet is discarded on its way across a 4rd domain, possibly because of an unreachable destination, 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 of the packet loss, the ICMPv6 packet MUST be converted to an ICMP packet returned to the IPv4 source. Type, or Type and Code, of the ICMPv4 packet MUST be obtained as specified for error messages in Section 5.2 of [RFC6145]. The ICMP checksum MUST be updated accordingly. R-34 The IPv4 source address to be used in these ICMP packets MUST be 192.70.192.254 (to be confirmed by IANA - see Section 7). (Note: this value taken in the /24 range proposed in [I-D.xli-behave-icmp-address] for a similar purpose.) Despres Expires July 31, 2012 [Page 20] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 4.8. Provisioning 4rd Parameters to CEs Parameter listed in Section 4.1 can be announced to CE's in DHCPv6 (ref. [RFC2131]). At this stage, option formats remain to be defined, one for Domain parameters other than Mapping rules, say OPTION-4RD, and one for mapping rules, say OPTION_4RD_RULE. 5. Use-Case Examples 5.1. How to choose Mapping Rules As far as mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the Default mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it comprising the BR /64 prefix, the V octet, a null octet, and the IPv4 address. This model has however the following limitations: (1) shared IPv4 addresses are not supported; (2) IPv6 prefixes used for 4rd are too long to be used also for native IPv6 addresses; (3) if the IPv4 address space of the ISP is split with many disjoint IPv4 prefixes, the IPv6 routing plan must be as complex as an IPv4 routing plan based on these prefixes. With more mapping rules, the same CE prefixes can be used for 4rd and for native IPv6. Also, IPv6 prefixes that have been assigned without previous relationship with IPv4 prefixes can be used for to offer 4rd service. How to choose CE mapping rules for a particular deployment needs not being standardized, but some hints are possible. The following is a pragmatic approach that can be used for various deployment scenarios: (1) Select a "Common IPv6 prefix" that will appear at the beginning of all 4rd CE IPv6 prefixes. (2) Choose all IPv4 prefixes to be used for 4rd. For each one, choose its applicable sharing ratio. Choose the length of CE IPv6 prefixes to be used (in the simplest scenarios, the same for all Mapping rules). (3) Derive from these data, and for each rule, the length of a "Rule code". This code is that which is appended to the Common prefix to get the Rule IPv6 prefix (Figure 10). For Mapping rule i, its length is L(Rule code(i) = L(CE IPv6 prefix(i)) - L(Common_IPv6_prefix) - (32 - L(Rule IPv4 prefix(i))) - L(PSID), where L(PSID) = k is the sharing ratio is 2^k: Despres Expires July 31, 2012 [Page 21] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 :<--------------------- L(CE IPv6 prefix(i)) --------------------->: : : : 32 - L(Rule IPv4 prefix(i)) L(PSID(i)) : : \ | : :<-- L(Common IPv6 prefix) ->: :<---------'--------><--'-->: : : : : : : || : : : : \/ : : : :<------->: : : L(Rule code(i) : : : : : +----------------------------+---------+ : | Common IPv6 prefix |Rule code| : | | (i) | || : +----------------------------+---------+ \/ : :<------ L(Rule IPv6 prefix(i)) ------>:<----- L(EA bits(i)) ----->: Figure 10 (4) For each rule successively, take as Rule code the prefix which has the obtained length, which does not overlap with previously chosen Rule codes, and which, to make a systematic choice, has the lowest value if interpreted as fractional part of a binary number. (For example with successive lengths 4, 3 , 5, and 2, this gives, in binary notation, 0000, 001, 00010, and 01) For textual representation of CE mapping rules in the next sections, we will use {Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix}. Example: {198.16.0.0/14, 22, 2001:db8:4000::/34}. 5.2. Adding Shared IPv4 Addresses to an IPv6 Network 5.2.1. IPv6 network of the ISP We consider an ISP that offers IPv6-only service to up to 2^20 customers. Each customer is delegated a /56, starting with common prefix 2001:db8:0::/36. It wants to add public IPv4 service to customers that are 4rd-capable, but does not have 2^20 IPv4 addresses. IPv4 prefixes it can use are only 192.8.0.0/15, 192.4.0.0/16, 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor aggregetable). This gives 2^(32-15) + 3*2^(32-16) IPv4 addresses, i.e. 2^18 + 2^16). For the 2^20 customers to have the same sharing ratio, the number of IPv4 addresses to be shared must be a power of 2. The ISP can therefore renounce to use one /16, say the last one. (Whether it could be motivated to return it to its Internet Registry is off-scope for this document.) The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2. Despres Expires July 31, 2012 [Page 22] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 Applying principles of Section 5.1 with L(Common IPv6 prefix) = 36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all rules, Rule codes and Rule IPv6 prefixes are: +--------------+--------+-----------+-----------+-------------------+ | CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 | | prefix | bits | length | (binary) | prefix | | | length | | | | +--------------+--------+-----------+-----------+-------------------+ | 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 | | 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 | | 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 | +--------------+--------+-----------+-----------+-------------------+ Table 5 Mapping rules are then the following: {192.8.0.0/15, 19, 2001:0db8:0000::/37} {192.4.0.0/16, 18, 2001:0db8:0800::/38} {192.2.0.0/16, 18, 2001:0db8:0c00::/38} {0.0.0.0/0, 32, 2001:0db8:0000:0001:3000::/80} The CE of whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56, derives its IPv4 address and its port set as follows (Section 4.3): IPv6 prefix : 2001:0db8:0bbb:bb00::/56 Rule IPv6 prefix(i) : 2001:0db8:0800::/38 (longest match) Rule IPv4 prefix(i) : 192.4.0.0/16 EA-bits length(i) : 18 PSID length(i) : 16 + 18 - 32 = 2 EA bits : 11 1011 1011 1011 1011 Rule IPv4 prefix(i) : 1100 0000 0000 0100 IPv4 address : 1100 0000 0000 0100 1110 1110 1110 1110 PSID : 10 IPv4 address : 192.4.238.238 (1110 1110 = 238) Ports : yyyy 10xx xxxx xxxx with y..y > 0, and x...x any value Despres Expires July 31, 2012 [Page 23] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 In the Mesh variant, a packet sent to port IPv4 address 192.4.238.238 and port 7777 is tunneled to IPv6 address obtained as follows (Section 4.4.1): IPv4 address : 192.4.238.238 Port field : 6666 Rule IPv4 prefix (i) : 192.4.0.0/16 (longest match) EA-bits length (i) : 18 Rule IPv6 prefix (i) : 2001:0db8:0800::/38 IPv4 address : 1100 0000 0000 0100 1110 1110 1110 1110 EA bits Rule IPv4 prefix (i) : 1100 0000 0000 0100 IPv4 suffix : 1110 1110 1110 1110 PSID length (i) : 19 - 17 = 2 Port field : 0001 1110 0110 0001 (7777) PSID : 11 EA bits : 1110 1110 1110 1110 11 : 11 1011 1011 1011 1011 Derived IPv6 prefix : 2001:0db8:0bbb:bb00::/56 IPv6 address : 2001:0db8:0bbb:bb00:3000:192.4.238.238:yyyy with yyyy = CNP in the Header-mapping variant = 0 in the Encapsulation variant 5.2.2. IPv6 Network of a Third-Party Provider We now consider an ISP that has the same need as in the previous section except that, instead of using its own IPv6 infrastructure, it uses that of a third party whose CPEs are imposed in customer sites. These CPEs use a suffix = 0xF to route IPv6 packets to physical ports to which CEs are attached. It is supposed to have the same IPv4 prefixes (192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16), and to use the same Common IPv6 prefix (2001:db8:0::/36). By adding a Domain IPv6 suffix = 0xF in parameters sent to CE's, the same Mapping rules can be used, i.er. : {192.8.0.0/15, 19, 2001:0db8:0000::/37} {192.4.0.0/16, 18, 2001:0db8:0800::/38} {192.2.0.0/16, 18, 2001:0db8:0c00::/38} {0.0.0.0/0, 32, 2001:0db8:0000:0001:3000::/80} Despres Expires July 31, 2012 [Page 24] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 CEs derive their own IPv4 addresses and port sets as in the previous section, except that they ignore the Domain IPv6 suffix at the end of their delegated IPv6 prefixes. The IPv6 address derived from IPv4 address 192.4.238.238 and port 7777 is derived as in the previous section except that, after the step that obtains EA bits = 11 1011 1011 1011 1011, we now have: Derived IPv6 prefix : 2001:0db8:0bbb:bbf0::/60 (suffix added) IPv6 address : 2001:0db8:0bbb:bbf0:3000:xxxx:xxxx:yyyy 5.3. Replacing Dual-stack Routing by IPv6-only Routing In this use case, we consider an ISP that offers IPv4 service with public addresses individually assigned to its customers. It also offers IPv6 service, having deployed for this dual-stack routing. Because it provides its own CPEs to customers, it can upgrade all its CPEs to support 4rd, at least for its chosen variants. It wishes to take advantage of this capability to replace dual-stack routing by IPv6-only routing without changing any IPv4 address or IPv6 prefix. For this, the ISP can use the single-rule model described at the beginning of Section 5.1. If the prefix routed to BRs is chosen to start with 2001:db8:0:1::/64, this rule is: {0.0.0.0/0, 32, 2001:db8:0:1:3000::/80} All what is needed in the network before disabling IPv4 routing is the following: o In all routers, where there is an IPv4 route toward x.x.x.x/n, add a parallel route toward 2001:db8:0:1:3000:x.x.x.x::/(80+n) o In router where IPv4 address x.x.x.x was assigned to a CPE, now delegate IPv6 prefix 2001:db8:0:1:3000:x.x.x.x::/112. NOTE: In parallel with this deployment, or after it, shared IPv4 addresses can be assigned to IPv6 customers. It is sufficient that IPv4 prefixes used for this be different from those used for exclusive-address assignments. Under this constraint, Mapping rules can be set up according to the same principles as those of Section 5.2. Despres Expires July 31, 2012 [Page 25] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 5.4. Adding IPv6 and 4rd Service to a Net-10 network In this use case, we consider an ISP that, possibly because some of its network devices are not yet IPv6 capable, has only deployed IPv4 and that, because it did not have enough IPv4 addresses did it with private IPv4 addresses of [RFC1918], say 10.x.x.x to support up to 2^24 customers (a so called Net-10 network). It wishes to add IPv6 service without delay to this network, using for this 6rd [RFC5969], and 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 supposed to be 2001:db8::/32, and the public IPv4 prefix to be used for shared addresses is supposed to be 192.16.0.0/16 (0xc610). The resulting sharing ratio is 2^24 / 2^(32-16) = 256, giving a PSID length of 8. The ISP installs or several BRs, at the its border to the public IPv4 Internet, to support both 6rd and 4rd BR functions (4rd function on top of 6rd function). The BR prefix /64 is supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e. 2001:db8:0:100:/64). In accordance with [RFC5969], 6rd BRs are configured with the following parameters IPv4MaskLen = 8, 6rdPrefix = 2001:db8::/32; 6rdBRIPv4Address = 192.168.0.1 (0xC0A80001). 4rd Mapping rules are then the following: {192.16.0.0/16, 24, 2001:db8:0:0:3000::/80} {0.0.0.0/, 32, 2001:db8:0:100:3000:/80,} Once this is done, any customer device that supports 4rd can use its assigned IPv4 address and port set of 240 ports.It can thus avoid cascading its NAT44 with the NAT44 carrier-grade NAT44 of the ISP. Its site can get back the port-forwarding function of its NAT44, which is lost in net-10 networks. Public-address IPv4 packets have their 4rd headers (48 or 60 octets depending on which 4rd Header variant is used) preceded by the Net-10 IPv4 header (20 octets) Despres Expires July 31, 2012 [Page 26] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 6. Security Considerations Spoofing attacks R-35 Domain-exit nodes MUST check consistency of IPv6 source address with the 4rd source addresses, and if the check fails MUST silently discard the packet. This is needed because IPv6 ingress filtering only guarantees that CE-provided source addresses do belong to the right CEs (ref. [RFC3704]). It does not guarantee that the Tunnel packets are built in compliance with rules of the present specification. The check can be performed in two steps. First, the Domain-exit node derives an IPv6 prefix from the source 4rd address according to Section 4.4.1. It then verifies that this prefix is present at the beginning of the IPv6 source address. With this precaution, and provided IPv6 ingress filtering is effective in the Domain, no opportunity for spoofing attacks in IPv4 is introduced by 4rd. Routing-loop attacks Routing-loop attacks that may exist in some automatic-tunneling scenarios are documented in [RFC6324]. No opportunity for routing-loop attacks introduced by 4rd has been identified. Fragmentation-related attacks As discussed in Section 4.5, BRs of Domains that assign shared IPv4 addresses to CEs maintain dynamic tables for fragmented datagrams that go from the IPv4 Internet to these CEs and that go from these CEs to the IPv4 Internet. * In the CE to Internet direction, this does not open a vulnerability to DOS-attacks because the table has at most one entry per CE. * In the Internet to CE direction, this opens a vulnerability any remote host can send a large number of first datagram fragments without sending any following fragment, thus occupying many table entries. This vulnerability has no effect on non- fragmented datagrams but is unavoidable in any network that shares IPv4 addresses between customers, be its statically or dynamically. The obvious way to eliminate this vulnerability is to use IPv6. Despres Expires July 31, 2012 [Page 27] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 7. IANA Considerations IANA is requested to allocate the following: o An IPv6 Interface-ID type reserved for 4rd (the V octet of Section 4.4.2). Its proposed value is 0x03. A registry for Interface-ID types that have neither local scope nor Modified EUI-64 format of [RFC4291]) could be created on this occasion. It would be available to serve other needs that may exist in the future. o A reserved IPv4 address to be used as source of ICMPv4 messages due to ICMPv6 error messages. Its proposed value is 192.70.192.254 (Section 4.7). o Two DHCPv6 option codes, to be defined, for the OPTION_4RD and OPTION_4RD_RULE options of Section 4.8. 8. Relationship with Previous Works The present specification has been influenced by many previous IETF drafts, in particular those accessible at http://tools.ietf.org/html/draft-xxxx where xxxx are the following (in order of their first versions): o xli-behave-ivi (2008-07-06) o despres-sam-scenarios (2008-09-28) o boucadair-port-range (2008-10-23) o ymbk-aplusp (2008-10-27) o xli-behave-divi (2009-10-19) o thaler-port-restricted-ip-issues (2010-02-28) o cui-softwire-host-4over6 (2010-05-05) o xli-behave-divi-pd (2011-07-02) o dec-stateless-4v6 (2011-03-05) o matsushima-v6ops-transition-experience (2011-03-07) o despres-intarea-4rd (2011-03-07) Despres Expires July 31, 2012 [Page 28] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 o deng-aplusp-experiment-results (2011-03-08) o murakami-softwire-4rd (2011-07-04) o operators-softwire-stateless-4v6-motivation (2011-05-05) o murakami-softwire-4v6-translation (2011-07-04) o despres-softwire-4rd-addmapping (2011-08-19) o chen-softwire-4v6-add-format (2011-10-2) o boucadair-softwire-stateless-requirements (2011-09-08) o mawatari-softwire-464xlat (2011-10-16) o mdt-softwire-mapping-address-and-port (2011-11-25) 9. Acknowledgements This specification has benefited over several years from independent proposals, questions, comments, constructive suggestions, and useful criticisms, from numerous IETF contributors. The author would like to thank all of them, but more particularly, in first name alphabetical order, Brian Carpenter, Behcet Sarikay,a Congxiao Bao, Dan Wing, Francis Dupont, Gabor, Bajko, Gang Chen, Hui Deng, Jacni Qin, Jan Zorz, Jaro Arkko, Laurent Toutain, Leaf Yeh, Mark Townsley, Maoke Chen, Marcello Bagnulo, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, Teemu Savolainen, Tetsuya Murakami, Tomasz Mrugalski, Tina Tsou, Tomasz Mrugalski, Washam Fan, Wojciech Dec, Xiaohong Deng, Xing Li, Yiu Lee. 10. References 10.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. Despres Expires July 31, 2012 [Page 29] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 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. [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. [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.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.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. [RFC1631] Egevang, K. and P. Francis, "The IP Network Address Despres Expires July 31, 2012 [Page 30] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 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. [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 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. Despres Expires July 31, 2012 [Page 31] Internet-Draft IPv4 Residual Deployment (4rd-U) January 2012 Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Email: despres.remi@laposte.net Despres Expires July 31, 2012 [Page 32]