Internet Engineering Task Force R. Despres, Ed. Internet-Draft RD-IPtech Intended status: Standards Track J. Qin Expires: March 25, 2012 ZTE S. Perreault Viagenie X. Deng France Telecom September 22, 2011 Stateless Address Mapping for IPv4 Residual Deployment (4rd) draft-despres-softwire-4rd-addmapping-01 Abstract This document specifies a mechanism, the 4rd address mapping, for service providers to offer residual deployment of the IPv4 service across IPv6-only domains. Ease of operation and scalability are due to this address mapping being stateless (no per customer states). IPv4 address sharing is based on exclusive port sets assigned to customers, these sets being algorithmically derived from bits used as port-set identifiers. Features include support of shared IPv4 addresses, same routes for IPv4 as for IPv6, and compatibility with both provider aggregatable and provider-independent IPv4 prefixes. The whole 4rd address mapping or part of it can be used combined with various tunneling and double-translation methods. It can also be used either alone or in parallel with stateful mechanisms used for their flexibility where necessary. 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 March 25, 2012. Copyright Notice Despres, et al. Expires March 25, 2012 [Page 1] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 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 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. Architectural model and design objectives . . . . . . . . . . 5 5. 4rd Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 9 6. Mapping steps from CE IPv6 prefix to CE IPv4 address space . . 10 6.1. From CE IPv6 prefix to Generalized IPv4 prefix . . . . . . 11 6.2. From Generalized IPv4 prefix to IPv4 prefix or IPv4 address or IPv4 Address + Port-set ID . . . . . . . . . . 12 6.3. From Port-set ID to Port set . . . . . . . . . . . . . . . 13 7. Mapping from IPv4 address or address plus port to CE IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. From IPv4 Address or Address + Port to Rule IPv4 prefix + Max CE index . . . . . . . . . . . . . . . . . . 15 7.2. From Rule IPv4 prefix + Max CE index to CE IPv6 address . 16 8. Mapping from IPv4 source address to BR IPv6 Address . . . . . 17 9. Example of 4rd Domain with two Rule BR addresses and three Rule IPv4 prefixes . . . . . . . . . . . . . . . . . . . . . . 18 10. Security considerations . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Despres, et al. Expires March 25, 2012 [Page 2] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 1. Introduction During the long transition period from IPv4-only to IPv6-only, some Internet Service Providers (ISPs) will prefer to operate their networks with IPv6-only routing. They will however have to maintain residual IPv4 connectivities across these networks. Some customers will still need exclusive IPv4 addresses, and others will accept shared IPv4 addresses. This document specifies a mechanism, the 4rd address mapping, whereby ISPs can statelessly derive IPv4 address spaces they assign to customers from their IPv6 delegated prefixes These IPv4 address spaces may consist of exclusive addresses or exclusive port sets of shared addresses. This specification can be used in association with a variety of tunneling or double-translation methods specified in other documents. As the chosen acronym suggest, 4rd can be viewed as the reverse of 6rd [RFC5969]: while 6rd statelessly derives IPv6 prefixes from preassigned IPv4 addresses, 4rd derives IPv4 prefixes from preassigned IPv6 prefixes. In addition, 4rd deals with public-IPv4 address sharing among customers. Motivation for stateful solutions, which include simplicity and ease of operation where more optimized address sharing ratios are not necessary, are documented in [I-D.ietf-softwire-stateless-4v6-motivation] (sharing ratio = number of CEs supported per public IPv4 address). Precautions are taken so that 4rd can coexist with stateful solutions where needed for more sharing-ratio optimization. 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, et al. Expires March 25, 2012 [Page 3] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 3. Terminology ISP: Internet-Service Provider. In this document, the offered service can be DSL, fiber-optics, cable, or wireless. The ISP can also be a private-network operator. 4rd domain (Domain if context permits): An ISP IPv6 network across which a residual IPv4 service is offered using the 4rd address mapping, based on a common set of statelessly advertizable mapping rules. 4rd CE (CE if context permits): 4rd-capable "customer-edge" node. It can be a home gateway, a provider-edge router, a host including a NAT44 or, more generally, any 4rd capable node on the customer side of a 4rd Domain. 4rd BR (BR if context permits): A 4rd capable "border router". At the border between a 4rd Domain and the IPv4 Internet. Stateless: In this document, stateless means with neither per transport-connection state nor per per-CE state (no on-demand assignments of IPv4 address space). BRs don't need per-CE states to forward packets that exit or enter the Domain. CEs don't need states about other CEs for direct CE-CE traffic. An IPv4 address space: A set of one or several exclusive IPv4 addresses, or, in case of address sharing, an IPv4 address with an exclusive port set to be used with it. CE IPv6 prefix: An IPv6 prefix delegated to a CE for normal IPv6 operation, e.g. according to [RFC3769]. With the 4rd address mapping, this prefix is the only CE-specific parameter needed for CEs to know which IPv4 addresses, exclusive or shared, are assigned to them. CEs that have larger IPv6 address spaces than others, i.e. have shorter IPv6 prefixes, also have larger IPv4 address spaces, i.e. have more IPv4 addresses or, in case of shared addresses, larger exclusive port sets). CE IPv6 address: One of the possible IPv6 addresses used to reach the 4rd function of a CE node. It starts with the CE IPv6 prefix and has the Well-known 4rd Interface ID in its last 64 bits. Despres, et al. Expires March 25, 2012 [Page 4] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 Port-set identifier (PSID): An identifier from which an exclusive port set is algorithmically derived. Generalized IPv4 prefix: An IPv4 prefix, an IPv4 address, or an IPv4 address plus a Port-set ID. Each one defines an IPv4 address space. Mapping rule (Rule if context permits): A set of parameters whereby: (1) a CE generalized IPv4 prefix is derived from a CE IPv6 prefix; (2) a CE IPv6 address is derived from an IPv4 address plus a port (or from an IPv4 address alone in case of a port-less IPv4 payload). A 4rd domain has one or more Mapping rules. Rule IPv6 prefix: An IPv6 prefix that appears in a Mapping rule. Rule IPv4 prefix: An IPv4 prefix that appears in a Mapping rule. Rule BR IPv6 address: The IPv6 address of a BR, or of several identical BRs. Rules having different may have the same Rule BR address. CE index: In a CE IPv6 prefix, bits that follow the Rule IPv6 prefix that it MUST contain. 4rd Interface ID: A well-known Interface ID (to be assigned by IANA). Having it, 4rd packets are distinguishable form any other IPv6 packets whose destination addresses start with CE IPv6 prefixes. 4. Architectural model and design objectives A 4rd domain is an ISP network in which all CEs use a common set of address mapping rules. Each rule comprises a Rule IPv6 prefix, Rule IPv4 prefix, BR IPv6 address> mappings), and in which the right exit can be picked by CE through the third parameter in chosen rule when deriving it IPv4 address space. in which: 1. IPv6 Routing is supported. 2. Each CE is delegated an IPv6 prefix, with a routing plan independent from IPv4. 3. Residual IPv4 service has to be offered to CEs, with some or all of the following constraints: Despres, et al. Expires March 25, 2012 [Page 5] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 A. Stateless operation. In addition to their delegated IPv6 prefixes, CEs need only to know the common set of Mapping Rules of the Domain. These Rules can be statelessly advertised to CEs (Section 5) B. Support of IPv4 address sharing. C. Ingress filtering compatibility. Several BRs having different incoming IPv4 ISP prefixes from the Internet must be supported. An IPv4 packet sent by a CE to the IPv4 Internet MUST exit the Domain via a BR having a reverse route to this CE [RFC3704]. D. Differentiated IPv4 sharing ratios. (It MUST be possible to assign IPv4 address spaces having different sizes to different CEs) E. Direct CE-CE routes. (CE-CE routes MUST be the same in IPv4 as in IPv6). F. Asymmetric routing compatibility. (An IPv4 packet sent to the Internet via a BR MUST have its response acceptable via any other BR having the same parameters). Figure 1 illustrates architectural aspects of 4rd domains. Restricted port sets, where assigned to CEs, MUST satisfy the following constraints: 1. Fairness. At least well-known ports 0-1023, which have more value than others, MUST NOT be assigned to any restricted-port- set CE. 2. Good-enough exhaustiveness. Ports that cannot be assigned to any CE due to the assignment algorithm MUST be in small enough proportion. (1/16, as proposed below, seems generally acceptable). 3. RTP/RTCP compatibility. (Port set SHOULD contain complete odd- even port pairs.) Since ports are used as extension mechanism of IPv4 addresses, protocols that have no ports are excluded from the solution. Note that ICMP error messages that concern packets having ports in their headers are not excluded: they contain copies of discarded-packet headers. ICMP echo-request packets have no ports, but have in IPv4 16-bit Identifier fields. For CEs that have shared IPv4 addresses to be able to ping remote IPv4 hosts that have exclusive IPv4 addresses, Despres, et al. Expires March 25, 2012 [Page 6] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 CEs and BRs MUST process Identifier fields as though they would be CE ports, both in Echo requests from CEs and in Echo responses to CEs. (This does not permit IPv4 Pings between two shared-address CEs, but this is inherent to IPv4 address sharing. IPv6 Pings should be used instead.) NOTE 1: An additional constraint for Port sets, the so-called UPnP friendliness, has been considered in view of the wide deployment of UPnP 1.0 control points in some operator's networks, and in view of the known difficulty of extensive host upgrades. Its purpose is to mitigate, in some cases, and to some extent, a weakness of early UPnP implementations (version 1.0). If, despite the additional complexity needed to support it, and despite its partially unpredictable effect on deployed devices, it would have to be reintroduced after a Working Group consensus, a possible design to support it is documented in version -00 of this I-D. Despres, et al. Expires March 25, 2012 [Page 7] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 1 or more identical BRs Customer per IPv4 1 or more sites CEs 4rd Domain provider IPv4 providers | | | | | V V V V V +----------------------+ | IPv6 routing | +-------------------- -------------+ | | | | | +'-----'+ Derived +'-'+ | | IPv4 | |<= CE IPv6 +.-----.+ <= One or more add space +.-.+ prefix | ... | Domain | | +'-----'+ IPv4 prefixes -------------+ | | | | +.-----.+ | | | ... | | +-------------------- | | IPv4 Internet ... | | +-------------------- -------------+ | | | | | +'-----'+ Derived +'-'+ | | IPv4 | |<= CE IPv6 +.-----.+ <= One or more add space +.-.+ prefix | ... | Domain | | +'-----'+ IPv4 prefixes -------------+ | | | ^ | +.-----.+ | | | | | | | +-------------------- | +----------------------+ | 1 or more statelessly advertised mapping rules Figure 1: 4rd Domain Model NOTE 2: A particular use case has been identified, the so-called "CPE-cascade" case. In it, the ISP that offers residual IPv4 service does it across the IPv6-only service of another ISP, and this ISP provides its own customer-premise equipments (CPEs). Some IPv6- address bits are used within these CPEs for internal routing. For this use case, "suffix" option in CPE IPv6 addresses has been proposed. It implies that the length of CE IPv6 prefixes be a Rule the same Mapping rule parameter. Because this conflicts with differentiation of sharing ratios based on different IPv6 prefix lengths, and because a specific option for this use case can be documented in a separate document, it has not been covered in this I-D. Despres, et al. Expires March 25, 2012 [Page 8] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 5. 4rd Mapping Rules A 4rd Domain has one or several Mapping rules, each one comprising the following items: o A Rule IPv6 prefix o A Rule IPv4 prefix o A Rule BR IPv6 address Rules are considered to be indexed by Rule IPv6 prefix when a CE looks for the matching rule with which it derives its IPv4 generalized prefix from its CE IPv6 prefix (see Section 6). On the other hand, Rules are considered to be indexed by Rule IPv4 prefix when a CE looks for the matching rule with which it derives a CE IPv6 address from an IPv4 destination (Section 7.1), or derives a BR IPv6 address from an IPv4 source (Section 7.2). For anti-spoofing protection, BRs and CEs MUST verify that the CE IPv6 source address of a packet received from the Domain would be the IPv6 destination addresses if the IPv4 source address, including the port if available, would be taken as destination. each IPv4 packet received by a BR or a CE after Domain traversal, the node A failure of this check can be the result of a tentative spoofing attack. The packet MUST be silently discarded (principle similar to that of Reverse Path Forwarding in [RFC3704]). If several BRs have the same IPv4 routes from the Internet, they are configured with the same BR address. This address is routed in the Domain as an anycast address so that these BRs can share the traffic load. Note however that, for IPv4 address sharing, IPv4 datagram reassembly may have to be supported by BRs (ports are used as address extension tool, and fragmented datagrams have ports only in their first fragments). Consequently, this load sharing between BRs MUST be done with anycast routes that are stable most of the time. Route changes may lead to a few losses of fragmented IPv4 datagrams, but this remains acceptable provided they are rare enough. CEs may receive Domain mapping rules in a variety of classic provisioning methods: Stateless DHCPv6, [RFC3736], the Broadband Forum's "TR-69", a DNS record, etc. Note that, if several rules have a common BR address, as in the example of Section 9, format optimization is possible. How to do it is however in scope of these provisioning methods. In order to send IPv4 packets to other CEs via the same routes as Despres, et al. Expires March 25, 2012 [Page 9] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 IPv6 packets, each CE MUST know all Mapping rules of the Domain. Ability to support up to 1000 rules, although unnecessary in typical use cases, has been reported as useful for some exceptional configurations. Since this is easily feasible with common memory sizes, it is REQUIRED. 6. Mapping steps from CE IPv6 prefix to CE IPv4 address space The following subsections detail steps whereby the IPv4 address space assigned to a CE is derived from its CE IPv6 prefix. The example below illustrates such a derivation with an example in which there is one Mapping rule. Its CE IPv6 prefix, Rule IPv6 prefix, and Rule IPv4 prefix, are supposed to be respectively 2001:db4:4444:4000::/52, 2001:db0::/28, and 192.32../12 (i.e. 0x602). For clarity, lengths of Rule prefixes and CE prefix are multiple of 4 bits, but this is not an obligation. Item Hexadecimal Num. of bits - CE IPv6 prefix : 20010DB444444 52 - Rule IPv6 prefix matching : 20010DB 28 - Resulting CE index : 444444 24 - Rule IPv4 prefix paired : 602 12 - Resulting Derived IPv4 address : 602444444 - Resulting CE's IPv4 address : 60244444 32 - Resulting Port-set ID : 4 4 - Resulting exclusive port-set : y4xx (with 16 y > 0 and any xx) Despres, et al. Expires March 25, 2012 [Page 10] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 6.1. From CE IPv6 prefix to Generalized IPv4 prefix <----------------- at most 64 bits ------------------> +-----------------------------------------------------+ | CE IPv6 prefix | || +-----------------------------------------------------+ || : : || +--------------------------------+--------------------+ || | Rule IPv6 prefix | CE index | || +--------------------------------+--------------------+ || : : || +------------------+--------------------+ || | Rule IPv4 prefix | CE index | || +------------------+--------------------+ || : : || +---------------------------------------+ || | CE Generalized IPv4 prefix | \/ +---------------------------------------+ <----------- at most 44 bits ----------> Figure 2: IPv6 prefix to Generalized IPv4 prefix More text TBD, but Figure 2 is expected to be self-explanatory. Despres, et al. Expires March 25, 2012 [Page 11] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 6.2. From Generalized IPv4 prefix to IPv4 prefix or IPv4 address or IPv4 Address + Port-set ID (A) CE Generalized IPv4 prefix shorter than 32 bits +-----------------------------------+ | CE Generalized IPv4 prefix | || +-----------------------------------+ || : : || +-----------------------------------+ || | CE IPv4 prefix | \/ +-----------------------------------+ <----------------- 32 bits -----------------> (B) CE Generalized IPv4 prefix having 32 bits +-------------------------------------------+ | CE Generalized IPv4 prefix | || +-------------------------------------------+ || : : || +-------------------------------------------+ || | CE IPv4 address | \/ +-------------------------------------------+ <---------------- 32 bits -----------------> (C) CE Generalized IPv4 prefix having 33 to 44 bits +--------------------------------------------------+ | CE Generalized IPv4 prefix | || +--------------------------------------------------+ || : : || +-------------------------------------------+------+ || | CE IPv4 address | PSID | \/ +-------------------------------------------+------+ <----------------- 32 bits -----------------><--.--> | max 12 bits Figure 3: Generalized IPv4 prefix to IPv4 prefix or IPv4 address or IPv4 Address + PSID More text TBD, but Figure 3 is expected to be self-explanatory. NOTE: If the Port-set ID (PSID) has its maximum length of 12 bits, the identified port set does not contain odd-even pairs of ports (see Section 6.3). Practical configurations would therefore use mapping rules such that the PSIDs do't exceed 11 bits, but the algorithm does not need to impose it. (PSID limited to 11 bits is equivalent to L(CE IPv6 prefix) < L(Rule IPv6 prefix) - L(Rule IPv4 prefix) + 44.) Despres, et al. Expires March 25, 2012 [Page 12] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 6.3. From Port-set ID to Port set 1| |0 |4 5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x| PSID |x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ : : ^ | : | | | Any value > 0 Any value Figure 4: From Port-set ID to Exclusive port set More text TBD, but Figure 4 is expected to be self-explanatory. 7. Mapping from IPv4 address or address plus port to CE IPv6 Address The following subsections detail steps whereby a CE IPv6 address is derived from a CE IPv4 address, or address plus port if a port is available. The derived CE IPv6 address has two REQUIRED properties: o It MUST start with the CE IPv6 prefix of the CE that has the IPv4 address or address plus port in its IPv4 address space. o It MUST be distinguishable from any possible IPv6 address that starts with this prefix and is not concerned with 4rd. This is achieved with the 200:5efe::/64 4rd-specific value in its Interface ID field of [RFC4291] (see Figure 6). The example below illustrates such a derivation where CE IPv6 prefix, Rule IPv6 prefix, and Rule IPv4 prefix, are supposed be the same as in Section 6 (i.e. respectively 2001:db4:4444:4000::/52, 2001: db0::/28, and 192.32../12 = 0x602)). The IPv4 address and port are chosen to be in the IPv4 address space of the considered CE. Note that, for clarity, lengths of Rule prefixes and CE prefix are multiple of 4 bits, but that similar derivations with less constrained lengths are also possible. Despres, et al. Expires March 25, 2012 [Page 13] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 Item Hexadecimal Value Nb of bits - IPv4 port : 8488 16 - Derived Max Port-set ID : 488 12 - IPv4 address : 60244444 32 - Rule IPv4 prefix that matches this IPv4 address : 602 12 - Resulting CE index : 44444488 32 - Rule IPv6 prefix of the Rule : 20010DB 28 - Padding to 64 bits : 0 4 - Resulting CE IPv6 address : 20010DB44444488002005EFE00000000 128 - Prefix routed to the CE : 20010DB444444 52 The other example below illustrates such a derivation where Rule IPv6 prefixes are unchanged (2001:db0::/28, and 192.32../12 = 0x602 respectively). The considered CE has now an exclusive IPv4 address, and the IPv4 packet sent to it has a port-less layer-4 protocol. The CE IPv6 prefix is supposed to be 2001:db1:1111::/48, which maps to IPv4 address 0x60211111 =192.33.17.17. Item Hexadecimal Value Nb of bits - Destination IPv4 address : 60211111 32 - Rule IPv4 prefix that matches this IPv4 address : 602 12 - Resulting CE index : 11111 20 - Rule IPv6 prefix of the Rule : 20010DB 28 - Padding to 64 bits : 0000 16 - Resulting CE IPv6 address : 20010DB11111000002005EFE00000000 128 - Prefix routed to the CE : 20010DB11111 48 Despres, et al. Expires March 25, 2012 [Page 14] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 7.1. From IPv4 Address or Address + Port to Rule IPv4 prefix + Max CE index (A) The IPv4 packet contains layer-4 ports 1| |0 |4 5| +---------------------------------+----------------+ | Destination IPv4 address |Destination port| +---------------------------------+---+------------+ : : : :<- 12 bits -> +-----------------+ : : : | Rule IPv4 prefix| : : : +-----------------+ : : : : : : : +---------------+ +------------+ | CE IPv4 suffix| | Max PSID | +---------------+ +------------+ : : / / : : / / : :/ / +---------------+------------+ | Max CE index | +----------------------------+ <-------------------- 44 bits -----------------> (B) The IPv4 packet contains no layer-4 port +---------------------------------+ | Destination IPv4 address | +-----------------+---------------+ : : : +-----------------+ : | Rule IPv4 prefix| : +-----------------+ : : : +---------------+ | Max CE index | +---------------+ <------------- 32 bits -----------> Figure 5: From IPv4 Destination to Rule IPv4 prefix + Max CE index More text TBD, but Figure 5 is expected to be self-explanatory. Despres, et al. Expires March 25, 2012 [Page 15] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 7.2. From Rule IPv4 prefix + Max CE index to CE IPv6 address +------------------+ | Rule IPv4 prefix | +------------------+ || \/ +--------------------------+ | Rule IPv6 prefix | +--------------------------+ (A) Truncation case <------------------ More than 64 bits -----------------> +---------------------------+--------------------------+ | Rule IPv6 prefix | Max CE index | +---------------------------+-----------------+--------+ :<------------------- 64 bits ----------------> : :<----- 64 bits ------> : : : +---------------------------------------------+----------//---------+ | Subnet prefix | 4rd IID | +---------------------------------------------+----------//---------+ : : +-------------------------------------------------------------------+ | CE IPv6 address | +-------------------------------------------------------------------+ (B) Padding case <------------ Up to 64 bits ------------> +-------------------------+---------------+---+ | Rule IPv6 prefix | Max CE index | 0 | +-------------------------+---------------+---+ : : : :<------------------- 64 bits ----------------> +-----------------------------------------+---+----------//---------+ | Subnet prefix | 4rd IID | +---------------------------------------------+----------//---------+ : : +-------------------------------------------------------------------+ | CE IPv6 address | +-------------------------------------------------------------------+ Figure 6: From Rule IPv4 prefix + Max CE index to CE IPv6 address Despres, et al. Expires March 25, 2012 [Page 16] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 In order to permit coexistence of the 4rd stateless solution with other solutions in the same nodes, CE IPv6 addresses MUST be differentiable from all other valid IPv6 addresses. For this, 4rd Interface IDs are proposed to start with 200:5efe::/64 (a choice to be confirmed by IANA). Reasons of this choice are the following: (1) In order to indicate a universal scope of this Interface-ID format, bit 6 of the first octet must be set to 1 (the "u" bit of [RFC4291]); (2) In order to guarantee no conflict with other universal scope Interface IDs, other bits of the first 32 bits are those of the IANA OUI in modified EUI format (the same as in [RFC4214]). Bits 64-127 are set to 0 if theDomain-traversal method is encapsulation, and is the embedded IPv4 address in case of double translation. 8. Mapping from IPv4 source address to BR IPv6 Address If a CE has an IPv4 packet to forward across the Domain and finds that its destination is not another CE (no Rule IPv4 prefix matches its IPv4 destination address), it has to send it to the IPv4 Internet via a BR. For compatibility wit Ingress filtering, this BR MUST be one that has an incoming route from the Internet that can reach this CE. +---------------------------------+ | CE IPv6 prefix | +------------------+--------------+ : : +------------------+ | Rule IPv6 prefix | +------------------+ || \/ +------------------------------------------------------------+ | Rule BR IPv6 address | +------------------------------------------------------------+ Figure 7: From IPv4 source address to BR IPv6 Address NOTE: While the above mapping is sufficient for Domain traversal based on encapsulation of IPv4 packets in IPv6 packets, it isn't sufficient for those based on double translation. With these, BRs need to find IPv4 destination addresses in destination IPv6 addresses that reach it. For this, the BR IPv6 address of each Rule can be replaced by a BR IPv6 prefix of 96 bits. BR IPv6 addresses are then constructed with embedded IPv4 addresses in their last 32 bits. Despres, et al. Expires March 25, 2012 [Page 17] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 In the example below, we take the rule of previous examples, whose Rule IPv6 prefix = 2001:db0::/28, and Rule IPv4 prefix = 192.32../12. We then take BR IPv6 address = 2001:db3::3 as third parameter (not needed in previous sections). Item Hexadecimal Value Nb of bits - Destination IPv4 address : 60433333 32 - Rule IPv4 prefix : 602 (non matching) - CE IPv6 prefix : 20010DB4 4444 4 52 - Rule IPv6 prefix that matches it : 20010DB 28 - BR IPv6 address of this Rule : 20010DB30000000000000000000000003 128 9. Example of 4rd Domain with two Rule BR addresses and three Rule IPv4 prefixes If a 4rd domain has a split IPv4 space to distribute to CEs, i.e. a space defined by several disjoint IPv4 prefixes, several Mapping rules can be used to keep the IPv6 routing plan independent from any IPv4 influence. (The "entropy" of the IPv4 space is thus not passed on to the IPv6 the IPv6 space.) To illustrate this possibility, we now consider an ISP having 2001: 0db0::/28 as unique IPv6 prefix, and three IPv4 prefixes. The first two, 192.32../13 and 192.64../14, come from an IPv4 service provider whose BR has 2001:db1::1 as IPv6 addresses. The last one, 192.16.64.0/14, comes from an IPv4 service provider whose BR has 2001:db2::2 as IPv6 address. The following Mapping rules can be configured to evenly distribute all IPv4 addresses. They also make sure that each IPv4 packet that leaves the domain does it via the right BR (that which, as far as ingress filtering is concerned, has a route from the IPv4 internet for the right IPv4 prefix). +------------------+------------------+-----------------+ | Rule IPv4 prefix | Rule IPv6 prefix | BR IPv6 address | +------------------+------------------+-----------------+ | 192.32../13 | 2001:db0::/29 | 2001:db1::1 | | 192.16../14 | 2001:db8::/30 | 2001:db1::1 | | 192.24../14 | 2001:dbc::/30 | 2001:db2::2 | +------------------+------------------+-----------------+ Despres, et al. Expires March 25, 2012 [Page 18] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 With these mapping rules, here are examples of CE parameters: +-------------------------+--------------+----------------+---------+ | CE IPv6 prefix | CE IPv4 | Port-set | Nb of | | | address | pattern | ports | | | | (Hexadecimal) | | +-------------------------+--------------+----------------+---------+ | 2001:db0:1111:1000::/52 | 192.32.17.17 | y1xx | 3840 | | 2001:db8:1111::/48 | 192.16.17.17 | N/A | 64K | | 2001:dbc:1111:1000::/52 | 192.24.17.17 | y2xx | 3840 | +-------------------------+--------------+----------------+---------+ 10. Security considerations Like any mechanism that needs parameters to be configured by ISPs, the 4rd stateless address mapping is subject to consequences of erroneous parameter settings. Other than that, with anti-spoofing checks of Section 5, no security vulnerability has been identified that would be due to the 4rd stateless address mapping. 11. IANA Considerations For the 4rd stateless address mapping to possibly coexist with a maximum of other IPv4/IPv6 address mappings, a 4rd-specific Interface IDs are desirable. For this, 200:5efe::/32 in their first half is proposed (universal scope with the IANA OUI, as explained in Section 7.2). 12. Acknowledgements Authors would like to acknowledge the invaluable contribution of Satoru Matsushima. His very early and constant support of the stateless approach has been key for its progress in IETF. Tetsuya Murakami deserves specific recognition for his implementation of an early 4rd specification, including its Ping mechanism for shared addresses. This has been important to confirm soundness of the approach. Without Mark Townsley's convincing arguments made to the IETF hierarchy, having stateless solutions as work items in Softwire wouldn't have been done in the same time frame. He has to be thanked for it. Wojciech Dec and some others made a number of relevant remarks on the Working Group discussion list that contributed to improve the proposed design. Despres, et al. Expires March 25, 2012 [Page 19] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 13. References 13.1. Normative References [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. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 13.2. Informative References [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. Despres, et al. Expires March 25, 2012 [Page 20] Internet-Draft IPv4-IPv6 Stateless Add. Mapping (4rd) September 2011 Authors' Addresses Remi Despres (editor) RD-IPtech 3 rue du President Wilson Levallois, France Email: despres.remi@laposte.net Jacni Qin ZTE Shanghai China Email: jacni@jacni.com Simon Perreault Viagenie 2875 Laurier, suite D2-630 Quebec Canada Email: simon.perreault@viagenie.ca Xiaohong Deng France Telecom Hai dian district, 100190 Beijing China Email: xiaohong.deng@orange.com Despres, et al. Expires March 25, 2012 [Page 21]