Network Working Group Y. Cui Internet-Draft J. Wu Intended status: Standards Track P. Wu Expires: June 3, 2011 Tsinghua University C. Metz Cisco Systems, Inc. O. Vautrin Juniper Networks Y. Lee Comcast November 30, 2010 4over6 Access for IPv4 provisioning in IPv6 network draft-cui-softwire-host-4over6-03 Abstract This draft proposes a mechanism for bidirectional IPv4 communication between IPv4 Internet and end 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 public 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 June 3, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Cui, et al. Expires June 3, 2011 [Page 1] Internet-Draft 4over6 Access November 2010 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 June 3, 2011 [Page 2] Internet-Draft 4over6 Access November 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. 4over6 Access Mechanism . . . . . . . . . . . . . . . . . . . 9 5.1. Address allocation . . . . . . . . . . . . . . . . . . . . 9 5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 9 5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 10 5.4. IPv4-IPv6 mapping maintaining methods . . . . . . . . . . 12 6. Combination with Dual-stack Lite . . . . . . . . . . . . . . . 13 6.1. Combination of 4over6 initiator and B4 . . . . . . . . . . 13 6.2. Combination in the DHCPv6 server . . . . . . . . . . . . . 13 6.3. Combination of 4over6 concentrator and AFTR . . . . . . . 13 7. Technical advantages . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Cui, et al. Expires June 3, 2011 [Page 3] Internet-Draft 4over6 Access November 2010 1. Introduction Global IPv4 addresses are running out fast. Meanwhile, the demand for IP address is still growing and may even burst in potential circumstances 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. When IPv6-only network are widely deployed, users of those networks will probably still need IPv4 connectivity. This is because part of Internet will stay IPv4-only for a long time, and network users in IPv6-only network will communicate with network users sited in the IPv4-only part of Internet. This need could eventually decrease with the general IPv6 adoption. Network operators should provide IPv4 services to IPv6 users to satisfy their needs, usually through tunnels. This type of IPv4 services differ by provisioned IPv4 addresses. If the users can't get public IPv4 addresses (e.g., new network users join an ISP which don't have enough unused IPv4 addresses), they have to use private IPv4 addresses on the client side, and IPv4-private-to-public translation is required on the carrier side, as is described in Dual- stack Lite[I-D.ietf-softwire-dual-stack-lite]. Otherwise the users can get public IPv4 addresses, and use them for IPv4 communication. In this case, 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 "public IPv4" situation is actually quite common. There're nearly 2^32 network users who are using or can potentially get public 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 networks, where IPv4 public addresses are still available. Cui, et al. Expires June 3, 2011 [Page 4] Internet-Draft 4over6 Access November 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 June 3, 2011 [Page 5] Internet-Draft 4over6 Access November 2010 3. Terminology 4over6 Access: 4over6 Access is the mechanism proposed by this draft. Generally, 4over6 Access supports bidirectional communication between IPv4 Internet and IPv4 hosts or local networks in IPv6 access network, by leveraging IPv4-in-IPv6 tunnel and public IPv4 address allocation. 4over6 initiator: in 4over6 Access mechanism, 4over6 initiator is the IPv4-in-IPv6 tunnel initiator located on the user side of IPv6 network. The 4over6 initiator can be either a dual-stack capable host or a dual-stack CPE device. In the former case, the host has both IPv4 and IPv6 stack but is provisioned with IPv6 access only. In the latter case, the CPE has both IPv6 interface for access to ISP network and IPv4 interface for local network connection; hosts in the local network can be IPv4-only. 4over6 concentrator: in 4over6 Access mechanism, 4over6 concentrator is the IPv4-in-IPv6 tunnel concentrator located in IPv6 ISP network. It's a dual-stack router which connects to both the IPv6 network and IPv4 Internet. Cui, et al. Expires June 3, 2011 [Page 6] Internet-Draft 4over6 Access November 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 ISP network directly, while others are local networks behind CPEs, such as a home LAN, an enterprise network, etc. The ISP 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 that one or more routers on the carrier side 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 ISP Network | +------+ | |host: | | |initi-| | |ator |=================+-------+ +-----------+ +------+ |4over6 | | IPv4 | | IPv4-in-IPv6 |Concen-|---| Internet | +----------+ +------+ |trator | | | |local IPv4|--|CPE: |=================+-------+ +-----------+ | network | |initi-| | +----------+ |ator | | +------+ | | | +-------------------------+ 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 users 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, 4over6 users require public IPv4 addresses rather than private addresses. Public IPv4 address means there's no IPv4 CGN along the path, so the acquired IPv4 service is btter. In particular, some hosts may be application servers, public address Cui, et al. Expires June 3, 2011 [Page 7] Internet-Draft 4over6 Access November 2010 works btter for reasons like straightforward access, direct DNS registration, no stateful mapping maintainence on CGN, etc. We assume the IPv4 public addresses are available, which is quite common as we covered in section 1. 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 June 3, 2011 [Page 8] Internet-Draft 4over6 Access November 2010 5. 4over6 Access Mechanism 5.1. Address allocation 4over6 Access can be generally considered as IPv4-over-IPv6 hub & spoke tunnel using public IPv4 address. Each 4over6 initiator will use a unique, public IPv4 address for IPv4-over-IPv6 communication. This means one IPv4 address for one host in host initiator case and one IPv4 address for one local IPv4 network in CPE initiator case. In the latter case, the CPE can then operate a local IPv4 NAT to share the IPv4 address between hosts in the local network. Note that local NAT is much more controllable and configurable than CGN. If the hosts in the local network need dedicated IPv4 addresses, just extend IPv6 across the CPE and make the local network IPv6. This way every host can be a dedicated 4over6 initiator. The key problem here is IPv4 address allocation over IPv6 network, from ISP device(s) to separated 4over6 initiators. Native IPv4 address allocation is done either in a dynamic way through DHCPv4, or in a static way through manual configuration. 4over6 Access should support both. DHCPv4 over IPv6 can be achieved through IPv4-in-IPv6 tunnel between ISP device and 4over6 initiators. As to manual configuration, 4over6 users and the ISP operators should negotiate beforehand to authorize the IPv4 address. Along with this address allocation, the concentrator needs to maintain the address mappings between the IPv4 address and IPv6 address of 4over6 initiators. This is required to provide correct destination address for encapsulation. There are several ways to achieve this mapping maintaining: DHCPv4-driven updating, traffic snooping and manual configuration. This draft recommends the first way for dynamic maintaining and describe it in detail, and then compare it with traffic snooping in section 5.4. 5.2. 4over6 initiator behavior 4over6 initiator has an IPv6 interface connected to the IPv6 ISP network, and a tunnel interface to support IPv4-in-IPv6 encapsulation. In CPE case, it has at least one IPv4 interface connected to IPv4 local network. 4over6 initiator should learn the 4over6 concentrator's IPv6 address beforehand. For example, if the initiator gets its IPv6 address by DHCPv6, it should get the 4over6 concentrator's IPv6 address through a DHCPv6 option[I-D.ietf-softwire-ds-lite-tunnel-option]. Usually, 4over6 initiator gets the public IPv4 address by DHCPv4 on an IPv4-in-IPv6 tunnel. A standard DHCPv4 client in the initiator Cui, et al. Expires June 3, 2011 [Page 9] Internet-Draft 4over6 Access November 2010 will run on the tunnel interface to acquire IPv4 address. All the DHCPv4 packets generated by the client will be encapsulated and forwarded to the 4over6 concentrator, and all the DHCPv4 replies from the concentrator encapsulating in IPv6 will be decapsulated by the tunnel interface and handed to the client. This way the DHCP client can get a dynamic public IPv4 address from the concentrator, and assign it to the tunnel interface. If the address allocation is static, 4over6 user should negotiate with the ISP operator beforehand. The user needs to learn the IPv4 address provisioned by the operator, and inform the operator the IPv6 address of the initiator, to install the address mapping on the concentrator. For IPv4 traffic, 4over6 initiator performs the IPv4-in-IPv6 encapsulation and decapsulation on the tunnel interface, which has its IPv4 address already assigned. When processing an IPv4 packet destinated to the IPv4 Internet(either generated by the initiator itself, or received from the local network and translated by local NAT44), it 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 either hands it to upper layer, or performs the local NAT44 translation and then 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, 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. 4over6 concentrator is responsible for DHCPv4 address allocation to 4over6 initiators. For static allocation, the concentrator just install the IPv4-IPv6 address mapping into the mapping table after negotiating with a 4over6 user. As to dynamic allocation, the concentrator should either run a DHCPv4 server on the tunnel interface to dynamically allocate public addresses to 4over6 initiators, or perform the DHCPv4 relay functions and leave the actual address allocation job to a dedicated DHCPv4 server. In both cases, when allocating an address, the concentrator should install an entry of the allocated IPv4 address and the initiator's IPv6 address into the address mapping table. This entry should be deleted when Cui, et al. Expires June 3, 2011 [Page 10] Internet-Draft 4over6 Access November 2010 receiving a DHCP release or reaching a lease expiration. All the update should be triggered by the DHCP process(see Figure 2). Note that in the DHCP relay case, the relay should be extended to maintain the lifetime of address leases. The DHCP packets the concentrator is performed in IPv4-in-IPv6 tunnel. The difficulty here is that before DHCP address allocation is done, the initiator may not have an IPv4 address, and the concentrator doesn't have an IPv4-IPv6 mapping for IPv6 encapsulation of corresponding DHCP packets. So when the concentrator receives a DHCP packet, it should store the mapping of IPv6 source address of this packet and the MAC address in the DHCP payload temporarily. This mapping will be used for encapsulation of outgoing DHCP packets. The concentrator should use the MAC address in the payload of an outing DHCP packet to match the correct IPv6 encapsulation destination address. DHCP EVENT initi- concen- BEHAVIOR ator trator allocating a new |---DHCPDISCOVER-->| store IPv6-MAC mapping network address |<-----DHCPOFFER---| |---DHCPREQUEST--->| |<-----DHCPACK-----| install IPv4-IPv6 mapping | : | address renewal |---DHCPREQUEST--->| store IPv6-MAC mapping |<-----DHCPACK-----| update lease lifetime | : | address release |---DHCPRELEASE--->| delete IPv4-IPv6 mapping | : | lease expiration | no message | delete IPv4-IPv6 mapping Figure 2 4over6 concentrator: DHCP behavior On the IPv6 side, 4over6 concentrator decapsulates IPv4-in-IPv6 packets coming from 4over6 initiators. It removes the IPv6 header of every IPv4-in-IPv6 packet and forwards it to the IPv4 Internet. On the IPv4 side, the concentrator encapsulates the IPv4 packets destined to 4over6 initiators. When performing the IPv4-in-IPv6 encapsulation, the concentrator uses its own IPv6 address as the IPv6 source address. As to IPv6 destination address, the concentrator will look up the IPv4-IPv6 address mapping table, use the IPv4 destination address of the packet 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 which contains the addresses of 4over6 initiators on the Cui, et al. Expires June 3, 2011 [Page 11] Internet-Draft 4over6 Access November 2010 IPv4 side, to make these initiators reachable on IPv4 Internet. Since the concentrator has to maintain the IPv4-IPv6 address mapping table, the concentrator is stateful in IP level. Note that this table will be much smaller than a CGN table, as there is no port information involved. 5.4. IPv4-IPv6 mapping maintaining methods section 5.3 describes the address mapping maintaining with DHCP- driven updating, in which DHCP process on the concentrator triggers installation and deletion of IPv4-IPv6 address mappings. Another way to maintain the mapping is traffic snooping, i.e., record the address mapping when decapsulating IPv4-in-IPv6 data packets coming from 4over6 initiators. In this way, the mappings are installed based on the actual traffic rather than DHCP. However, the shortage of this method is that extra procedure is required to support inbound access well. This happens when there's no mapping exists on the concentrator for an allocated IPv4 address, either because there's no outbound traffic from this IP yet or because the earlier-installed mapping has expired, while packets from the IPv4 Internet have already arrived on the concentrator and tried to reach the corresponding IP. To solve this problem, the 4over6 initiator need to send keepalive "pinhole" packets to the concentrator. A pinhole packet can be an arbitrary IPv4 packet which can reach the concentrator. This draft recommends the DHCP-driven updating method since it's more accurate and controllable, and requires no extra procedure on the initiator. If an operator chooses the DHCP-driven updating method, the concentrator need manual mapping configuration as well for static configured 4over6 initiators. The traffic snooping method works for both static and dynamic 4over6 initiators, though. Cui, et al. Expires June 3, 2011 [Page 12] Internet-Draft 4over6 Access November 2010 6. Combination with Dual-stack Lite The scenario will be common in which an operator do have some unused IPv4 addresses, but not enough for every user. This requires a combination of Dual-stack Lite and 4over6 Access to provide IPv4 access for all the users. 4over6 Access uses public IPv4 address while Dual-stack Lite uses private IPv4 address, so ordinary users can use Dual-stack Lite to get IPv4 access, and high-priority users such as application servers can use 4over6 Access to get btter IPv4 access. 4over6 Access can easily collaborate with Dual-Stack Lite, since the functions of 4over6 initiator are quite close to DS-lite B4, and the functions of 4over6 concentrator are quite close to DS- lite AFTR. 6.1. Combination of 4over6 initiator and B4 The initiator and B4 uses same IPv4-in-IPv6 encapsulation and decapsulation method, so they can use one tunnel interface. The initiator/B4 should support DS-lite as basic IPv4 access method, and assign IPv4 private address to the tunnel interface. If it can get public IPv4 address(and hence 4over6 Access), then this address should be assigned to the tunnel interface as primary address, and leave the private IPv4 address as sencondary address. In this way, 4over6 Access will be the preferred access method and DS-lite will be the basic method. 6.2. Combination in the DHCPv6 server DHCPv6 server need to allocate IPv6 addresses with the option containing 4over6 concentrator/AFTR address, to 4over6 initiator/B4. 6.3. Combination of 4over6 concentrator and AFTR 4over6 Access and DS-lite can use the same concentrator/AFTR device. They can use one tunnel interface for encapsulation and decapsulation. The device will support NAT-related functions only for DS-lite, and support DHCP function and IPv4-IPv6 mapping table only 4over6 Access. The concentrator can distinguish between outbound packets of Dual-stack Lite and 4over6 Access by the source IPv4 address: if it is public, 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, as long as 4over6 Access and Dual-stack lite use different public IPv4 address range. In practical situation, the concentrator/AFTR should maintain a 4over6 authority list, which contains the IPv6 addresses of all the authorized 4over6 subscribers(initiators). If a subscriber is on the Cui, et al. Expires June 3, 2011 [Page 13] Internet-Draft 4over6 Access November 2010 list, it can get a public IPv4 address and the 4over6 Access service. Else it has to use private IPv4 address and DS-lite for IPv4 communication. Cui, et al. Expires June 3, 2011 [Page 14] Internet-Draft 4over6 Access November 2010 7. Technical advantages 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 initiator uses a public 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 transparently. 4over6 Access supports dynamic reuse of a single IPv4 address between multiple subscribers based on their dynamic requirement of communicating with IPv4 Internet. A subscriber will request a public IPv4 address for a period of time only when it need to communicate with IPv4 Internet. Besides, in the CPE case, one public IPv4 address will be shared by the local network. So 4over6 Access can improve the reuse rate of IPv4 addresses. 4over6 Access is suited for network users/ISPs which can still get/ provide public IPv4 addresses. Dual-stack lite is suited for network users/ISPs which can no longer get/provide public IPv4 addresses. By combining 4over6 Access and Dual-stack lite, the IPv4-over-IPv6 Hub & spoke problem can be well solved. Cui, et al. Expires June 3, 2011 [Page 15] Internet-Draft 4over6 Access November 2010 8. Acknowledgement The authors would like to thank Alain Durand and Dan Wing for their valuable comments on this draft. Cui, et al. Expires June 3, 2011 [Page 16] Internet-Draft 4over6 Access November 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. 9.2. Informative References [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-06 (work in progress), November 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. Cui, et al. Expires June 3, 2011 [Page 17] Internet-Draft 4over6 Access November 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 June 3, 2011 [Page 18] Internet-Draft 4over6 Access November 2010 Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com Cui, et al. Expires June 3, 2011 [Page 19]