Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Standards Track October 18, 2010 Expires: April 21, 2011 IPv4 Residual Deployment across IPv6-Service networks (4rd) A NAT-less solution draft-despres-softwire-4rd-00 Abstract During the long transition period from IPv4-only to IPv6-only, networks will have not only to deploy the IPv6 service but also to maintain some IPv4 connectivity for a number of customers, and this for both outgoing and incoming connections and for both customer- individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. It applies not only to ISPs have IPv6-only routing networks, but also to those that, during early transition stages, have IPv4-only routing, with 6rd to offer the IPv6 service, those that have dual- stack routing networks but with private IPv4 addresses assigned to customers. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4 which achieve better IPv4-address sharing ratios (but at a price of significantly higher operational complexity). 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 April 21, 2011. Copyright Notice Despres Expires April 21, 2011 [Page 1] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 Copyright (c) 2010 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The 4rd Protocol Specification . . . . . . . . . . . . . . . . 8 4.1. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Packet Encapsulations/Decapsulations . . . . . . . . . . . 9 4.3. Port sets of IPv4r prefixes longer than /32 . . . . . . . 10 4.4. PMTU Considerations . . . . . . . . . . . . . . . . . . . 12 4.5. Parameter Acquisitions by 4rd Clients . . . . . . . . . . 12 5. Example with IPv6-only Routing and Shared IPv4 Addresses . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Despres Expires April 21, 2011 [Page 2] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 1. Introduction During the long transition period from only IPv4 to IPv6, networks of Internet Service providers (ISPs) will have not only to offer IPv6 connectivity but also, for some customers, to maintain a residual IPv4 connectivity. Both outgoing and incoming connections will have to be supported. While some privileged customers will still have individual IPv4 addresses of their own, more and more others with only have shared IPv4 addresses. All ISP routing networks will eventually be IPv6-only but, in earlier phases, some deployments of the IPv6 service can be done on ISP routing networks that only route private IPv4 of [RFC1918], the IPv6 service being offered by means of 6rd. Some others will route both IPv6 and private IPv4. 4rd is a solution for the residual support of global IPv4 connectivity across routing networks that are IPv6-only, private- IPv4-only, or IPv6-and-private-IPv4. Depending on ISP constraints and policies, 4rd can be used across IPv6-only networks either alone, no NAT being then needed in ISP infrastructures, or in parallel with NAT based solutions that, at a price of more operational complexity, achieve better address sharing ratios such as [DS-lite] and [NAT64]/[DNS64]. This proposal is a more detailed version of what was initially described in section 3.2 of the more general Stateless Address Mapping proposal of [1]) (SAM). At the time of writing, 4 ISPs in Japan have expressed interest for the SAM/4rd solution to offer IPv4 connectivity across IPv6-only routing networks (www.ietf.org/mail-archive/web/v6ops/current/ msg05247). Despres Expires April 21, 2011 [Page 3] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 2. Definitions Locator: in a given address family, an address or a routable prefix. IPv4r Address Family: the "residual IPv4" address family, that of IPv4r locators. IPv4r Address: Either a global IPv4 address or the combination of a global IPv4 address and a port (an A+P address) IPv4r prefix: Either a global IPv4 prefix (up to /32), or a global IPv4 address followed by a port-set identifier whose length is from 1 to 15. IPv4p Address Family: That of a private address spaces of (10/8, 172.16/12, or 192.16/16, prefixes). interior address family: in a tunnel-supporting network, the address family of encapsulating packets (in 4rd, IPv6 or IPv4p). exterior address family: in a tunnel-supporting network, the address family of encapsulated packets (in 4rd, IPv4r). 4rd parent network: For a given 4rd network, the network that assigns to it one or several IPv4r prefixes. 4rd network: A network whose interior address family is different from global IPv4, and that supports one or several 4rd servers at its border with its 4rd parent network. 4rd server (4rd-S): A function at a border point between a 4rd network and its 4rd parent network. Via automatic tunnels, it statically shares among customers of the 4rd network IPv4r locators that have been received from the parent network. 4rd client (4rd-C): A function that obtains mapping rules from a 4rd server, derives from them its own IPv4r locator, and tunnels IPv4r packets across its 4rd network. 4rd BR: A router that supports one or several 4rd servers (Border Router). 4rd CE: A node supports a 4rd client and is in a customer position on a 4rd network. It may be a host, a router, or both. Despres Expires April 21, 2011 [Page 4] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 network PMTU: For an identified address family, the packet size that must not be exceed to traverse the network without risk of packets being discarded (in IPv6) or fragmented (in IPv4). 3. Applicability For 4rd to actually be used across a network, the network must be a 4rd network, and must have at least one 4rd CE. 4rd CE 4rd NETWORK ---------------------+ \ .-----. | \/ \ IPv6 +-----+ / \ IPv6 <--------------=4rd-C=---= IPv6-only =--------------------> +--.--+ \ routing / | | /\ /\ IPv4r | | / '-----' \ +-----+ <-----------------O | \IPv6 +-----+| IPv4r | | '----+4rd-S+-------> . | +-----+ IPv4p +-----+ / | 4rd BR(s) <------+NAT44+--' | +-----+ | ---------------------+ 4rd ACROSS AN IPv6-ONLY ROUTING NETWORK Figure 1 If the interior address family is IPv4p, the operator of must know the PMTU of its 4rd network. Figure 1 shows a scenario where the interior address family is IPv6. In the CE, the IPv4r interface of the 4rd client can be used to provide global IPv4 addresses and reserved ports to a socket API and/or to a NAT44. This NAT can use them for its port-forwarding function, be it configured administratively or by means of UPnP or NAT-PMP. If both a socket API and a NAT44 share the set of available addresses and ports, a static switch can do split. Despres Expires April 21, 2011 [Page 5] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 This scenario doesn't exclude other ways to offer IPv4 connectivity across the same IPv6-only routing network (typically DS-lite and/or NAT64/DNS64). Note however that, with each IPv4 address shared between 16 customers, each customer obtains with 4rd 3840 global-IPv4 ports (in addition to its 65 536 ports per IPv6 address), and the available IPv4 address space is multiplied by 16. Since most port- consuming applications should quickly be reachable in IPv6 (Google Maps in particular is already in this case) this should be largely sufficient in many scenarios. Figure 2 shows a scenario where the interior address family is IPv4p and where the IPv6 service is supported with 6rd. The 4rd CE architecture is similar to that of the previous example with two differences: IPv6, instead to be directly available at the network interface, is obtained by means of a 6rd-CE function; the NAT44, if present, can use as external addresses not only those of its IPv4r locator but also the IPv4 address assigned to the CE in the 4rd network. How the NAT44 uses this external address set is an implementation matter, but it can be noted that applications that are known to traverse cascades of NATs without problem (Web, DNS, and Mail, in particular) can use IPv4p addresses. IPv4r addresses are thus kept for IPv4 connections that may need end-to-end transparency. 4rd CE +-----+ -----------------------------+ IPv4p | | IPv6 | .-----+ 6rd +-------> IPv6 | 4rd NETWORK / | BR | <-----------------. | / +-----+ \ | \ .------. / +-----+ +--'--+-----+ \/ \/ +-----+ | | | | | / \ IPv4p | | IPv4r <-----+NAT44+----= 6rd =4rd-C=--= IPv4p-only =--------+NAT44+--------> IPv4p | |\ | CE | | \ routing / | | or IPv4p +-----= \ +-----+--.--+ /\ /\ +-----+ \ / | / '------' \ <---------------O-------' | \ +-----+ IPv4r | \ IPv4p +-----+| IPv4r | '------+4rd-S+-------> -----------------------------+ +-----+ 4rd BR(s) 4rd ACROSS AN IPv4p-ONLY ROUTING NETWORK Figure 2 Despres Expires April 21, 2011 [Page 6] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 Figure 3 shows a scenario where both IPv6 and IPv4p are routed. The main difference with the IPv4p-only routing case is that 6rd is not needed. Tunnels for IPv4r packets can use IPv6 or IPv4p depending on local policies. 4rd CE -----------------------------+ IPv6 | .------------------> IPv6 | 4rd NETWORK / <-----------------. | / \ | \ .------. / +-----+ \ +-----+ \/ \/ +-----+ | | IPv4p \ | | / Ipv6 \ IPv4p | | IPv4r <-----+NAT44+---------'=4rd-C=--= and Ipv4p =--------+NAT44+--------> IPv4p | |\ | | \ routing / | | or IPv4p +-----= \ +--.--+ /\ /\ +-----+ \ / | / '------' \ IPv4p <---------------O-------' | \ or +-----+ IPv4r | \ IPv6 +-----+| IPv4p | '------+4rd-S+-------> -----------------------------+ +-----+ 4rd BR(s) 4rd ACROSS A DUAL-STACK ROUTING NETWORK Figure 3 NOTE: The above scenarios can apply not only to 4rd networks operated to ISPs but also to private networks. A CPE that supports a 4rd server can, when it has an IPv4r locator, share it among hosts of its site that support 4rd clients. This is in practice a static alternative to UPnP and NAT-PMP for hosts to still have some IPv4 incoming connectivity. Despres Expires April 21, 2011 [Page 7] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 4. The 4rd Protocol Specification 4.1. Mapping Rules 4rd mapping rules establish 1:1 mappings between interior and exterior locators. Each rule Ri comprises: Di : the "rule exterior prefix" Pi : the "rule interior prefix" xi : the "index length", i.e. the length of the field X that, for a given 4rd client is common to its interior and exterior locators. Di's of all rules of a 4rd network must be non overlapping prefixes, and the same for Pi's. 4rd NETWORK IPv6 or IPv4p interior routing Mapping rules: Ri = {Di, Pi, xi}, i=1,2,... +----------------------+ ----| | 4rd BRs 4rd CE | | +-------+ +-------+ | Interior locator | +-------+| | | | I=Pi.X /pi+xi G | | || IPv4r <--------= 4rd-C =----+<--- ---->+--+ 4rd-S +<--------- | | | | | |+ D1,D2,... +---+---+ | | +-------+ / | | <----------' ----| | IPv4r locator +----------------------+ E=Di.X /di+xi G: 4rd border anycast address 4rd LOCATOR MAPPING RULES Figure 4 Figure 4 shows how the exterior locator "E" of a 4rd client is derived from its interior locator "I". E comprises the Di of the rule whose Pi is recognized at the beginning of I, followed by index X whose length is the xi of the rule, and which is copied from the I after the its Pi. In this document field acronyms are uppercase, and lengths of fields are the same letters in lower case. (Thus, Despres Expires April 21, 2011 [Page 8] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 "/pi.xi" represents a locator length that is the sum of Pi's length and xi). To derive an interior address from an exterior address, the reverse logic is used. In this document, Y... represents any address that starts with prefix Y. The interior locator I derived from exterior address E... then comprises the Pi of the rule whose Di matches the beginning of E..., followed by index X whose length is the xi of the rule and which is copied from E... after its bits used to match Di. If the obtained I is shorter than a complete interior address, it is completed with zeroes. If no rule applies (no Di found in E), the interior locator is the 4rd-server interior address G (an anycast address). 4.2. Packet Encapsulations/Decapsulations Mapping rules: Ri = {Di, Pi, xi}, i=1,2,... PACKET iSRC = (Pi.X /pi+xi).0 /g iDST = G 4rd CE iPRO = "SAM" 4rd BR(s) +-------+ eSRC = E... +-------+ | | eDST = not any (Dj...) | | <----+---]---+------------<->-----------+---[---+----> | | | | E = Di.X /di+xi | | I=Pi.X /pi+xi G | |D1,D2,... <---------------| 4rd-C |<------------- --->| 4rd-S |<------- | | +-------+ | | PACKET | | iSRC = I.0 /g | | iDST = Pj.(eDST-Match(Dj) /xj).0 /g | | iPRO = "SAM" | | eSRC = E... | | eDST = Dj... <----+---]---+------<->-------. | | \ +-------+ \ / other 4rd CEs / <-------<-------' 4rd PACKET ENCAPSULATIONS AND ADDRESS MAPPINGS Figure 5 Despres Expires April 21, 2011 [Page 9] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 When a 4rd client or server receives a packet at its IPv4r interface (a pseudo interface in the client case), it checks the validity of its source and destination addresses. It also checks that the packet size is acceptable (see Section 4.4). If yes, it encapsulates it in an interior packet and forwards it via its interior interface. The Next-header field, if interior addresses are IPv6, of the Protocol field if they are IPv4p, a value to be assigned by IANA for 4rd and for other applications of the SAM of [1] (SAM). A specific value for SAM is preferred to a re-use of Protocol 41, used for IP- in-IP encapsulations of 6to4, ISATAP, and 6rd, because this ensures that coexistence with these without risk of incompatibility. Symmetrically, a 4rd client or 4rd server that receives a packet at its interior interface checks the validity of source and destination addresses in both its encapsulating and encapsulated packets. It also checks that they are mutually consistent with mapping rules of the 4rd network. If yes it decapsulates the IPv4r packet contained in the encapsulating packet, and forwards it its IPv6 interface. Details on which addresses are acceptable in which packets are detailed in Figure 5, where SRC and DST respectively mean source and destination, PRO means protocol, where iXXX and eXXX respectively refer to interior and exterior address families. 4.3. Port sets of IPv4r prefixes longer than /32 The port-set identifiers S of an IPv4r prefix of length s in the range 33 to 47 consists in the s-32 bits beyond the first 32. The port set it identifies is specified with the following constraints: "Exclusiveness" Port sets of two S's must be disjoint if the S's are non overlapping prefixes (10 and 1011 do overlap while 10 and 1110 don't) "No administration" The port set of S must be algorithmically derived from S without depending on any parameter. "Fairness-1" Port sets of two S's of same lengths must contain the same number of ports. "Fairness-2" No port-set may contain any port 0 to 4095 (these have more value than others in OS's, and are normally not used in dynamic port assignments to applications). Despres Expires April 21, 2011 [Page 10] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 "Exhaustiveness" All ports other than 0-4095 must be assignable. Figure 6 shows the relationship between port set identifiers and port sets. Each port set is composed of up to 4 port ranges, each one being defined by its port prefix PPk. <-------- IPv4r prefix /33 to /47 ----------> | | <----------- IPv4 address -----------><- S -> | Port-set identifier Port prefixes of the the port set identified by S: PP1 1<- S -> PP2 01<- S -> (only if s < 15) PP3 001<- S -> (only if s < s14) PP4 0001<- S -> (only if s < s13) s < 13 => 2^(16-s)*15/16 ports s = 13 => 7 ports s = 14 => 3 ports s = 15 => 1 port <----- IPv4r address matching a IPv4r prefix > /32 -----> | | <-------------------- 32 bits -------><---- 16 bits ----> | | | <-------- global IPv4 address ------->< PPk >< any bits > PORT SETS OF IPv4r PREFIXES THAT EXCEED 32 BITS Figure 6 Note that, due to the above constraints on port sets, a 48-bits IPv4r address that matches an IPv4r prefix Di longer than /32 doesn't start with the complete Di. Its port number (bits 32 to 48 of the IPv4r address) rather starts with one of the PPk prefixes of the set identified by the S contained in bits 32 to s-1 of Di. Despres Expires April 21, 2011 [Page 11] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 4.4. PMTU Considerations To properly deal with large size IPv4 datagrams that are fragmented before entering a 4rd network, precautions have to be taken because: o In IPv4, intermediate nodes may have to forward packets that are longer than the MTU of next links to be traversed. For this, they fragment packets within the network. o In IPv6, such packets are discarded, with ICMP Packet Too Big ICMPv6 error packets returned to sources, but with all IPv6 links having to support MTUs of at least 1280 octets. To cope with these constraints, 4rd clients and 4rd servers can reassemble multi-fragment IPv4 datagrams before processing them. (This function is stateful at the IP layer like the same function in NATs. But at the transport layer, 4rd remains stateless whereas NATs are stateful, a source of operational complexity that is avoided with 4rd.) Each datagram, after fragment reassembly if needed, is forwarded either in a single packet, if with its encapsulation header it fits in the network PMTU, or in as many packets as needed for each one to fit in this PMTU. Optimized treatments are possible, whereby first parts of datagrams are forwarded without waiting for complete datagram reassembly, but this is an implementation matter that doesn't belong to the scope of this specification.) 4.5. Parameter Acquisitions by 4rd Clients The 4rd-server address G may be obtained in various ways. It may be administratively configured (typically applicable if the 4rd network operator provides its own 4rd CEs). It can also be obtained in DHCP [RFC2131], DHCPv6 [RFC3315], Radius [RFC2865], or Diameter [RFC3588]. For these, IANA assigned numbers for 4rd remain to be chosen. In absence of all these means, G can be taken as the well-known address of SAM servers in the applicable interior address family (also to be assigned by IANA). If a 4rd client has Gs for both IPv6 and IPv4p, it may try both and settle for either one from which it obtains responses. To obtain its mapping rules and their common lifetime, a 4rd client sends a 4rd "Parameter Request" message to the 4rd-server anycast address G. It retransmits it until it obtains an answer, typically with longer time intervals after several unsuccessful attempts. When it receives a 4rd "Parameter Indication" message with the 4rd-server anycast address as source, it derives from the contained mapping Despres Expires April 21, 2011 [Page 12] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 rules its own IPv4r locator. It also stores these rules for its future packet encapsulations/decapsulations. 4rd messages are transmitted in payloads of 4rd interior packets at the same place as encapsulated exterior packets. Their first octet is set to 0, a "Message Mark" which permits to distinguish 4rd messages from encapsulated packets (IPv4 packet headers all start with a 4 in the first 4 bits). +-----------+--- ... ---+-- --+--- ... ---+-- ... --+ | msg mark | | | | | | (= 0) | rule 1 | ... | rule n |lifetime | +-----------+--- ... ---+-- --+--- ... ---+---------+ 1 octet | \______________ parameter | \ +-- ... --+-- ... --+---...--+ | D1 | P1 | x1 | +-- ...---+-- ... --+---...--+ parameter parameter parameter <--------- L octets ----------> +------+------+------+-- ... --+------+ Parameter Format: | Type | L | Value | +--|---+------+------+-- ... --+------+ v ---- 0x1F : xi (L = 2) 0x2F : Lifetime (L = 3) 0x4n : IPv4 prefix (L = 2 to 5) 0x6n : IPv6 prefix (L = 2 to 9) | n = number of useful bits in the last octet FORMAT OF 4rd PARAMETER INDICATIONS Figure 7 A 4rd Parameter Request is sent with no information after the 4rd Message Mark. In order to facilitate future extensions that may prove useful, 4rd servers should ignore octets that may be received after this mark. Despres Expires April 21, 2011 [Page 13] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 After the Message Mark, a 4rd Parameter Indication contains one or several rules, followed by a lifetime expressed in seconds. Each rule starts with its rule exterior prefix Di, followed by its rule interior prefix Pi, followed by its index length xi. Detailed formats are shown on Figure 7. 5. Example with IPv6-only Routing and Shared IPv4 Addresses With the protocol of Section 4, each public network operator and each private network administrator can make its own parameter choices. +--------------------------+ | IPv6-ONLY ROUTING | | | | * Common prefix K/24 | | * Assigned prefixes /48 | CUSTOMER SITES | => 2^24 customers | (3840 ports each) | | | | | IPv4 v | G /128 --->O<---- ==================+ | D1/13 | <----O<--- I1=(P1=K.C1).X /48 | D2/14 |2^20 addresses /| | D3/14 | E1=D1.X /36 <--' | | x=23 | | ==================+ | <----O<--- I2=(P2=K.C2).X /48 | /| | E2=D2.X /36 <--' | | x=22 | | ==================+ | <----O<--- I3=(P3=K.C3).X /48 | /| | E3=D3.X /36 <--' | | x=22 | | ==================+ | +--------------------------+ Rules: {D1/13, P1=K.C1/25, x1=23} with C1=0b0 {D2/14, P2=K.C2/26, x2=22} with C1=0b10 Rules: {D3/14, P3=K.C3/25, x3=23} with C1=0b11 4rd EXAMPLE ON AN IPv6-ONLY-ROUTING NETWORK Figure 8 Despres Expires April 21, 2011 [Page 14] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 The following example illustrates the case of an ISP that operates an IPv6-only routing network and assigns shared global IPv4 addresses to its customers. The ISP has 2^24 customers whose /48 prefixes start with a common prefix K/24. In IPv4, it has three global IPv4 prefixes, R1/13, R2/14, R3/14, giving a total of 2^20 addresses. Each of these addresses must therefore be shared among 16 customers. Exterior locators E must therefore be /36s, comprising port-set identifiers S having 4 bits (each customer is thus assigned 2^12*15/ 6=3840 reserved ports in global IPv4). Each interior prefix I/48 must then be composed of the common prefix K followed by the short identifier Ci of one of the three Di's. Their lengths have to be related to lengths of Di's by the formula ci=(i-k)-(e-di), which gives c1=1, c2=2, and c3=2. Within these constraints, bit values of the Ci's may be arbitrary non overlapping prefixes, e.g. C1 = 0bO, C2=0b10, C3 =0b11 (with 0bXXX being the binary number XXX). Rule are {D1/ VARIANTS: o It the ISP would have preferred to have only one rule, this would have been possible by using in IPv4 only the /13. Then port-set identifiers S would have had 5 bits, and each customer would have had 1920 ports in global IPv4. o If instead of one K/24, the ISP there would have had to use two different prefixes, K1/25 and K2/25, mapping rules could have been {D1/13, P1=K1/25, x1=23}, {D2/14, P2=K2.C2/26, x2=22}, and {D3/14, P3=K2.C2/26, x3=22}, with C2=0b0 and C3=0b1. o If, in a more complex scenario, the ratio between number of customers and number of IPv4 addresses would not have been a power of two, either some interior addresses or some exterior addresses would have had to be sacrificed (not assigned). For example, with K1/25, K2/26, and D1/14, D2/15, D3/15, D4/15, giving 2^23+2^22 customers and 2^19+2^15 IPv4 addresses, rules could have been {D1/14, P1=K1.C1/26, x1=22}, {D2/15, P2=K1.C2/27, x2=21}, {D3/15, P3=K1.C3/27, x3=21}, {D4/15, P4=K2.C4, x4=21}, with C1=0b0, C2=0b10, C3=0b11, C4=0. Despres Expires April 21, 2011 [Page 15] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 6. Security considerations Spoofing attacks With address-consistency checks of Section 4.2, authentication verifications that apply interior locators also apply, indirectly, to exterior locators. Similarly, anti-spoofing protections that apply to interior addresses also apply, indirectly, to exterior locators. 4rd should therefore introduce no opportunity of its own for spoofing attacks. Denial-of-service attacks Reassembly of fragmented exterior datagrams introduces an opportunity for some form of DOS attacks, shared with NAT-based solutions. Note that this risk among reason to prefer native IPv6 to native IPv4 when there is the choice for a transport connection. Risks of DOS attacks at the transport-connection layer, to which NAT-based solutions are exposed, are avoided in 4rd because of its the stateless operation of this layer. Faked 4rd servers If a 4rd CE uses as 4rd server address one of the two IANA assigned well-known address for this in IPv6 and IPv4, and if its ISP network has no 4rd server, packets addressed to it can be forwarded to the Internet backbone. They should however not reach any faked 4rd server because, this address starting with none of prefixes routed to other ISP networks, they will normally be discarded in the backbone. However, whether some additional protection in would be appropriate against fake 4rd servers (e.g. with a nonce in Parameter Requests and Parameter Indications), is still viewed as an open issue. Routing-loop attacks Routing-loop attacks that may exist in some automatic-tunneling scenarios are documented in [3]. They cannot exist with 4rd because its address checks of Section 4.2 prevent multiple traversals of a 4rd network by the same IPv4r packet, and because, 4rd using its own Protocol number, routing-loops between nodes of nodes working with two different tunnel protocols are also impossible. Despres Expires April 21, 2011 [Page 16] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 7. IANA Considerations This specification depends on the following number assignments by IANA: o The SAM protocol number (Section 4.2) o The DHCP and DHCPv6 4rd option codes (Section 4.5) o The Radius 4rd attribute type (Section 4.5) o The SAM-server well-known addresses, in IPv4 and IPv6 (Section 4.5) 8. Acknowledgments The author has benefited from useful informal discussions with a number of IETF participants on previous SAM proposals, from which this specification is a by-product. Concerning 4rd in particular, Satoru Matsushima deserves special recognition, first for the interest in the approach he expressed from the beginning, but also for his constructive contributions, including his proposal of the 4rd acronym, and for convincing his colleagues to make actual deployment plans with this technology. Olivier Vautrin, by independently proposing the same acronym for a similar orientation, has to be thanked for the valuable encouragement this has been. 9. References 9.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [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. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., Despres Expires April 21, 2011 [Page 17] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 9.2. Informative References [1] Despres, R., "Stateless Address Mapping (SAM) - a Simplified Mesh-Softwire Model - draft-despres-softwire-sam-01 - work in progress", July 2010. [2] Vautrin, O., "IPv4 Rapid Deployment on IPv6 Infrastructures (4rd) - draft-vautrin-softwire-4rd-00 - work in progress", July 2010. [3] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations - draft-ietf-v6ops-tunnel-loops-00 - Work in progress", September 2010. [DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-dns64 - work in progress]", October 2010. [DS-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion [draft-ietf-softwire-dual-stack-lite - work in progress]", August 2010. [NAT64] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 - Clients to IPv4 Servers [draft-ietf-behave-v6v4-xlate-stateful - work in progress]", July 2010. Despres Expires April 21, 2011 [Page 18] Internet-Draft IPv4 Residual Deployment(4rd) October 2010 Author's Address Remi Despres RD-IPtech 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Despres Expires April 21, 2011 [Page 19]