Network Working Group Y. Cui Internet-Draft J. Wu Intended status: Standards Track P. Wu Expires: April 28, 2011 Tsinghua University C. Metz Cisco Systems, Inc. O. Vautrin A. Durand Juniper Networks Y. Lee Comcast October 25, 2010 4over6 Access for IPv4 provisioning in IPv6 network draft-cui-softwire-host-4over6-02 Abstract This draft proposes a mechanism for bidirectional IPv4 communication between IPv4 Internet and hosts or IPv4 networks sited in IPv6 access networks. This mechanism follows the softwire hub & spoke model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. By allocating global IPv4 addresses to end hosts/networks in IPv6, it can achieve IPv4 end-to-end bidirectional communication between IPv4 Internet and these hosts/networks. This mechanism is an IPv4 access method for hosts and IPv4 networks sited in IPv6. 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 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Cui, et al. Expires April 28, 2011 [Page 1] Internet-Draft 4over6 Access October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Cui, et al. Expires April 28, 2011 [Page 2] Internet-Draft 4over6 Access October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Deployment scenario . . . . . . . . . . . . . . . . . . . . . 7 4.1. Scenario description . . . . . . . . . . . . . . . . . . . 7 4.2. Communication requirements . . . . . . . . . . . . . . . . 7 5. Stateless 4over6 Access . . . . . . . . . . . . . . . . . . . 9 5.1. Address allocation and routing . . . . . . . . . . . . . . 9 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 9 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 10 6. Stateful 4over6 Access . . . . . . . . . . . . . . . . . . . . 12 6.1. Address allocation . . . . . . . . . . . . . . . . . . . . 12 6.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 12 6.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 13 6.4. Mapping maintaining methods other than DHCP snooping . . . 14 7. Combination with Dual-Stack Lite . . . . . . . . . . . . . . . 16 7.1. Combination in the CPE . . . . . . . . . . . . . . . . . . 16 7.2. Combination in the DHCPv6 server . . . . . . . . . . . . . 16 7.3. Combination in the concentrator . . . . . . . . . . . . . 16 8. Further Discussion . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Technical advantages of 4over6 Access . . . . . . . . . . 17 8.2. 4over6 Access for direct-connected 4over6 hosts . . . . . 17 8.3. Address configuration issue in home LAN network situation . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Cui, et al. Expires April 28, 2011 [Page 3] Internet-Draft 4over6 Access October 2010 1. Introduction Global public IPv4 addresses are running out fast. The recent simulation result by ipv4.potaroo.net says the exact exhaustion date will be in two years. Meanwhile, the demand for address allocation is still growing and may even burst in potential situations like the "Internet of Things". To satisfy the end users, operators have to push IPv6 to the front, by building IPv6 networks and providing IPv6 services. In the future, when IPv6-only network will be widely deployed, users of those networks could still need IPv4 connectivity. This is because part of Internet will stay IPv4-only for a long time, and users in IPv6-only network will probably communicate with network users sited in the IPv4-only part of Internet. This need could later decrease with the general Ipv6 adoption eventually. The IPv4 services that network operators provided to IPv6 users differs by IPv4 address. If the users can't get global IPv4 addresses (e.g., new network users join an ISP which don't have enough unused IPv4 addresses for them), they have to use private IPv4 addresses in the client side, and an IPv4-private-to-global translation is required in the carrier side, as is described in Dual- stack lite[I-D.ietf-softwire-dual-stack-lite]. Otherwise the IPv6 users can get global IPv4 addresses, they can use them for IPv4 communication, and hence translation shouldn't be involved. Then the network users and operators can avoid all the problems caused by translation, such as ALG, NAT traversal, state maintenance, etc. Note that this situation is actually quite common. There're nearly 2^32 network users who are using global IPv4 addresses or can potentially get global IPv4 addresses. Most of them will switch to IPv6 sooner or later, and will require IPv4 services for a significant period after the switching. This draft focuses on this situation, i.e., to provide IPv4 access for users in IPv6 network where IPv4 global addresses are available. Cui, et al. Expires April 28, 2011 [Page 4] Internet-Draft 4over6 Access October 2010 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]. Cui, et al. Expires April 28, 2011 [Page 5] Internet-Draft 4over6 Access October 2010 3. Terminology 4over6 Access: 4over6 Access is the technique proposed by this draft, which can support bidirectional communication between IPv4 Internet and hosts in IPv6 access network. 4over6 host: a 4over6 host refers to an end host/server/device located in IPv6 access network, which has IPv4 protocol stack and IPv4 applications running on it, and hence desires to get connected with IPv4 Internet. 4over6 host can be either directly connected to IPv6 service provider network or behind a CPE device. 4over6 initiator: 4over6 initiator is the IPv4-in-IPv6 tunnel initiator (based on the hub & spoke softwire model[RFC4925]) in 4over6 Access mechanism. It can be a dual-stack capable, direct- connected host, or a dual-stack CPE. 4over6 concentrator: 4over6 concentrator is the IPv4-in-IPv6 tunnel concentrator (based on the hub & spoke softwire model) in 4over6 Access mechanism. It's a dual-stack router which connects to both the IPv6 service provider network and IPv4 Internet. 4over6 address: 4over6 address is the address allocated to 4over6 initiator and 4over6 host for 4over6 use in stateless 4over6 Access. The initiator will get the IPv6 4over6 address while the host will get the corresponding IPv4 4over6 address. Cui, et al. Expires April 28, 2011 [Page 6] Internet-Draft 4over6 Access October 2010 4. Deployment scenario 4.1. Scenario description The general scenario of 4over6 Access is shown in Figure 1. Users in an IPv6 network take IPv6 as their native service. Some users are end hosts which face the access network of service provider directly, while others are local networks behind CPEs, such as a home LAN, an enterprise network, etc. The access network is IPv6-only rather than dual-stack, which means that ISP can't provide native IPv4 access to its users; however, it's acceptable in the carrier side that one or more routers become dual-stack and get connected to IPv4 Internet. So if network users want to connect to IPv4, these dual-stack routers will be their "entrances". +-------------------------+ | IPv6 Access Network | +------+ | +-------------+ |4over6| | | | | host |================ +-------+ | IPv4 | +------+ |4over6 |---| Internet | +-------+ | |Concen-| | | |local | +------+ |trator | | | |network|-| CPE |================ +-------+ +-------------+ +-------+ +------+ | | | +-------------------------+ Figure 1 4over6 Access scenario 4.2. Communication requirements Before getting into any technical details, the communication requirements should be stated. The first one is that, 4over6 hosts require IPv4-to-IPv4 communication with the IPv4 Internet. An IPv4 access service is needed rather than an IPv6-to-IPv4 translation service.(IPv6-to-IPv4 communication is out of the scope of this draft.) Second, end hosts of the network users require to use public IPv4 addresses rather than private addresses. Public IPv4 address means there's no IPv4 NAT along the path, so the IPv4 service the hosts get is better. Some hosts may be application servers, in this case public address works better for reasons like straightforward access, direct DNS registration, no permanent address mapping on NAT, etc. We assume the IPv4 global addresses are available, which is quite common as we covered in section 1. Cui, et al. Expires April 28, 2011 [Page 7] Internet-Draft 4over6 Access October 2010 Third, translation is not preferred in this scenario. If this IPv4- to-IPv4 communication is achieved by translation, it'll needs double translation along the path, one from IPv4 to IPv6 and the other from IPv6 back to IPv4. It's quite complicated. Contrarily a tunnel can achieve the IPv4-over-IPv6 traversing easily. That's the reason this draft follows the hub & spoke softwire model. Cui, et al. Expires April 28, 2011 [Page 8] Internet-Draft 4over6 Access October 2010 5. Stateless 4over6 Access 4over6 Access can be achieved in a stateless way or a stateful way. In stateless 4over6 the concentrator doesn't need to maintain any state, at the cost of coupling IPv4 and IPv6 addressing. In stateful 4over6 the concentrator has to maintain the mapping of allocated IPv4 address and the IPv6 address of corresponding initiator. The principle of stateless 4over6 Access is shown in this section, and stateful 4over6 Access will be discussed in next section. The draft will mainly focus on the CPE case since it's more complicated, and leave the host case as an extension. 5.1. Address allocation and routing Stateless 4over6 Access has specialized requirement on address allocation. Besides regular IPv6 address allocation, network operator should have a network-specific prefix (NSP) and a global IPv4 address pool (usually aggregated as an IPv4 prefix) for 4over6 Access addressing. A host requiring 4over6 Access service should acquire an IPv4-Embedded IPv6 address[I-D.ietf-behave-address-format], in which the prefix part is filled with NSP (the length of NSP is flexible and decided by the operators), and the IPv4 address part is filled with one 32bit address from the IPv4 address pool. The 4over6 host will get the IPv4 address while its CPE will hold the corresponding IPv6 address for IPv6 reachability. Besides address allocation, the related routing should be done. In IPv4 scope, the 4over6 concentrator on the IPv4-IPv6 border should advertise the IPv4 prefix (consists of the addresses allocated to IPv6 hosts) into the IPv4 network on Internet side, so that packets from the Internet destined to these addresses can be routed to the concentrator. In IPv6 scope, the routing in IPv6 network should support the 4over6 IPv6 address allocation besides the regular IPv6 address allocation. 5.2. 4over6 initiator behavior In the CPE case, 4over6 initiator represents the dual-stack CPE in front of the 4over6 hosts. It has an IPv6 interface connected to the IPv6 SP network, and at least an IPv4 interface connected to the IPv4 local network. Also it will have a tunnel interface supporting IPv4- in-IPv6 encapsulation and decapsulation. Before any 4over6 process, 4over6 initiator should have its regular IPv6 address provisioned, for its regular IPv6 communication. Cui, et al. Expires April 28, 2011 [Page 9] Internet-Draft 4over6 Access October 2010 4over6 initiator gets the IPv6 4over6 address by DHCPv6. It acts as a DHCPv4 server to 4over6 hosts and meanwhile a DHCPv6 client in IPv6. When a 4over6 host asks for an IPv4 access, it'll start the DHCPv4 process to acquire an IPv4 4over6 address. 4over6 initiator deals with this DHCPv4 request and starts the DHCPv6 process to acquire an IPv6 4over6 address. When getting the IPv6 address, the initiator will add this address to the address list of its IPv6 interface, and allocate the IPv4 4over6 address, which is embedded in the IPv6 4over6 address, to the 4over6 host. This way the host gets the global IPv4 address for its IPv4-IPv4 communication, and the initiator uses the IPv6 address to support this communication. A new DHCPv6 option is needed to identify this kind of DHCPv6 request, and to carry the NSP or NSP length information in DHCPv6 reply. 4over6 initiator performs the IPv4-in-IPv6 encapsulation and decapsulation for 4over6 hosts which has their IPv4 addresses already allocated. When a 4over6 host sends an IPv4 packet to the IPv4 Internet, this packet will first arrive at the initiator. The initiator performs the encapsulation, using the IPv6 4over6 address as the IPv6 source address. As to the IPv6 destination address, there're two choices. One is to using the concentrator address which should be acquired earlier. The other is to use an IPv4-mapped IPv6 address[I-D.ietf-behave-address-format] with NSP followed by the destination IPv4 address in original IPv4 packet. In this case the concentrator should advertise a default route for the NSP to collect the encapsulated IPv6 packets. The decapsulation on 4over6 initiator is simple. When receiving an IPv4-in-IPv6 packet, the initiator just drops the IPv6 header and forwards it to the IPv4 local network. 5.3. 4over6 concentrator behavior 4over6 concentrator represents the IPv4-IPv6 border router working as tunnel endpoint for 4over6 initiators. Its IPv6 interface is connected to the IPv6 network, and its IPv4 interface is connected to the IPv4 Internet. Also it will have a tunnel interface supporting IPv4-in-IPv6 encapsulation and decapsulation. 4over6 concentrator decapsulates the IPv4-in-IPv6 packets coming from 4over6 initiators in IPv6 side. It just drops IPv6 header and forwards the packets to the IPv4 Internet. The concentrator encapsulates the IPv4 packets destined to 4over6 hosts. When receiving an IPv4 packet like that, the concentrator performs an IPv4-in-IPv6 encapsulation, using the IPv4-embedded address IPv6 address formed by NSP and the IPv4 destination address in the IPv4 packet, as the IPv6 destination address. As to IPv6 source address, the concentrator can use its regular IPv6 address, or use an IPv4- mapped IPv6 address formed by the NSP and the IPv4 source address in the IPv4 packet. After the encapsulation, the concentrator forwards Cui, et al. Expires April 28, 2011 [Page 10] Internet-Draft 4over6 Access October 2010 the IPv6 packet on its IPv6 interface to reach an initiator. As is mentioned earlier, if we use the IPv4-mapped IPv6 address encapsulation source address in the concentrator and the encapsulation destination address in the initiators, then the concentrator should advertise a default route for the NSP in the IPv6 network, to collect the encapsulated IPv6 packets from the initiators. The choice will be made in the next version of this draft. As we can see, there's no need to maintain any IPv4-IPv6 address mapping on the 4over6 concentrator. So this 4over6 Access mechanism is stateless. However, operators do have to couple the IPv4 and IPv6 address and plan the address allocating and routing in a specialized way. Cui, et al. Expires April 28, 2011 [Page 11] Internet-Draft 4over6 Access October 2010 6. Stateful 4over6 Access 6.1. Address allocation Contrary to stateless 4over6 Access, stateful 4over6 Access has no requirement on the IPv6 address, and has no IPv4-IPv6 address coupling. IPv4 and IPv6 addressing and routing are separated, which would be a more common situation. Without IPv4-IPv6 address coupling, there has to be some address mapping maintained in the concentrator for correct encapsulation. There're several ways to achieve this mapping state maintaining, including DHCPv4 over tunnel with DHCP snooping, DHCPv4 over tunnel with traffic snooping, IPv4 subnet allocation with BGP or static mapping, etc. This draft talks about the first way in detail, and then turn to the other two in section 6.4. Adopting the first way, the global IPv4 addresses for 4over6 host will be maintained by the concentrator or dedicated DHCPv4 server around the concentrator, and allocated by DHCPv4 process over the IPv6 network, i.e., through the IPv4-in-IPv6 tunnel between the initiator and the concentrator. Also the CPE initiator should relay DHCPv4 between 4over6 host and the concentrator. 6.2. 4over6 initiator behavior Similar to the stateless 4over6 Access, in the CPE case 4over6 initiator represents the CPE in front of the 4over6 hosts with an IPv6 interface connected to the IPv6 SP network, at least an IPv4 interface connected to the IPv4 local network, and a tunnel interface supporting IPv4-in-IPv6 encapsulation and decapsulation. 4over6 initiator should learn the 4over6 concentrator's IPv6 address. For example, if the initiator gets its IPv6 address by DHCPv6, it should get the 4over6 concentrator's IPv6 address by DHCPv6 option[I-D.ietf-softwire-ds-lite-tunnel-option]. 4over6 initiator gets the global IPv4 address for by DHCPv4 on an IPv4-in-IPv6 tunnel. In the CPE case, when a 4over6 host asks for an IPv4 access, it'll start the DHCPv4 process to acquire a global IPv4 address. The 4over6 initiator acts as a DHCPv4 relay and relays the request to the concentrator. Although the network between the initiator and the concentrator is IPv6, an IPv4-in-IPv6 tunnel can achieve this DHCPv4 process. All the DHCPv4 packets between the initiator and the concentrator are encapsulated in IPv6. The initiator will relay the DHCPv4 reply from the concentrator to the 4over6 host. Then the host can get a global IPv4 address and assign the address to its IPv4 interface. Cui, et al. Expires April 28, 2011 [Page 12] Internet-Draft 4over6 Access October 2010 4over6 initiator performs the IPv4-in-IPv6 encapsulation and decapsulation for 4over6 hosts which has their IPv4 addresses already allocated. When a 4over6 host sends an IPv4 packet to the IPv4 Internet, this packet will arrive at the initiator. The initiator performs the encapsulation, using the IPv6 address of the 4over6 concentrator as the IPv6 destination address, and the IPv6 address of itself as the IPv6 source address. The encapsulated packet will be forwarded to the IPv6 network. The decapsulation on 4over6 initiator is simple. When receiving an IPv4-in-IPv6 packet, the initiator just drops the IPv6 header and forwards it to the IPv4 local network. 6.3. 4over6 concentrator behavior 4over6 concentrator represents the IPv4-IPv6 border router working as tunnel endpoint for 4over6 initiators, with its IPv6 interface connected to the IPv6 network, IPv4 interface connected to the IPv4 Internet, and a tunnel interface supporting IPv4-in-IPv6 encapsulation and decapsulation. 4over6 concentrator maintains an IPv4-IPv6 address mapping table for IPv4 data packet encapsulation, and a MAC-IPv6 address mapping table for DHCPv4 encapsulation. 4over6 concentrator is responsible for DHCPv4 address allocation for the 4over6 hosts. One way to do it is to perform a DHCPv4 server on the concentrator. Then it should maintain the global IPv4 address pool, and dynamically allocate addresses according to DHCPv4 request from 4over6 initiator. After allocating a dynamic IPv4 address to the 4over6 endpoint, the concentrator should maintain the mapping between the allocated IPv4 address and the IPv6 address of corresponding 4over6 initiator. Another way to do it is to perform DHCPv4 relay functions on the concentrator, and leave the actual address allocation job to a dedicated DHCPv4 server. In this case the concentrator still needs to maintain the IPv4-IPv6 address mapping when relaying DHCP messages. The DHCP process on IPv6 side is performed in IPv4-in-IPv6 tunnel. The concentrator receives IPv6 packet containing the DHCPv4 message coming from a 4over6 host and relayed by the initiator, decapsulate it to get the DHCPv4 message, add the mapping between the MAC address in it and the IPv6 address of the initiator to the MAC-IPv6 mapping table, and then handle it to the DHCPv4 server or relay on the concentrator. The concentrator sends DHCPv4 message from DHCPv4 server or relay to 4over6 initiator using IPv6 encapsulation. When encapsulating, the concentrator should use the MAC address in the DHCPv4 message to look up the MAC-IPv6 mapping table and find the address as encapsulation destination IPv6 address. Cui, et al. Expires April 28, 2011 [Page 13] Internet-Draft 4over6 Access October 2010 4over6 concentrator decapsulates the IPv4-in-IPv6 packets coming from 4over6 initiators in IPv6 side. It just drops IPv6 header and forwards the packets to the IPv4 Internet. The concentrator encapsulates the IPv4 packets destined to 4over6 hosts. When receiving an IPv4 packet like that, the concentrator performs an IPv4-in-IPv6 encapsulation, using the IPv6 address of itself as the IPv6 source address. As to IPv6 destination address, the concentrator will use the IPv4 destination address to look up the IPv4-IPv6 address mapping table to find the correct IPv6 address. After the encapsulation, the concentrator forwards the IPv6 packet on its IPv6 interface to reach an initiator. The 4over6 concentrator, or its upstream router should advertise the IPv4 prefix used for 4over6 hosts address allocation on the IPv4 side, to make this hosts reachable on IPv4 Internet. Since the concentrator has to maintain the IPv4-IPv6 address mapping table for encapsulation purpose, the concentrator is stateful in IP- level. Note that this table will be much smaller than a CGN table, as there is not port involved. 6.4. Mapping maintaining methods other than DHCP snooping Till now the stateful 4over6 Access is described in a DHCP snooping way, in which the concentrator snoops on the DHCPv4 process to learn the IPv4-IPv6 address mapping. Actually, an operator can choose to learn the mapping through traffic snooping, i.e., when decapsulating IPv6 packets coming from 4over6 initiators. This way the mappings are installed based on the actual traffic rather than DHCP. However, one shortage of this method is that extra procedure may be needed to support inbound access. This happens when there's no mapping for an allocated IPv4 address installed on the concentrator yet since there's no outbound traffic from this IP, and packets from the IPv4 Internet have already arrived on the concentrator and try to reach the corresponding IP. The extra procedure is simple, though. The 4over6 host or the initiator can just send an arbitrary IPv4 packet to reach the concentrator through encapsulation and decapsulation, and hence install the mapping. We suggest the destination IPv4 address of this packet to be the IPv4 interface address of the concentrator. In some situations, DHCPv4 for address allocation may be irrelevant. For example, the local network behind a CPE can be a quite large enterprise network; then the one-by-one address allocation won't be efficient. In this case ISP should assign a subnet to the enterprise, and leave the detailed address allocation to the enterprise. What the concentrator should learn is the mapping of the IPv4 subnet and the IPv6 address of the enterprise CPE. A BGP Cui, et al. Expires April 28, 2011 [Page 14] Internet-Draft 4over6 Access October 2010 process supporting [RFC5549] extension between the concentrator and the CPE can achieve that. Actually, if the addresses are stable, the concentrator can just configure the mappings itself. Cui, et al. Expires April 28, 2011 [Page 15] Internet-Draft 4over6 Access October 2010 7. Combination with Dual-Stack Lite 4over6 Access can easily collaborate with Dual-Stack Lite[I-D.ietf-softwire-dual-stack-lite], for they are trying to solve the same problem with different type of addresses. 4over6 Access uses global IPv4 address while Dual-stack Lite uses private IPv4 address. For situations where global address resource is rare, common users can use Dual-stack Lite to get IPv4 service, and users with special requirement like operating an IPv4 server can use 4over6 Access. 7.1. Combination in the CPE CPE SHOULD run the DHCPv4 server to allocate private addresses for DS-Lite, and performs DHCPv4 relay for stateful 4over6 Access, or "DHCPv46"(the DHCPv4 and DHCPv6 procedure described in section 4.2) for stateless 4over6 Access at the same time. The CPE can differentiate the two types of DHCP request by MAC configuration. 7.2. Combination in the DHCPv6 server DHCPv6 server need to allocate IPv6 addresses with the option containing CGN/4over6 concentrator address, to B4 element and 4over6 initiator respectively. 7.3. Combination in the concentrator DS-lite and 4over6 Access can use the same concentrator, while 4over6 Access doesn't need the CGN function. The concentrator can distinguish between outbound packets of Dual-stack Lite and 4over6 Access by the source IPv4 address: if it is global, it is a 4over6 Access packet. Otherwise, it is a Dual-stack Lite packet. Besides, the concentrator can distinguish inbound IPv4 packets based on IPv4 destination address, since 4over6 Access and Dual-stack lite will use different global IPv4 address range if they coexist. Cui, et al. Expires April 28, 2011 [Page 16] Internet-Draft 4over6 Access October 2010 8. Further Discussion 8.1. Technical advantages of 4over6 Access 4over6 Access provides a method for users in IPv6 network to communicate with IPv4. In many scenarios, this can be viewed as an alternative to IPv6-IPv4 translation mechanisms which have well-known limitations described in [RFC4966] . Since a 4over6 host uses a global IPv4 address, 4over6 Access supports full bidirectional communication between IPv4 Internet and hosts/networks in IPv6 access network. In particular, it supports the servers in IPv6 network to provide IPv4 application service quite well. 4over6 Access supports dynamic reuse of a single IPv4 address between multiple hosts based on their dynamic requirement of communicating with IPv4 Internet, and hence can improve the reuse rate of IPv4 addresses. When clients or servers need to communicate with IPv4 Internet, they will request a global IPv4 address for a period of time. This time can be longer for servers and shorter for clients. 4over6 Access is mainly suited for end hosts or networks which can still get/provide IPv4 services, such as legacy IPv4 users newly switching to IPv6. Network operators can take back the IPv4 addresses from the existing users, have the network switched to IPv6 and re-allocate the IPv4 addresses to them in a 4over6 Access way. 8.2. 4over6 Access for direct-connected 4over6 hosts Section 3 and section 4 only discusses the CPE case since it's a little more complicated than the direct-connect host case. The difference in direct-connected host case will be provided here. For stateless 4over6 Access, When the 4over6 host is the initiator, by performing DHCPv6 acquiring 4over6 address, the host holds both the IPv4 4over6 address and the IPv6 4over6 address. No DHCPv4 process is needed. The IPv6 address will be assigned to its IPv6 interface, and the IPv4 address will be assigned to the tunnel interface. The host will perform the encapsulation and decapsulation itself, but the operations are similar. For stateless 4over6 Access, When the 4over6 host is the initiator, it'll perform the DHCPv4 process with the concentrator itself, through an IPv4-in-IPv6 tunnel. It'll assign the allocated IPv4 address to the tunnel interface. The host will perform the encapsulation and decapsulation itself, but the operations are similar. Cui, et al. Expires April 28, 2011 [Page 17] Internet-Draft 4over6 Access October 2010 8.3. Address configuration issue in home LAN network situation There is one issue not covered yet when the local network is a home LAN: how do the 4over6 hosts configure the gateway address and the subnet mask length (usually by DHCPv4 along with address allocation)? In stateful 4over6 Access, It's tricky since two hosts in one LAN may get any two addresses in the entire global IPv4 address pool. Suppose the hosts in one LAN set the subnet mask length equal to the prefix length of the address pool, in order to achieve one-hop communication between them, and set the gateway to be the CPE. As a consequence, they'll drop any IPv4 packet destined to other 4over6 hosts which are not in the same LAN, since they think they' re one- hop away while the ARP process find no answer. One solution is to have the CPE work as an ARP proxy which answers to any ARP request whose IPv4 address is not in this LAN. Then the CPE can get the packets destined to other 4over6 hosts and deal with them separately. Another solution is to have the hosts and the CPE narrow their subnet mask to 32, and have the CPE to configure a /32 route for every host. Then the CPE will become a "switch" for any two hosts in this LAN. Note that all the CPEs can use one unique IPv4 address from the address pool. Due to the IPv6 address planning in stateless 4over6 Access, the IPv4 addresses 4over6 hosts in the same LAN got will be more "close" to each other. Nevertheless the problem still exists. The above two solutions both works in stateless 4over6 Access as well, except that CPE can't use a unique CPE address. Cui, et al. Expires April 28, 2011 [Page 18] Internet-Draft 4over6 Access October 2010 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009. 9.2. Informative References [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), August 2010. [I-D.ietf-softwire-ds-lite-tunnel-option] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", draft-ietf-softwire-ds-lite-tunnel-option-05 (work in progress), September 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-06 (work in progress), August 2010. [I-D.ietf-softwire-ipv6-6rd] Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10 (work in progress), May 2010. Cui, et al. Expires April 28, 2011 [Page 19] Internet-Draft 4over6 Access October 2010 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Peng Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: weapon@csnet1.cs.tsinghua.edu.cn Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA Email: chmetz@cisco.com Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 USA Email: Olivier@juniper.net Cui, et al. Expires April 28, 2011 [Page 20] Internet-Draft 4over6 Access October 2010 Alain Durand Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089-1206 USA Email: adurand@juniper.net Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com Cui, et al. Expires April 28, 2011 [Page 21]