Internet Engineering Task Force R. Despres, Ed. Internet-Draft RD-IPtech Intended status: Standards Track S. Matsushima Expires: September 8, 2011 SoftBank T. Murakami IP Infusion O. Troan Cisco March 7, 2011 IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional draft-despres-intarea-4rd-00 Abstract This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network infrastructure. During the long transition period from IPv4-only to IPv6-only, a service provider's network infrastructure will have to deploy IPv6. But it will also have to maintain some IPv4 connectivity for a number of customers, 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. 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. 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 September 8, 2011. Despres, et al. Expires September 8, 2011 [Page 1] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal 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. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. From an IPv6 Prefix to a 4rd Prefix . . . . . . . . . . . 5 4.2. From a 4rd Prefix longer than 32 bits to a Port-set ID . . 6 4.3. From a Port-Set ID to a Port Set . . . . . . . . . . . . . 6 4.4. From an IPv4 Address or IPv4 address + Port to a CE IPv6 address . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. MTU Considerations . . . . . . . . . . . . . . . . . . . . 9 5. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 9 6. BR and CE behaviors . . . . . . . . . . . . . . . . . . . . . 10 6.1. Encapsulation and IPv6 Fragmentations . . . . . . . . . . 10 6.2. Domains having only One Mapping rule . . . . . . . . . . . 11 6.2.1. BR reception of an IPv4 packet . . . . . . . . . . . . 11 6.2.2. BR reception of an IPv4/IPv6 packet . . . . . . . . . 12 6.2.3. CE reception of an IPv4 packet . . . . . . . . . . . . 12 6.2.4. CE reception of an IPv4/IPv6 packet . . . . . . . . . 13 6.3. Domains having Multiple Mapping Rules (TBD) . . . . . . . 13 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Despres, et al. Expires September 8, 2011 [Page 2] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 1. Introduction During the long transition period from only IPv4-only to IPv6-only, Internet-service providers (ISP's), will sooner or later deploy networks where routing is IPv6-only. Some of them will do so while they still have to offer residual IPv4 connectivity for the service to remain dual-stack. While this connectivity may be offered to privileged customers with in exclusive global addresses, more and more other customers will only have shared IPv4 addresses. In this document, "ISP" is used as a generic term. It includes DSL or Broadband service providers, mobile operators, and private operators of networks of any sizes. 4rd (IPv4 Residual Deployment) is a generic lightweight solution for the residual support of global IPv4 connectivity across IPv6-only routing networks. As such, it is the reverse of 6rd (IPv6 Rapid Deployment) whose purpose is to rapidly introduce native IPv6 connectivity across IPv4-only routing infrastructures. It applies the same principles of automatic tunneling, an stateless address mappings between IPv4 and IPv6. On the tradeoff scale between efficiency of address sharing ratios and simplicity, 4rd is on the side of design and operational simplicity. Depending on ISP constraints and policies, 4rd can be used either alone, with no NAT needed in ISP infrastructures, or in parallel with NAT based solutions such as DS-lite [I-D.ietf-softwire-dual-stack-lite] and NAT64/DNS64 [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-dns64]. At the time of writing, four ISP's in Japan have expressed interest for deploying 4rd (www.ietf.org/mail-archive/web/v6ops/current/ msg05247). This draft is still in an early stage. So far, it specifies details only for domains that have one mapping rule. In order to permit more flexible services, a next version is being worked on to deal with multiple mapping rules. 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 September 8, 2011 [Page 3] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 3. Terminology 4rd domain (Domain): an IPv6 routing network operated by an ISP and comprising one or several 4rd relays operating with the same set of parameters. It offers to its 4rd-capable customers global IPv4 connectivity, both outgoing and incoming, and with exclusive or shared IPv4 addresses. 4rd Border Relay (BR): A 4rd-enabled router managed by the service provider at the edge of 4rd domain. A BR has an IPv6-enabled interface connected to the ISP routing network, and an IPv4 virtual interface acting as an endpoint for the automatic 4rd tunnel. This tunnel (IPv4 in IPv6) is between the BR and all CE's of the Domain. 4rd Customer Edge (CE): A node at the border between a customer infrastructure and the 4rd domain. This node has an IPv6 interface connected to the ISP routing network, and a virtual IPv4 interface acting as the end-point of the automatic 4rd tunnel. This tunnel (IPv4 in IPv6) is between the CE and all other CE's and all BR's of the Domain. It may be a host, a router, or both. CE IPv6 prefix: The IPv6 prefix assigned to a CE independently from 4rd. CE IPv6 address: In the context of 6rd, the IPv6 address used to reach a CE from other CE's and from BR's. A CE typically has another IPv6 address, assigned to it at its IPv6 interface without relationship with 6rd. CE 4rd prefix: The 4rd prefix of the CE. It is derived from the CE IPv6 prefix by a mapping rule according to Section 4. Depending on its length, it is an IPv4 prefix, an IPv4 address, or a shared IPv4 address followed by a Port-set ID (Section 4.2). Port-set ID: In a CE 4rd prefix longer than 32 bits, bits that follow the first 32. It identifies a set of ports exclusively assigned to the CE. As specified in Section 4.3, the set contains up to 4 port ranges, each range being defined by its port prefix. Despres, et al. Expires September 8, 2011 [Page 4] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 Domain IPv6 prefix: An IPv6 prefix assigned by an ISP to a 4rd domain. Domain 4rd prefix: A 4rd prefix assigned by an ISP to the 4rd domain. In typical operator applications, it is an IPv4 prefix. In a residential site in which an already shared IPv4 address has to be shared even more among several hosts, it may have more than 32 bits. CE index: In a CE IPv6 prefix, all bits that follow the Domain IPv6 prefix. It is also, in a CE IPv4 prefix, all bits that follow the BR IPv4 prefix. 4. Mapping Rules 4.1. From an IPv6 Prefix to a 4rd Prefix A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes and CE 4rd prefixes. <---------------- CE IPv6 prefix (max 64) --------------> +-------------------------------+------------------------+ | Domain IPv6 prefix | CE index | +-------------------------------+------------------------+ <-- Domain IPv6 Prefix length -><--- CE index length --->: : : : || : : \/ : : : <--- CE index length --->: +-------------------+------------------------+ | Domain 4rd prefix | CE index | +-------------------+------------------------+ <----------- CE 4rd prefix (max 47) --------> Figure 1: From an IPv6 Prefix to a 4rd Prefix A CE derives its CE 4rd prefix from the IPv6 prefix it has been delegated on the IPv6-routing network, using for this parameters of the applicable mapping rule. If the domain has several mapping rules, that which applies is that whose Domain IPv6 prefix is at the beginning of the CE IPv6 prefix. As shown in Figure 1, the CE 4rd prefix is made of the Domain 4rd prefix followed by the CE index, where the CE index is the remainder of the CE IPv6 prefix after the Despres, et al. Expires September 8, 2011 [Page 5] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 Domain IPv6 prefix (the length of the Domain IPv6 prefix is defined by the mapping rule). 4.2. From a 4rd Prefix longer than 32 bits to a Port-set ID Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a full IPv4 address, or a shared IPv4 address followed by a Port-set ID (Figure 2). If it includes a port set ID, this ID specifies which ports are assigned to the the CE for its exclusive use. This set, composed of up to 4 port ranges, is algorithmically derived from the Port-set ID (see Section 4.3). <-- CE 4rd prefix length --> +--------------------------+- - -+ Shorter than 32 bits | IPv4 prefix | ... | + -------------------------+- - -+ <----- CE 4rd prefix length -----> +--------------------------------+ 32 bits | IPv4 address | +--------------------------------+ <--------------- 32 -------------> <----------- CE 4rd prefix length ----------> +-------------------------------+-----------+ 33 to 47 bits | IPv4 shared address |Port-set ID| +-------------------------------+-----------+ <--------------- 32 -----------><- max 15 --> Figure 2: Variants of CE 4rd prefixes 4.3. From a Port-Set ID to a Port Set Each value of a Port-set ID specifies which ports can be used by any protocol whose header format starts with source and destination ports (UDP, TCP, SCTP, etc.). Design constraint of the algorithm are the following: "Fairness with respect to special-value ports" No port-set must contain any port from 0 to 4095. (These ports, which have more value than others in OS's, are normally not used in dynamic port assignments to applications). Despres, et al. Expires September 8, 2011 [Page 6] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 "Fairness with respect to the number of ports" For a Port-set-ID's having the same length, all sets must have the same number of ports. "Exhaustiveness" For a any Port-set-ID length, the aggregate of port sets assigned for all values must include all ordinary-value ports (from 4,096 to 16,384). If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges. As shown in Figure 3, each port range is defined by its port prefix, made of a range-specific "head" followed by the Port-set ID. Head values are in binary 1, 01, 001, and 0001. They are chosen to exclude ports 0-4095 and only them. <------- Port (16 bits) --------> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-range a |1|x x x x x x x x| | 0xF780 - 0xF7FF (head = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-range b |0 1|x x x x x x x x| | 0x7BC0 - 0x7BFF (head = 01) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-range c |0 0 1|x x x x x x x x| | 0x3DE0 - 0x3DFF (head = 001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port-range d |0 0 0 1|x x x x x x x x| | 0x1EF0 - 0x1EFF (head = 0001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <- head-><--Port-set ID-> /\ <-- Port-range prefix --><-tail-> || || Example of Port-ranges if the Port-set ID is 0xEF Figure 3: From Port-set ID to Port ranges In the Port-set ID has 13 bits, only the 3 port ranges are assigned, having heads 1, 01, and 001. If it has 14 bits, only the 2 port ranges having heads 1 and 01 are assigned. If it has 15 bits, only the port range having head 1 is assigned. (In these three cases, the smallest port range has only one element). Note: The port set assigned to a CE may be further subdivided by the CE among several functions such as the following: (1) an IPv4 NAPT Despres, et al. Expires September 8, 2011 [Page 7] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 (possibly configurable to do port forwarding, and possibly doing dynamic port assignments to hosts with UPnP and/or NAT-PMP); (2) an API for applications in the CE that need dynamic port assignments; (3) a new 4rd BR which assigns to its CE's subsets of its own port set. How to chose among these functions and/or combine them is beyond the scope of this specification. Readers are referred to documents dealing with operational applicability in diverse environments, e.g. [draft-sun-intarea-4rd-applicability] prepared in parallel of this one. 4.4. From an IPv4 Address or IPv4 address + Port to a CE IPv6 address Port-set ID | <--- CE 4rd prefix ---|-> +---------------+---+-|--+ |IPv4 shared address| ' | +---------------+---+----+ <--------> CE-index length : : : || : : || : : \/ : Domain IPv6 suffix : : | +------------------+--------+--|-+----------------------------------+ |Domain IPv6 prefix|CE index| ' | 0 | +------------------+--------+----+----------------------------------+ <------------ max 64 ------------> <---------------------- CE IPv6 address (128) ---------------------> Figure 4: From a CE 4rd Prefix to the CE IPv6 address In order to find whether a CE IPv6 address can be derived from an IPv4 address, or an IPv6 address + a port, a mapping rule has to be found that matches the IPv4 information: o If a mapping rule has a length L of CE IPv4 prefixes which does not exceed 32 bits, there is a match if the IPv4 address starts with the Domain 4rd prefix. The CE 4rd prefix is then the first L bits of the IPv4 address. o If a mapping rule has a length L of CE IPv4 prefixes which exceeds 32 bits, the match can only be found with the IPv4 address and the port. For this, the port is examined to determine which port- range head it starts with: 1, 01,001, or 0001. The N bits that Despres, et al. Expires September 8, 2011 [Page 8] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 follow this head are taken as Port-set ID, where N is the length of Port set ID of the mapping rule. The CE 4rd prefix is then made of the IPv4 address followed by the Port-set ID. If a match has been found, the CE IPv6 prefix is then made of the Domain IPv6 prefix followed by bits of the CE 4rd prefix that follow the Domain 4rd prefix, followed by the Domain IPv6 prefix of the mapping rule if there is one, and followed by 0's up to 128 bits to satisfy [RFC4291]. Figure 4 illustrates this process in the case of a shared IPv4 address. 4.5. MTU Considerations The maximum size of IPv4 packets that are forwarded across a 4rd domain must be the path MTU of the domain minus the 40 octets (the length of the encapsulation header). (Otherwise, due to the impossibility of intermediate IPv6 nodes to fragment packets, they might be discarded during domain traversal.) Absent more specific indication, this path MTU has to be set to 1280, the minimum size that all IPv6 networks must support. o In domains where IPv4 addresses are not shared, IPv6 destinations are derived from IPv4 addresses alone. Thus, each IPv4 packet can be encapsulated and decapsulated independently of each other. 4rd processing is completely stateless. o On the other hand, in domains where IPv4 addresses are shared, BR's and CE's can have to encapsulate IPv4 packets whose IPv6 destinations depend on destination ports. Precautions are needed, due to the fact that the destination port of a fragmented datagram is available only in its first fragment. A sufficient precaution consists in reassembling each datagram received in multiple packets, and to treat it as though it would have been received in single packet. This function is such that 4rd is in this case stateful at the IP layer. (This is common with DS-lite and NAT64/ DNS64 which, in addition, are stateful at the transport layer.) In the encapsulating direction, this permits to address all pieces of a received datagram to the right IPv6 destination. In the decapsulating direction, this permits to ensure that all pieces of received datagram do come from the right CE. 5. 4rd Configuration Both CE's and BR's have to know parameters of their 4rd domain. These include the BR IPv6 address plus, for each mapping rule, the following: Despres, et al. Expires September 8, 2011 [Page 9] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 o Domain IPv6 prefix o CE-index length or CE-IPv6-prefix length (derivable from one another) o Domain IPv6 suffix (optional - default ::/0) o Domain 4rd prefix A CE can acquire 4rd parameters of its 4rd domain in various ways. o The simplest one, which requires no protocol, can be used if the CE software is provided by the ISP and is downloadable. 4rd parameters can be included in update packages. (This case is similar to that which permitted the first 6rd deployment [RFC5569].) o Another way is based on DHCPv6 [RFC3315]. As such, it is similar to that of 6rd in [RFC5969] where CE parameters are acquired in IPv4 DHCP. How to format these parameters in a DHCPv6 option, or for other ways to advertise them to CE's has still to be specified. The design may be influenced by the following facts: (1) if the length of the Domain IPv6 prefix is known, the length of the CE index or that of the CE IPv6 prefix can be derived from one another; (2) if a single mapping rule applies to all CE's, each CE can derive the Domain IPv6 prefix from its CE IPv6 prefix by just knowing the length of this Domain IPv6 prefix; (3) sateless DHCPv6 servers are simpler to manage than stateful. o Other methods of parameter acquisition are for further study. 6. BR and CE behaviors BR's and CE's MAY have the behaviors specified in the following sections. Different behaviors are permitted, but MUST be equivalent as far as exchanged packets are concerned. 6.1. Encapsulation and IPv6 Fragmentations For 4rd domain traversal, IPv4 packets are encapsulated in IPv6 packets whose Next header is set to 4 (i.e. IPv4). If fragmentation of IPv6 packets is needed (see Section 4.5), it is performed according to [RFC2460], as shown in Figure 5. All IPv6 packets except the last one have the same length, namely the IPv6 path MTU of the Domain. Received encapsulating packets are reassembled before being processed Despres, et al. Expires September 8, 2011 [Page 10] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 according to Section 6.2.4 and Section 6.2.4. +--------------------//---------------+ | IPv4 packet | +--------------------//---------------+ : : : : +-----//----+-----//----+--//--+--//--+ | frag 1 | frag 2 | |frag n| IPv6 +-----//----+----//-----+--//--+------+ fragmentation extension : : : : : \ : : : : : |0 \|48 : : : : +----------++-----//----+ : : : | IPv6 || frag 1 | : : : +----------++-----//----+ : : : <---- IPv6 path MTU --->: : : : : : : : +----------++-----//----+ : : | IPv6 || frag 1 | : : +----------++-----//----+ : : <---- IPv6 path MTU ---> : : ... : : : : +----------++--//--+ | IPv6 ||frag n| +----------++------+ Figure 5: IPv4 packet fragmentation for Domain traversal 6.2. Domains having only One Mapping rule 6.2.1. BR reception of an IPv4 packet Step 1 When a BR receives an IPv4 packet at its IPv4 interface, its process depends on whether the length of CE 4rd prefix exceeds 32 bits. If not, the BR proceeds to the next step. If yes, there are three cases: (1) if the packet is a single- packet datagram, the BR proceeds to the next step; (2) if it is a fragment of an datagram that is still incomplete, the packet is kept for later reassembly of a complete IPv4 datagram (with a timeout protection as usual for this function); (3) if it is the last fragment that was missing to assemble a complete datagram, the BR proceeds to the next Despres, et al. Expires September 8, 2011 [Page 11] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 step with the datagram considered as received in a single packet. Step 2 The BR first checks that no CE IPv6 address can be derived per Section 4.4) from the IPv4 source. If this is the case, it derives from the IPv4 destination the IPv6 address of the destination CE from per Section 4.4). The CE then transmits the packet via its IPv6 interface, duly fragmented in IPv6 if necessary. 6.2.2. BR reception of an IPv4/IPv6 packet Step 1 When a BR receives an IPv6 packet at its IPv6 interface, with the BR IPv6 address as destination, its process depends on whether the length of CE 4rd prefix exceeds 32 bits. If not, or if the IPv4 packet is a complete datagram, the BR proceeds to the next step. If yes, there are two cases: (1) if the packet contains the last fragment that was missing to assemble a complete IPv4 datagram, the BR proceeds to the next step with the reassembled datagram as if it had been received in a single IPv4 packet; (2) otherwise, the packet is kept for later reassembly of a complete IPv4 datagram (with a timeout protection as usual for this function). Step 2 The BR checks that the IPv6 source address of the packet is not the BR IPv6 address, and is that which is derived per Section 4.4 from the IPv4 destination. If this is the case, the BR transmits the IPv4 packet via its IPv4 interface, duly fragmented in IPv4 if necessary for the link MTU. 6.2.3. CE reception of an IPv4 packet Step 1 When a CE receives an IPv4 packet at its IPv4 interface, its process depends on whether the length of CE 4rd prefix exceeds 32 bits. If not, the BR proceeds to the next step. If yes, there are three cases: (1) if the packet is a complete IPv4 datagram, the CE proceeds to the next step; (2) if it is a fragment of datagram that is still incomplete, the packet is kept for later reassembly with other fragments (with a timeout protection as usual for this function); (3) if it is the last fragment that was missing to assemble a complete datagram, the CE proceeds to the next step with the datagram considered as received in a single packet. Step 2 The CE tries to derive an IPv6 address from the IPv4 destination per Section 4.4. In case of success, this address taken as IPv6 destination of the encapsulating packet. Otherwise, it is the BR IPv6 address that is taken. Despres, et al. Expires September 8, 2011 [Page 12] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 The CE then transmits the packet via its IPv6 interface, duly fragmented in IPv6 if necessary. 6.2.4. CE reception of an IPv4/IPv6 packet Step 1 When a CE receives an IPv6 packet at its IPv6 interface, with the BR IPv6 address as destination, its process depends on whether the length of CE 4rd prefix exceeds 32 bits. If not, or if the IPv4 packet is a complete datagram, the BR proceeds to the next step. If yes, there are two cases: (1) if the packet contains the last fragment that was missing to assemble a complete IPv4 datagram, the CE proceeds to the next step with the reassembled datagram as if it had been received in a single IPv4 packet; (2) otherwise, the packet is kept for later reassembly of a complete IPv4 datagram (with a timeout protection as usual for this function). Step 2 The CE tries to derive an IPv6 address from the IPv4 source per Section 4.4. If this succeeds, it checks that the obtained address is the same as the IPv6 source address. Otherwise, it checks that the IPv6 source address is the BR IPv6 address. In case of success, the CE transmits the IPv4 packet via its IPv4 interface, duly fragmented in IPv4 if necessary for the link MTU. 6.3. Domains having Multiple Mapping Rules (TBD) 7. Security considerations Spoofing attacks With consistency checks between IPv4 and IPv6 sources that are performed on IPv4/IPv6 packets received by BR's and CE's (Section 6), 4rd does not introduce any opportunity for spoofing attack that would not pre-exist in IPv6. Denial-of-service attacks In 4rd domains where IPv4 addresses are shared, the fact that IPv4 datagram reassembly may be necessary introduces an opportunity for DOS attacks (see Section 4.5). This is inherent to address sharing, and is common with other address sharing approaches such as DS-lite and NAT64/DNS64. Despres, et al. Expires September 8, 2011 [Page 13] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 The best protection against such attacks is to accelerate IPv6 enablement in both clients and servers so that, where 4rd is supported, it is less and less used. Routing-loop attacks Routing-loop attacks that may exist in some automatic-tunneling scenarios are documented in [I-D.ietf-v6ops-tunnel-loops]. They cannot exist with 4rd because each BRs checks that the IPv6 source address of an IPv4/IPv6 packet it receives is not the 4rd-relay IPv6 address (Section 6.2.2). 8. IANA Considerations IANA is requested to assign a DHCPv6 option number for 4rd (Section 5). 9. Acknowledgments The authors wish to thank Mark Townsley for his active encouragements to pursue the 4rd approach since it was first introduced in [I-D.despres-softwire-sam]. Olivier Vautrin, who independently proposed a similar approach with the same acronym deserves special recognition. Particular gratitude is due to decision makers of the Japan ISP's that have announced actual 4rd deployment projects (see Section 1). 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 IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Despres, et al. Expires September 8, 2011 [Page 14] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 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.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-11 (work in progress), October 2010. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work in progress), March 2011. [I-D.ietf-v6ops-tunnel-loops] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", draft-ietf-v6ops-tunnel-loops-03 (work in progress), February 2011. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. Despres, et al. Expires September 8, 2011 [Page 15] Internet-Draft IPv4 Residual Deployment(4rd) March 2011 Authors' Addresses Remi Despres (editor) RD-IPtech 3 rue du President Wilson Levallois, France Email: remi.despres@free.fr Satoru Matsushima SoftBank 1-9-1 Higashi-Shinbashi, Munato-ku Tokyo Japan Email: satoru.matsushima@tm.softbank.co.jp Tetsuya Murakami IP Infusion 1188 East Arques Avenue Sunnyvale USA Email: tetsuya@ipinfusion.com Ole Troan Cisco Bergen, Norway France Email: ot@cisco.com Despres, et al. Expires September 8, 2011 [Page 16]