Network Working Group Y. Chen Internet-Draft J. Wu Intended status: Standards Track Tsinghua University Expires: March 01, 2014 X. Tang G. Zhou China Unicom Research Institute August 28, 2013 Gateway-Initiated 4over6 Deployment draft-chen-softwire-gw-init-4over6-02 Abstract Gateway-Initiated 4over6 is a variant of Lightweight 4over6. A Lightweight B4 in Lightweight 4over6 mechanism is a router which acts as a tunnel initiator for the IPv4-in-IPv6 tunnel. This mechanism mainly focuses on the scenario in which an IPv4 address and related configuration information is configured to the device behind Lightweight B4. Gateway-Initiated 4over6 uses the full IPv4 address rather than a shared address. This enables an unmodified end server or host that is behind a Lightweight B4 to get access to the IPv4 Internet through an IPv6 network. 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 March 01, 2014. Copyright Notice Copyright (c) 2013 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 Chen, et al. Expires March 01, 2014 [Page 1] Internet-Draft Gateway-Initiated 4over6 August 2013 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 4. GI-4over6 Architecture . . . . . . . . . . . . . . . . . . . 3 5. GI-4over6 in ICP Network . . . . . . . . . . . . . . . . . . 4 5.1. Static Configuration to Establish Tunnel . . . . . . . . 4 5.2. Dynamic Configuration to Establish Tunnel . . . . . . . . 5 6. 4over6 Gateway Data Plane Behaviors . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In typical use case of Lightweight 4over6 (Lw4over6) ([I-D.ietf-softwire-lw4over6]), IPv4 address (and available port set) is provisioned to the Lightweight B4 (LwB4), the tunnel initiator. However, there are some cases in which IPv4 address and related configuration are not be provisioned to LwB4, but the end device behind it. There is a typical scenario in this case, that is Lw4over6 is used in an Internet Content Provider (ICP) network, and the device behind LwB4 is an ICP server. Gateway-Initiated 4over6 (GI-4over6) is a variant of Lw4over6. It mainly focuses on the scenario in which an IPv4 address and related configuration information is provisioned to the device behind LwB4. Provisioning full address is preferred to provisioning shared address (port-restricted address) in GI-4over6. It enables an unmodified IPv4 device that behind the LwB4 to get access to IPv4 Internet through IPv6 network. 2. Terminology This document uses the terms defined in [I-D.ietf-softwire-lw4over6]. Chen, et al. Expires March 01, 2014 [Page 2] Internet-Draft Gateway-Initiated 4over6 August 2013 The other terms used are defined as follows: o End device: The device in the IPv4 network behind the 4over6 gateway. It can be an IPv4-only or a dual-stack device. o End server: The end device in an ICP network is supposed to be an end server. o 4over6 gateway: The dual-stack gateway device located at the border of both IPv4 and IPv6 networks. It should be configured with an IPv4 address and the IPv6 address of LwAFTR, and act as the LwB4 on the data plane. 3. 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]. 4. GI-4over6 Architecture The general architecture of GI-4over6 is illustrated as Figure 1. The 4over6 gateway is a dual-stack gateway device which establishes IPv4-in-IPv6 tunnel with the Lightweight Address Family Transition Router (LwAFTR) and performs the LwB4 function on data plane. The LwAFTR is a dual-stack border router deployed at the edge of the IPv6 network and the Internet. The IPv4 network can be either an ICP network, or a customer network of an ISP. The IPv6 network can be either an ICP access network or an ISP access network. Either or both of these networks could be dual-stack. +---------------------+ +-------------------------+ | +-------------+ +-+----------+-+ +-+--------+ +----------+ | | | | 4over6 | IPv4-in-IPv6 tunnel | | | | | | End device +---+ Gateway |=====================| LwAFTR +---+ Internet | | | | | (LwB4) | | | | | | +-------------+ +-+----------+-+ IPv6 Network +-+--------+ +----------+ | IPv4 network | | | +---------------------+ +-------------------------+ Figure 1 GI-4over6 Architecture The 4over6 gateway is configured with an public IPv4 address on its Chen, et al. Expires March 01, 2014 [Page 3] Internet-Draft Gateway-Initiated 4over6 August 2013 "left" side, an IPv6 address on its "right" side, either by static (in ICP network) or dynamic (in customer network) way. It is also configured with the IPv6 address of LwAFTR as the address of the tunnel endpoint. Each end device has a public IPv4 address with all ports (0-65535) available, hence there is no need to implement NAPT44 on the 4over6 gateway. One typical scenario of this framework is that using Lw4over6 in an ICP network. There might be other similar scenarios, and they could be included in this document in the future. 5. GI-4over6 in ICP Network Considering an ISP that plans to update its network to IPv6, one of the major issues it may be faced with is the update of its ICP network. If the ICP network is to be updated to run IPv6, the server in the network should also be updated to support IPv6. Obviously it is not trivial to update upper layer service running on the server to support a network layer protocol. It's ideal if the ICP access network is updated to IPv6, but still capable of providing the server with access to IPv4 Internet, meanwhile the ICP network (and the servers inside) stay unmodified. In this scenario, the end server has already been configured with a full public IPv4 address, and it's expected to stay unchanged during the update of the network. It has also been configured with other IPv4 related configurations like the network mask of the IPv4 ICP network, the IPv4 address of DNS server, etc. The 4over6 gateway has already been configured with the routing to the end server. It MUST establish the IPv4-in-IPv6 tunnel with the LwAFTR, in order to forward the IPv4 traffics between the end server and the IPv4 Internet. The establishment of the IPv4-in-IPv6 tunnel could be done either by static - the most likely way - or dynamic configuration. 5.1. Static Configuration to Establish Tunnel The LwAFTR is statically configured with the binding of the public IPv4 address of the end server, the available port set (0-65535), and IPv6 address of the 4over6 gateway in its binding table statically. In a more general case, the addresses of servers behind the same 4over6 gateway can aggregate. And as the 4over6 gateway and the LwAFTR are both managed by the ISP, people who configure the LwAFTR are usually aware of the routing to the ICP network behind the 4over6 gateway. Hence the LwAFTR can be configured with the following binding: the network prefix of the ICP network, the available port Chen, et al. Expires March 01, 2014 [Page 4] Internet-Draft Gateway-Initiated 4over6 August 2013 set (0-65535), and IPv6 address of the 4over6 gateway. 5.2. Dynamic Configuration to Establish Tunnel Dynamic configuration could be adopted in case the static configuration is not feasible or practical. The 4over6 gateway MUST inform the LwAFTR of all of its IPv4 routing information (i.e. the whole IPv4 routing table). The detail of this process could be clarified in related draft in future. Once the LwAFTR received the routing information from the 4over6 gateway, it should add the entry(s) into its binding table, with the given routing information. The binding may looks like: the ICP network prefix, available port set (0-65535), the IPv6 address of the 4over6 gateway. 6. 4over6 Gateway Data Plane Behaviors The 4over6 gateway must perform the LwB4 function on the data plane. The data plane behavior of 4over6 gateway uses the description in section 5.2 of [I-D.ietf-softwire-lw4over6]. However, there is no need to implement NAPT44 function on 4over6 gateway, because each end server behind the 4over6 gateway has a public IPv4 address with all ports available. 7. Security Considerations TBD 8. IANA Considerations This document does not include an IANA request. 9. References 9.1. Normative References [I-D.ietf-softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", draft-ietf-softwire-lw4over6-01 (work in progress), July 2013. 9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chen, et al. Expires March 01, 2014 [Page 5] Internet-Draft Gateway-Initiated 4over6 August 2013 Authors' Addresses Yuchi Chen Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86 10 6278 5822 Email: chenycmx@gmail.com 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 Xiongyan Tang China Unicom Research Institute 33 Erlong Road, Xicheng District Beijing 100032 P.R.China Phone: +86 10 6652 2558 Email: tangxy@chinaunicom.cn Guangtao Zhou China Unicom Research Institute 9 Shouti South Road, Haidian District Beijing 100048 P.R.China Phone: +86 10 6789 9600 Email: zhouguangtao@chinaunicom.cn Chen, et al. Expires March 01, 2014 [Page 6]