Network Working Group Y. Cui Internet-Draft J. Wu Intended status: Standards Track P. Wu Expires: January 6, 2011 Tsinghua University July 5, 2010 4over6 for IPv6 host connecting IPv4 Internet draft-cui-softwire-host-4over6-00 Abstract This draft proposes a mechanism for bidirectional communication between IPv4 Internet and hosts in IPv6 access networks. Adopting the Softwire hub & spoke model, this mechanism uses IPv4-over-IPv6 tunnel to traverse the IPv6 networks. 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 January 6, 2011. Copyright Notice 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. Cui, et al. Expires January 6, 2011 [Page 1] Internet-Draft Host 4over6 July 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenario description and analysis . . . . . . . . . . . . . . 6 4. Host 4over6 Framework . . . . . . . . . . . . . . . . . . . . 7 4.1. addressing and routing in Host 4over6 . . . . . . . . . . 7 4.2. 4over6 Initiator . . . . . . . . . . . . . . . . . . . . . 7 4.3. 4over6 Concentrator . . . . . . . . . . . . . . . . . . . 8 5. Further Discussion . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Technical advantage of Host 4over6 . . . . . . . . . . . . 10 5.2. Application Scenario of Host 4over6 . . . . . . . . . . . 10 5.3. Home network consideration . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Cui, et al. Expires January 6, 2011 [Page 2] Internet-Draft Host 4over6 July 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 network users, operators have to push IPv6 to the front, by building IPv6 networks and providing IPv6 services. When IPv6 begins to serve the large number of end users as native network, IPv4 service for these users rises as a critical requirement simultaneously. This is because before the whole world switch to IPv6, there'll still be a portion of resources, applications and users to communicate persisting in IPv4. So the end users in IPv6 network desires to get connected with IPv4 Internet, especially in the early period when IPv4 is still dominant. The IPv4 service which network operators provided for IPv6 users differs IPv4 address. If the IPv6 clients don't have IPv4 addresses(e.g., new network users join this ISP and ISP don't have enough unused IPv4 address for them), then they have to use private IPv4 address in client side and an IPv4 private-to-global translation is required in the carrier side. Otherwise the IPv6 clients can get global IPv4 addresses, then they can use them for IPv4 communication, and hence translation shouldn't be involved. Without translation, the network users and operators can avoid all the problems introduced by it, such as application translation, port allocation, state maintenance, etc., and get/provide better IPv4 services. Note that this situation is actually quite popular. There're up to 2^32 networks users who are using IPv4 global address or can get an IPv4 global IPv4 address. Most of them will switch to IPv6 sooner or later, and will require IPv4 services after the switching. This draft will focus on this situation, i.e., to provide IPv4 access for hosts in IPv6 network where IPv4 global addresses are available. We can take CERNET(China Education and Research Network) as an example. CERNET has two backbone using different address families, the IPv4-only backbone is known as CERNET and the IPv6-only backbone is known as CERNET2. There are hundreds of Campus networks attaching to CERNET and some of them have got attached to CERNET2 as well. All these Campus networks have got their IPv4 prefixes allocated from CERNET and the end hosts in these networks are using IPv4 global addresses at present. Now imagine one day all these campus networks get attached to CERNET2 and turn into IPv6-only. Then the end hosts in them have to switch to IPv6 accordingly, but they'll naturally continue to require IPv4 services. In this scenario, the end hosts can use their previous IPv4 addresses for the new type of IPv4 Cui, et al. Expires January 6, 2011 [Page 3] Internet-Draft Host 4over6 July 2010 services, since the addresses are already possessed by the campus network and the clients basically remains the same. Cui, et al. Expires January 6, 2011 [Page 4] Internet-Draft Host 4over6 July 2010 2. Terminology Host 4over6 Host 4over6 is the technology proposed by this draft, to support the bidirectional communication between IPv4 Internet and a host in IPv6 access network. 4over6 host The host that supports Host 4over6 in IPv6 access network. 4over6 host is also called 4over6 initiator. 4over6 host is a 4over6 tunnel endpoint in Host 4over6. 4over6 concentrator 4over6 concentrator is the dual stack router which connecting the IPv6 access network to IPv4 Internet. 4over6 concentrator is also a 4over6 tunnel endpoint in Host 4over6. Cui, et al. Expires January 6, 2011 [Page 5] Internet-Draft Host 4over6 July 2010 3. Scenario description and analysis The scenario is shown in Figure 1. Hosts in an IPv6 network take IPv6 as their native service. At the same time, these hosts want to get IPv4 services as well, i.e., they want to connect to IPv4 Internet. However, the reality is that the network these hosts get attached to is IPv6-only rather than dual-stack. Fortunately, network operators can connect a small number of routers to IPv4 Internet, so a large number of end hosts can get IPv4 connectivity through these v4-v6 border routers. So generally, it's an IPv4-over- IPv6 Hub & spoke problem[RFC4925]. +-------------------------+ | IPv6 Network | +-----+ | +-------------+ | H1 | ================ +-------+ | | +-----+ |v4-v6 | | IPv4 | | |Border |---| Internet | +-----+ |Router | | | | H2 | ================ +-------+ | | +-----+ // | +-------------+ | // | | +-----+ | +---------------| H3 |---+ +-----+ Figure 1 Host 4over6 scenario Under this scenario, let's make some basic assumptions on the user expectations. First and the most important one, the end users want an IPv4 access method, so they expect a tunnel mechanism rather than a translation mechanism. Second, end users require global IPv4 address. As is analyzed earlier, lack of IPv4 addresses isn't a concern in this scenario. Third, users expect no translations along the IPv4 path, so there're no problems like NAT traversing, so the IPv4 service can be better, various applications can be supported well. As to network operators, they expect the method to be simple, useful and scalable. They don't want to maintain state on their devices unless they have to. Cui, et al. Expires January 6, 2011 [Page 6] Internet-Draft Host 4over6 July 2010 4. Host 4over6 Framework Host 4over6 is a traversing mechanism for hosts in IPv6 network to reach IPv4 Internet and get IPv4 service. Host 4over6 adopts the Hub & Spoke model, and uses IP-in-IP tunnel as the encapsulation method. The IPv6 hosts requiring IPv4 service act as tunnel initiator, and the IPv4-IPv6 border router acts as tunnel concentrator. Host 4over6 allocates IPv4 global address to the hosts by embedding it in the IPv6 address of the hosts. This way tunnel concentrator can figure out the IPv6 encapsulation destination address automatically when sending an IPv4 packet through 4over6 tunnel, therefore no information maintenance is required on concentrator. 4.1. addressing and routing in Host 4over6 Host 4over6 has specialized requirement on address allocation. Network operator should have a network-specific prefix(NSP), and a global IPv4 address pool(usually aggregated as an IPv4 prefix) for Host 4over6 usage. The IPv6 hosts requiring Host 4over6 service should be allocated with IPv4-Embedded IPv6 address[I-D.ietf-behave-address-format], in which the prefix part is filled with NSP, and the v4 address part is filled with one 32bit address from the IPv4 address pool. Different hosts get different IPv6 addresses with the same prefix (i.e. NSP) and different IPv4 addresses. The prefix length is flexible and decided by the operators. By this IPv6 address allocation process, one host possesses a global IPv4 address and the corresponding mapped IPv6 address. Besides address allocation, the corresponding 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 packet destined to these addresses can be routed to the concentrator and then reach the hosts by tunnel. In IPv6 scope, the routing in IPv6 network should support the IPv6 address allocation. This is no different from regular IPv6 allocation and routing. 4.2. 4over6 Initiator 4over6 initiator represents the IPv6 hosts requiring IPv4 service. These hosts are in the IPv6-only network, they're not provisioned with native IPv4 access, but the protocol stack on the hosts supports IPv4. The protocol stack should have an tunnel interface, supporting IPv4-in-IPv6 tunnel encapsulation and decapsulation. 4over6 Initiator should get its IPv6 address by DHCPv6. When it learns the IPv6 address and bind it to the IPv6 interface, it will Cui, et al. Expires January 6, 2011 [Page 7] Internet-Draft Host 4over6 July 2010 also extract the IPv4 address from the IPv4-Embedded IPv6 address, and bind it to the tunnel interface. This address will work as the native IPv4 address for this host. When the host want to send an IPv4 packet, this packet will be handed to the tunnel interface. The tunnel interface will put an IPv6 header on this packet, using the IPv4-Embedded IPv6 address as the source address and the concentrator IPv6 address as the destination address. Then the packet will be sent on the IPv6 interface. When the host receives an encapsulated IPv4-in-IPv6 packet, it will decapuslate it by dropping the IPv6 header and handed it to the tunnel interface, and then handed up to higher layer. 4over6 Initiator should learn the NSP(or the NSP length) and the concentrator IPv6 address before the data process begins. This can be done by manual configuration, new DHCP option, etc. Actually, when performing encapsulation, there is another way to form the destination address. We can use an IPv4-mapped IPv6 address with NSP as prefix and actual destination IPv4 address as v4 address to be the IPv6 destination address, and then have the Concentrator advertise the default route for NSP, so as to route the encapsulated packet to the Concentrator. However, when there exists multiple Concentrators, this will leads to asymmetric routing. This draft mainly discusses the situation that the Initiator is the IPv6 host. See section 5.3 for the situation where there is an IPv4 home network behind the Initiator. 4.3. 4over6 Concentrator 4over6 Concentrator represents the IPv4-IPv6 border router working as tunnel endpoint for the IPv6 hosts. Its IPv6 interface is connected to the IPv6 network, and its IPv4 interface is connected to the IPv4 Internet. When the Concentrator receives an encapsulated IPv4-in-IPv6 packet from the IPv6 side, it will decapsulated the packet by dropping the IPv6 header. If the decapsulated IPv4 packet is destined to the IPv4 Internet, then it'll be sent on the IPv4 interface. Else the packet is destined to another IPv6 host, then the Concentrator will encapsulate it by IPv6, using the IPv6 address of itself as the source address, and use the IPv4 destination address and the NSP to form the IPv6 destination address automatically. Note that if the Initiator uses the IPv4-mapped IPv6 address as the destination address for encapsulation, this type of packets won't go through the Concentrator. Cui, et al. Expires January 6, 2011 [Page 8] Internet-Draft Host 4over6 July 2010 When the Concentrator receives an IPv4 packet from the IPv4 side, it will check the destination address. For our concern, the destination will fall into the address pool for IPv6 hosts. Then the 4over6 Concentrator will encapsulate the packet by IPv6, using the IPv6 address of itself as the source address, and use the IPv4 destination address and the NSP to form the IPv6 destination address automatically. Then the IPv6 packet will be sent on the IPv6 interface. Cui, et al. Expires January 6, 2011 [Page 9] Internet-Draft Host 4over6 July 2010 5. Further Discussion 5.1. Technical advantage of Host 4over6 Since a 4over6 host uses a global IPv4 address, host 4over6 supports bidirectional communication between IPv4 Internet and a host in IPv6 access network. By coupling the IPv4 address and the IPv6 address of the IPv6 host, the encapsulation in the Concentrator can be simple and scalable. The Concentrator can automatically form the destination IPv6 address for encapsulation, rather than maintain a table of per-user IPv4-IPv6 address mapping and look it up for every encapsulation. 5.2. Application Scenario of Host 4over6 Since a host 4over6 support bidirectional communication between a host in IPv6 network and IPv4 Internet, this technology can provide the solution for data center networks or those hosts which need to provide IPv4 service in IPv6 access networks. In order to improve save the reuse rate of IPv4 address, host 4over6 can support dynamically reuse of a single IPv4 address between multiple hosts based on their dynamical requirement of communicating with IPv4 Internet. A 4over6 host can use IPv6 protocols (e.g. ND) to have an ordinary IPv6 address rather than 4over6 address when it starts up. When it needs to communicate with IPv4 Internet, it then requires a new 4over6 address from the 4over6 DHCPv6 to have a global IPv4 address in the short time it needs. Host 4over6 is mainly suited for IPv6 hosts that can get IPv4 addresses, such as legacy IPv4 users 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 Host 4over6 way 5.3. Home network consideration Host 4over6 is mainly facing IPv6 hosts. If the Initiator is a CPE with an IPv4 home network behind it, then the situation will be more complicated. One solution is to update the home network to support IPv6, and have each host in this network to get IPv4-Embedded address(The CPE can require an IPv6 block and distribute the addresses in home network, or working as an DHCP relay). If this can't be done, then a normal IPv4 NAT is required on the CPE. Hosts in home network will use IPv4 private addresses. Packets from home network will be translated by the IPv4 NAT, so as to use the global IPv4 address of the CPE as source address, and then use the tunnel Cui, et al. Expires January 6, 2011 [Page 10] Internet-Draft Host 4over6 July 2010 between the CPE and the Concentrator to reach IPv4 Internet. Cui, et al. Expires January 6, 2011 [Page 11] Internet-Draft Host 4over6 July 2010 6. References 6.1. Normative References [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. 6.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-08 (work in progress), May 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-04 (work in progress), March 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. [I-D.xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 (work in progress), January 2010. Cui, et al. Expires January 6, 2011 [Page 12] Internet-Draft Host 4over6 July 2010 Authors' Addresses Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: cy@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 Cui, et al. Expires January 6, 2011 [Page 13]