Internet Engineering Task Force R. Despres, Ed. Internet-Draft RD-IPtech Intended status: Standards Track J. Qin Expires: February 20, 2012 ZTE S. Perreault Viagenie X. Deng France Telecom August 19, 2011 Stateless Address Mapping for IPv4 Residual Deployment (4rd) draft-despres-softwire-4rd-addmapping-00 Abstract This document specifies an address mapping mechanism, 4rd, for service providers to offer residual deployment of the IPv4 service across IPv6-only domains. Ease of operation and scalability are due to address mapping being done stateless (no per customer states). 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. IPv4 address sharing is based on exclusive port sets that are algorithmically derived of IPv4 prefixes longer than 32 bits. The 4rd address mapping can be used combined with various tunneling or translation mechanisms. It can also can be used either alone or in parallel with stateful mechanisms used for their flexibility. 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 February 20, 2012. Copyright Notice Despres, et al. Expires February 20, 2012 [Page 1] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Design Objectives . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Architectural model . . . . . . . . . . . . . . . . . . . 5 4.2. Compatibility with Asymmetric routing . . . . . . . . . . 5 4.3. Compatibility with Reverse-Path Forwarding . . . . . . . . 6 4.4. Same routes for IPv4 packets and IPv6 packets . . . . . . 6 4.5. Multiple IPv4 prefixes without impact on IPv6 routing . . 6 4.6. Stateless Support of Shared IPv4 Addresses . . . . . . . . 7 4.6.1. Flexible Sizes of CPE-assigned Port-Sets . . . . . . . 7 4.6.2. Odd-even port couples in assigned port sets . . . . . 7 4.6.3. Interleaved Port Sets for UPnP friendliness . . . . . 7 5. Specification of the 4rd Stateless Address Mapping . . . . . . 8 5.1. Mapping-Rule Parameters and Basic Operation . . . . . . . 8 5.2. Mapping from IPv6 Prefix to IPv4 Prefix (including A+P) . 9 5.3. Mapping from IPv4 address or A+P to IPv6 address . . . . . 10 5.4. Algorithmic Derivation of a Port Set from a Port-Set ID . 13 5.5. The CPE-Cascade Option . . . . . . . . . . . . . . . . . . 14 6. Mapping-rule Examples for some Representative 4rd Domains . . 14 7. Security considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Despres, et al. Expires February 20, 2012 [Page 2] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 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 routing done only in IPv6. They will however have to maintain residual IPv4 connectivity across these networks, for some customers with exclusive IPv4 addresses, and for some others with shared IPv4 addresses. This document specifies a mechanism, 4rd, whereby ISPs statelessly derive IPv4 addresses they assign to customers from the IPv6 prefixes they have delegated to them. In this document, stateless means without per-customer states in ISP nodes concerned with the 4rd address mapping and without, for 4rd, states about other CPEs in each CPE. This specification can be used in association with a variety of tunneling or translation mechanisms that are in scope of other documents. (Earlier 4rd documents such as [I-D.despres-softwire-sam]-sec. 3.2 and [I-D.murakami-softwire-4rd] simultaneously covered stateless address mapping and encapsulation- based tunneling, but it has now become clearthat stateless address mapping can have a much larger scope than just this tunneling.) Design objectives that influenced this specification are listed in Section 4. Section 5 specifies the 4rd stateless address mapping. Examples of 4rd mapping-rule configurations, for diverse ISP needs, are illustrated in Section 6. 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]. 3. Terminology ISP: Internet-Service Provider. In this document, it can be a DSL, a fiber-optics, cable, or a wireless operator. It can also be a private- network operator. 4rd CPE (CPE if context permits): Customer Premise Equipment that supports the 4rd stateless address mapping. Despres, et al. Expires February 20, 2012 [Page 3] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 4rd AFTR (AFTR if context permits): Address-Family-Transition Router that supports the 4rd stateless address mapping. 4rd domain (Domain if context permits): An ISP IPv6-only network across which a residual IPv4 service is offered using the 4rd address mapping. It has at least one 4rd AFTR at its border to the IPv4 Internet, and a number of CPEs which may or may not be 4rd CPEs. A+P: IPv4 address plus transport-layer port, also known as "transport address". Port-set ID (PSID): An identifier from which a port set is algorithmically derived according to Section 5.4. CPE IPv6 prefix: An IPv6 prefix delegated to a CPE, e.g. per [RFC3769]). CPE IPv4 prefix: In this document, an IPv4 address prefix or an IPv4 address followed by a Port-set ID. 4rd mapping rule (Mapping rule, or Rule, if context permits): A set of parameters that permit to derive a CPE IPv4 prefix from a CPE IPv6 prefix, and to derive an IPv6 address from an IPv4 address or A+P. A 4rd domain has at least one Mapping rule, and may have several. Each Rule contains at least a Domain IPv6 prefix, a Domain IPv4 prefix, and an AFTR IPv6 prefix. Domain IPv6 prefix: An IPv6 prefix that appears in a Mapping rule. Domain IPv4 prefix: An IPv4 prefix that appears in a Mapping rule. AFTR IPv6 prefix: For a set of AFTRs that share the same IPv4 prefixes, the /64 IPv6 prefix used by CPEs to reach them. 4rd IID prefix: A 32-bit value use to disambiguate what concerns the 4rd address mapping from other address mapping that may coexist it the same AFTRs or CPEs, e.g. with dynamic port assignments. Despres, et al. Expires February 20, 2012 [Page 4] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 Domain IPv6 suffix: Optional parameter of a Mapping rule applicable to specific configurations having cascaded CPEs (see Section 5.5). 4. Design Objectives 4.1. Architectural model The 4rd stateless address mapping is for an IPv6-only routing domain in which: o Each CPE is delegated an IPv6 prefix. o Residual IPv4 service has to be offered to CPEs. o Some design objectives detailed in the following sections have to be satisfied. If some objective(s) would be relaxed, the specification could be simplified accordingly. Yet, a unique solution that covers a large scope of use cases is in general be better for ISPs and for product vendors, provided it remains simple enough. This specification is expected to be such. 4.2. Compatibility with Asymmetric routing An ISP can have border points to the IPv4 Internet that are geographically far apart and for which there are incoming routes for the same prefixes. This can be the case with provider-independent prefixes (PIs), if routed from the Internet core to the via several independent providers. It can also be the case with provider- dependent prefixes (PAs), if coming from providers having several Internet exchange points. packets sent to a host of another ISP via a given border point may have answers coming via another border point. End-to-end routes can in this case be asymmetric. Unless some nodes between AFTRs and CPEs would also deal with both IPv4 and IPv6 (which is contrary to the IPv6-only nature of the Domain), this implies in practice static address mappings in AFTRs. (Otherwise, complex coordination between widely separated AFTRs would be necessary.) Compatibility with asymmetric routing without complex coordination between AFTRs is an objective of the 4rd specification. Despres, et al. Expires February 20, 2012 [Page 5] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 4.3. Compatibility with Reverse-Path Forwarding An ISP can be allocated IPv4 prefixes from different lower-tier providers (tier numbers decrease in direction to the Internet core). These providers normally exercise anti-spoofing control at their border points with the reverse-path forwarding of [RFC3704]. A CPE that is assigned an IPv4 address for incoming connectivity must therefore send its IPv4 packets to off-Domain destinations via the provider that delegated the prefix of this IPv4 address. Sending IPv4 packets to the Internet via AFTRs that are compatible with reverse-path forwarding is an objective of this specification. 4.4. Same routes for IPv4 packets and IPv6 packets If IPv4 traffic follows the same routes than IPv6 traffic, the impact on IPv4 quality of service can remain negligible compared with direct support of IPv4 routing in the Domain. This is useful to facilitate ISP moving from dual-stack routing to IPv6-only routing. Also, scalability of the solution is improved by the fact that AFTRs don't need to deal with traffic between CPEs of the Domain. (In particular, if some content-providers have servers in the domain, it traffic between in-domain customers and these servers does not contribute to the load of AFTRs.) Support of common routes between IPv4 and IPv6 traffics, in particular between CPEs, is an objective of the 4rd specification. 4.5. Multiple IPv4 prefixes without impact on IPv6 routing An ISP whose need for IPv4 addressing space has increased over time has typically a number of allocated IPv4 prefixes. The IPv6 routing plan is easier to setup if not influenced by the multiplicity of these prefixes. In other words, the problem is to statelessly distribute the fragmented IPv4 space among CPEs whose IPv6 prefixes have been allocated without any concern for IPv4. NOTE: IPv4 address sharing can be used to reduce the number of IPv4 prefixes to be supported. Let us take, for example, an ISP whose IPv4 prefixes are one /10, two /11s, one /14, one /15, and one /16 (a real example of the past). If it returns the three longest prefixes to the free pool, it reduces the IPv4-space size by only 5%. If it shares one IPv4 address out of 16 among 16 customers, the total number of supported customers is increased by 94%, which more than compensates the 5% loss. (Whether returning prefixes to the free pool would be with a compensation is beyond the scope of this document.) Despres, et al. Expires February 20, 2012 [Page 6] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 Ability to support multiple IPv4 prefixes without impact on IPv6 routing is an objective of this specification. 4.6. Stateless Support of Shared IPv4 Addresses Because IPv4 prefixes allocatable to ISPs has been exhausted, the need to share IPv4 public address among several customers is now well known, with ports as the multiplexing instrument. While dynamic assignments of ports to customers can optimize the sharing ratio of IPv4 addresses, static assignments are an approach to comply with route commonality between IPv4 and IPv6 of Section 4.4, and with asymmetric-routing compatibility of Section 4.2. Also, stateless operation simplify operation in many typical cases. It is an objective of the 4rd specification. 4.6.1. Flexible Sizes of CPE-assigned Port-Sets In IPv4, some customers are delegated IPv4 prefixes shorter than 32 bits, while the vast majority are only assigned single IPv4 addresses. In the context of shared IPv4 addresses, some customers will need individual addresses, and sooner or later the vast majority will have to be satisfied with shared IPv4 addresses. Ability to assign port sets of different sizes to different classes of customers is an objective of this specification. Because it has to be done without interfering with other objectives, different port- set sizes are linked to different lengths of delegated IPv6 prefixes. 4.6.2. Odd-even port couples in assigned port sets A number of protocols designed a long time ago require pairs two consecutive ports. In particular, a SIP application using the RTP of [RFC3550] without support of the RTCP of [RFC3605] uses odd/even port pairs. Also, where FTP of [RFC0959] is used in passive mode without the option that relaxes this constraint, even/odd pairs are needed. Although there may be very few impacted hosts if odd/even pairs would become impossible, it is hard to predict where and when they this appear. That may be costly to diagnose. In order to ensure backward compatibility with old practices, assigning port sets that contain odd-even pairs of ports is an objective of this specification. 4.6.3. Interleaved Port Sets for UPnP friendliness In a CPE having a restricted port set and a NAT44 that supports UPnP for hosts to reserve ports for incoming connectivity, the number of Despres, et al. Expires February 20, 2012 [Page 7] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 UPnP attempts before obtaining a port is a legitimate concern. With UPnP version 1, widely deployed, hosts try ports in sequential order numbers until one is obtained from the NAT. By interleaving port sets, the likely number of attempts before getting an available port can be statistically reduced. Assigning to CPEs port sets that are as interleaved as possible is, for UPnP-version-1 friendliness, an objective of this specification. This objective is however subject to the odd/even-pair constraint of Section 4.6.2. NOTE: Typical NAT implementations assign ports based on the assumption of a single port range. With this objective of interleaved port sets they need to be adapted. Provided there is a simple algorithm that does a 1:1 mapping between ports of the port- set and a continuous port range, this is not difficult. This is the case with port sets of Section 5.4. 5. Specification of the 4rd Stateless Address Mapping 5.1. Mapping-Rule Parameters and Basic Operation A 4rd domain are one or several Mapping rules, each one having the following parameters: o REQUIRED parameters: * Domain IPv6 prefix * Domain IPv4 prefix * AFTR IPv6 prefix o OPTIONAL parameters (see Section 5.5): * CPE IPv6 suffix * CPE IPv6-prefix length Each AFTR has incoming routes from the Internet for one or several IPv4 prefixes. It MUST know all Mapping rules that have one of these prefixes as Domain IPv4 prefix. In order to send IPv4 packets to other CPEs via the same routes as IPv6 packets, each CPE 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 Despres, et al. Expires February 20, 2012 [Page 8] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 configurations. Since this is easily feasible with common memory sizes, it is REQUIRED. For each packet received at its IPv4 interfaces, an AFTR or a CPE MUST use Mapping rules it knows to determine the IPv6 destination used to traverse the Domain. It MUST also verify that the IPv4 source of the packet is one that would be a possible destination in the reverse direction. If one of these two steps fails, the IPv4 packet is silently discarded. Otherwise the packet is forwarded with whatever tunneling or translation mechanism applies. For each packet received at its IPv6 interface with an IID as specified in Section 5.3, an AFTR or CPE MUST check that the IPv4 address or A+P it contains is a possible destination in the reverse direction and, if the packet is encapsulated, that the IPv6 source address is that which Mapping rules derive from the IPv4 source. In case of success, it MUST forward the packet to the IPv4 destination found in the IPv6 packet (with decapsulation or translation as the case may be). Otherwise, it MUST silently discard the packet. Since ports are used as extension mechanism of IPv4 addresses, protocols that have no ports are excluded from the solution. ICMP error messages that concern discarded packets that had ports in their transport-layer headers are not in this case because they contain copies of discarded-packet headers. ICMP echo-request packets have no ports but have in IPv4 a 16-bit identifier field. In both CPEs and AFTRs, this field MUST be processed as though it would be a CPE port. Note that this permits CPEs having shared IPv4 addresses to Ping remote IPv4 hosts that have exclusive IPv4 addresses. (This does not permit IPv4 Pings between two shared-address hosts, but this is inherent to IPv4 address sharing. IPv6 Pings should be used instead.) CPEs may receive Domain mapping rules in a variety of classic provisioning methods, including DHCPv6, the Broadband Forum's "TR-69", a DNS record, etc. A separate draft on DHCPv6 provisioning is expected to be discussed in Softwire, with draft-mrugalski-softwire-dhcpv6-4rd-00 as envisaged file name. 5.2. Mapping from IPv6 Prefix to IPv4 Prefix (including A+P) How a CPE derives its CPE IPv4 prefix is detailed in Figure 1. Despres, et al. Expires February 20, 2012 [Page 9] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 <------------------ up to 64 bits -------------------> +-----------------------------------------------------+ | CPE IPv6 prefix (delegated by the ISP) | +-----------------------------------------------------+ : : : (1) Find a matching rule : +--------------------------------+ : | Domain IPv6 prefix | (2) Delete the : +--------------------------------+ Domain IPv6 prefix : : : +--------------------+ | | +--------------------+ Domain IPv4 prefix : : | : : +---|---------+ (3) Add the : | | | Domain IPv4 prefix : +-------------+ of the rule : : : +----------------------------------+ | CPE IPv4 prefix (A or A+P) | +----------------------------------+ <--------- max 46 bits -----------> Figure 1: Mapping from CPE IPv6 prefix to CPE IPv4 prefix (A or A+P) NOTE: If, as it seems so far, CPEs are expected to have non overlapping IPv6 prefixes, the first match found is sufficient. Should the need for CPE IPv6 ) prefixes that overlap be confirmed, as some have suggested, longest match should become a requirement. 5.3. Mapping from IPv4 address or A+P to IPv6 address How a CPE or AFTR derives from an IPv4 address or A+P an IPv6 address is detailed in Figure 2 (in-domain address case) and in Figure 3 (off-domain address case). Despres, et al. Expires February 20, 2012 [Page 10] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 |0 31| |0 3| 15| +-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | | Destination Port (if any) | +-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (1) : :<--L-->:: : Find a rule having : (3) : (*) : : a matching : If a port is available : : Domain IPv4 prefix : and isn't in the first 4K, : +-------------------+ : extract L bits before bit 15, : | Domain IPv4 prefix| : and reverse their order. : +-------------------+ (2) : : : : Delete : +-+-+-+-+ : the Domain: | | :IPv4 prefix: (4) +-+-+-+-+ : : Concatenate available : : +-----------+ intermediate results : : | | : : +-----------+ _____________________/ / : : / ______________________/ : :/ / +-----------+-------+ Domain IPv6 suffix | | (if applicable) +-----------+-------+ / : (5) : / Padding to 64 bits : Complete the : / (if needed) : Tunnel-endpoint : / ____________| : IPv6 address : | | |0 : : | | |64 127| +----- - - - - ------+-------------------+-|-+-|-+--- - - - - - ---+ | Domain IPv6 prefix | | | 0 | 4rd IID (**) | +----- - - - - ------+-------------------+---+---+--- - - - - - ---+ CPE IPv6 address / : ________________________________/ : / : +--------------------------+--------------------------+ | 4rd IID prefix (**) | 0 or IPv4 address (***) | +--------------------------+--------------------------+ (*) L = maximum length of Port-set IDs of the matching rule (**) . The 4rd IID prefix (TBD by IANA) for encapsulation-based or double-translation based solutions . 0 per RFC 6145 for IPv6-only CPEs (***) . 0 for encapsulation-based solutions . The IPv4 address for translation-based solutions Figure 2: IPv4 (A or A+P) to IPv6 Mapping - In-Domain Address The maximum length L of port-set IDs is in absence of a CPE-cascade Despres, et al. Expires February 20, 2012 [Page 11] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 option, is L = min(14, 64 - Length(Domain IPv6 prefix) - (32 - Length(Domain IPv4 prefix)). With the CPE-cascade option, the CPE IPv6-prefix length is a rule parameter, say X, and L = X - Length(Domain IPv6 prefix) - (32 - Length(Domain IPv4 prefix)). For tunnel-based solutions (encapsulation or double-translation based), 4rd IIDs have to be different from any IID a host of the CPE site may legitimately have. Also, in order to permit coexistence of the 4rd stateless solution with other solutions (e.g. some using NAPT to support dynamic port mappings for more optimized address sharing), 4rd has to be different from any IID that may be used by these other solutions. In particular, it has to differ from that used by IPv4/ IPv6 translators conforming to [RFC6145]. For this, the value proposed to IANA for the 4rd IID prefix is 200:5efe::/32. It has bit 6 of its first octet set to 1, in order to indicate a universal scope of the IID ("u" bit of). Its other bits have, like in [RFC4214], IANA OUI in modified EUI format (ref. [RFC4291]). | IPv4 DST | | IPv4 SRC | +--------------------------+ +--------------------------+ (1) : (2) : Detect that no rule has a : Find a rule having : matching Domain IPv4 prefix : a matching : : Domain IPv4 prefix : : : +-------------------+ : | Domain IPv4 prefix| : +-------------------+------+ (3) Take the AFTR IPv6 prefix of the rule and the appropriate 4rd IID to complete the IPv6 address |0 |64 127| +---------------------------------+---------------------------------+ | AFTR IPv6 prefix | 4rd IID (*) | +---------------------------------+---------------------------------+ AFTR IPv6 address (*) As for in-domain addresses Figure 3: IPv4 (A or A+P) to IPv6 Mapping - Off-Domain Address Despres, et al. Expires February 20, 2012 [Page 12] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 5.4. Algorithmic Derivation of a Port Set from a Port-Set ID The port set specified by an [A] From IPv4 prefix longer than 32 bits to PSID |0 31| +-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+ | CPE IPv4 prefix (A+P) | +-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Delete the first 32 bits : : +-+-+-+-+ (Port-set ID) --- PSID | +-+-+-+-+ [B] From PSID to port-set pattern +-+-+-+-+ | PSID | +-+-+-+-+ (1) Reverse bits left to right : : ("ABC..." => "...CBA") : : +-+-+-+-+ Reversed port-set ID --> |R-PSID | +-+-+-+-+ (2) Place the result in the port pattern : : with its last bit in bit 14 position : : : : |0 3| : 14: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-set pattern: |y y y y|x x x x x x x|R-PSID |x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ \___________/ \/ | \______________/ 0x1 to 0xF Any value Figure 4: Port Pattern derived from a Port-Set ID Despres, et al. Expires February 20, 2012 [Page 13] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 5.5. The CPE-Cascade Option A use case has been identified where the ISP that wants to offer residual IPv4 service to offer has to offer it across an IPv6-only service obtained from another ISP, and where this other ISP provides its own CPEs in customer sites (the "outer CPEs"). In outer CPEs, the other ISP adds a "suffix" to customer-site IPv6 prefixes to select among its physical interfaces. The 4rd ISP then attaches its 4rd CPEs to a specific interface of outer CPEs, the same in all sites. The suffix of this interface must be included in IPv6 addresses that target 4rd CPEs, but it must not be included in CPE IPv4 prefixes (that would be waste of the precious IPv4 address space of the Domain). For this to work, two optional rule parameters are added: the Domain IPv6 suffix and the CPE IPv6-prefix length. Their use has been specified in Section 5.3. An example of Domain configuration using this option is shown in Section 6. 6. Mapping-rule Examples for some Representative 4rd Domains The following examples are chosen to illustrate representative use cases of 4rd mapping rules. Many other combinations are possible, in particular by mixing and matching properties of the chosen examples. (A) ISP PROVIDING EXCLUSIVE AND SHARED ADDRESSES We consider an ISP domain having the following parameters: * Domain IPv6 prefix: 2001:db0::/28 * Domain IPv4 prefix: 192.32.0.0/12 The IPv4 prefix may be a provider-aggregetable prefix allocated by a single lower-tier provider of the ISP. It can also be a provider independent prefix, with routes to the Domain for this prefix from several lower-tier operators of the ISP. The choice is to assign in /48 IPv6 prefixes to privileged customers those who paying for exclusive IPv4 addresses, and /52s to ordinary customers who accept to share their IPv4 addresses. Privileged customers are expected to be a minority. Despres, et al. Expires February 20, 2012 [Page 14] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 With up to 2^16 customers having privileged addresses, this leaves 2^20 - 2^16 IPv4 addresses to be shared, giving 2^16 + 2^4 * (2^20 - 2^16) = 15,794,176 ordinary customers. Thus, 15 times more customers are supported than if all had exclusive addresses (their number would have been 2^(32-12) = 1,048,576). The Domain has for this the following mapping rule: +--------------------+--------------------+-------------------------+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +--------------------+--------------------+-------------------------+ | 192.32../12 | 2001:db0::/28 | 2001:db0:aaaa:aaaa::/64 | +--------------------+--------------------+-------------------------+ With this rule, here are representative examples of CPE parameters: +-------------------------+--------------+------------------+-------+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-------------------------+--------------+------------------+-------+ | 2001:db1:1111:/48 | 192.33.17.17 | NA | 64K | | 2001:db2:2222:2000::/52 | 192.34.34.34 | yyyyxxxxxxx0100x | 3840 | +-------------------------+--------------+------------------+-------+ NOTE: Without changing the mapping rule, some customers could be delegated /56 IPv6 prefixes. This would increase even more the number of supportable customers, with 960 ports per /56 customer. (B) ISP HAVING IN IPV4 THRE PREFIXES FROM DIFFERENT PROVIDERS" We now consider an ISP having 2001:0db0::/28 as Domain IPv6 prefix, and three Domain IPv4 prefixes from different lower-tier providers, 192.32.128.0/13, 192.64.128.0/14, 192.16.64.0/14, and 192.16.128.0/13. The following Mapping rules ensure that each IPv4 packet that leaves the domain does it via the right AFTR (that which, as far as anti-spoofing protection is concerned, is attached to the right lower-tier provider). +--------------------+--------------------+-------------------------+ | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) | +--------------------+--------------------+-------------------------+ | 192.32../13 | 2001:db0::/29 | 2001:db0:aaaa:aaaa::/64 | | 192.16../14 | 2001:db8::/30 | 2001:db1:bbbb:bbbb::/64 | | 192.24../14 | 2001:dbc::/30 | 2001:db2:cccc:cccc::/64 | +--------------------+--------------------+-------------------------+ Despres, et al. Expires February 20, 2012 [Page 15] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 With these mapping rules, here are examples of CPE parameters: +-------------------------+--------------+------------------+-------+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-------------------------+--------------+------------------+-------+ | 2001:db0:1111:1000::/52 | 192.32.17.17 | yyyyxxxxxxx1000x | 3840 | | 2001:db8:1111::/48 | 192.16.17.17 | NA | 64K | | 2001:dbc:1111:1000::/52 | 192.24.17.17 | yyyyxxxxxxx0100x | 3840 | +-------------------------+--------------+------------------+-------+ (C) ISP PROVIDING SHARED ADDRESSES ACROSS WITH CPE CASCADES We now consider an ISP whose IPv6-only infrastructure comes from another provider whose CPEs use a 4-bit suffix to reach LAN interfaces at which 4rd CPEs are attached (see ). The suffix value is supposed to be 0xF. The 4rd ISP has 2001:0db0::/28 as Domain IPv6 prefix, and has four Domain IPv4 prefixes coming from the same lower-tier provider, namely 192.32.128.0/13, 192.64.128.0/14, 192.16.64.0/14, and 192.16.128.0/13. Each IPv4 address is shared among 16 customers. With its 2^20 IPv4 addresses, The ISP can thus support up to 2^24 customers. The following mapping rules can be used: +-----------------+-----------------+----------------+--------------+ | Domain IPv4 | Domain IPv6 | CPE IPv6 max | CPE IPv6 | | prefix | prefix | length | suffix | +-----------------+-----------------+----------------+--------------+ | 192.32../13 | 2001:db0::/29 | 52 | 0xF | | 192.16../14 | 2001:db8::/30 | 52 | 0xF | | 192.24../14 | 2001:dbc::/30 | 52 | 0xF | +-----------------+-----------------+----------------+--------------+ With these mapping rules, here are examples of CPE parameters: +-------------------------+--------------+------------------+-------+ | CPE IPv6 prefix | CPE IPv4 | Port-set bit | Nb of | | | address | pattern | ports | +-------------------------+--------------+------------------+-------+ | 2001:db0:1111:1f00::/52 | 192.32.17.17 | yyyyxxxxxxx1000x | 3840 | | 2001:db8:2222:2f00:/52 | 192.16.34.34 | yyyyxxxxxxx0100x | 3840 | | 2001:dbc:4444:4f00::/52 | 192.24.70.70 | yyyyxxxxxxx0010x | 3840 | +-------------------------+--------------+------------------+-------+ Despres, et al. Expires February 20, 2012 [Page 16] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 7. 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. 8. IANA Considerations For the 4rd stateless address mapping to possibly coexist with a maximum of other IPv4/IPv6 address mappings, a 4rd-specific IID prefix is desirable. As explained in (Section 5.3), 200:5efe::/32 is a proposed value that avoids ambiguity with other currently permitted IID values. 9. 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. He has also been the source of explanations on the CPE- cascade use case. 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. 10. References 10.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. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for Despres, et al. Expires February 20, 2012 [Page 17] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 10.2. Informative References [I-D.despres-softwire-sam] Despres, R., "Stateless Address Mapping (SAM) - a Simplified Mesh-Softwire Model", draft-despres-softwire-sam-01 (work in progress), July 2010. [I-D.murakami-softwire-4rd] Murakami, T. and O. Troan, "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", draft-murakami-softwire-4rd-00 (work in progress), July 2011. [I-D.murakami-softwire-4v6-translation] Murakami, T., Chen, G., Deng, H., Dec, W., and S. Matsushima, "4via6 Stateless Translation", draft-murakami-softwire-4v6-translation-00 (work in progress), July 2011. [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 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 Despres, et al. Expires February 20, 2012 [Page 18] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 (ISATAP)", RFC 4214, October 2005. [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 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: jacniq@gmail.com Despres, et al. Expires February 20, 2012 [Page 19] Internet-Draft IPv4-IPv6 Stateless Address Mapping (4rd) August 2011 Simon Perreault Viagenie 2875 Laurier, suite D2-630 Quebec Canada Email: simon.perreault@viagenie.ca Xiaohong Deng France Telecom Hai dian district, 100190 Beijingc China Email: xiaohong.deng@orange-ftgroup.com Despres, et al. Expires February 20, 2012 [Page 20]