Network Working Group Y. Chen Internet-Draft J. Wu Intended status: Informational Tsinghua University Expires: August 28, 2013 X. Tang China Unicom Research Institute February 24, 2013 Gateway-Initiated 4over6 Deployment draft-chen-softwire-gw-init-4over6-01 Abstract Gateway-Initiated 4over6 (GI-4over6) is a variant of 4over6 mechanisms which include Public 4over6 ([I-D.ietf-softwire-public-4over6]) and Lightweight 4over6 ([I-D.cui-softwire-b4-translated-ds-lite]), and it's designed to satisfy the certain tunnel-based access scenario. The GI-4over6 extends the On-Link Client Relay Agent (LCRA) that is defined in [I-D.ietf-dhc-dhcpv4-over-ipv6] and thus makes it enabled to help gateway device perform 4over6 CE function described in [I-D.ietf-softwire-public-4over6], and lwB4 function described in [I-D.cui-softwire-b4-translated-ds-lite], while the public IPv4 addresses (and available ports) are assigned to the end hosts that behind the gateway device. 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 August 28, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Chen, et al. Expires August 28, 2013 [Page 1] Internet-Draft Gateway-Initiated 4over6 February 2013 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. GI-4over6 Architecture . . . . . . . . . . . . . . . . . . . . 6 5. 4over6 Gateway Behaviors . . . . . . . . . . . . . . . . . . . 7 5.1. Public 4over6 Mode . . . . . . . . . . . . . . . . . . . . 7 5.2. Lightweight 4over6 Mode . . . . . . . . . . . . . . . . . 7 6. Relative Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Consideration for IPv4 Gateway of Customer End Hosts . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Chen, et al. Expires August 28, 2013 [Page 2] Internet-Draft Gateway-Initiated 4over6 February 2013 1. Overview Gateway-Initiated 4over6 (GI-4over6) is a variant of 4over6 mechanisms which include Public 4over6 ([I-D.ietf-softwire-public-4over6]) and Lightweight 4over6 ([I-D.cui-softwire-b4-translated-ds-lite]), and it's designed to satisfy the certain tunnel-based access scenario. [I-D.ietf-dhc-dhcpv4-over-ipv6] describes a way for communication between traditional DHCPv4 clients with DHCPv4 servers over IPv6-only transport. The On-Link Client Relay Agent (LCRA) defined in the draft can serve any DHCPv4 client on the same link. If the 4over6 tunnel initiator is the gateway device, and if the DHCP client on the end host behind the gateway device wants to communicate with the remote DHCP server on the tunnel concentrator, and get IPv4 provision from the tunnel concentrator directly, the gateway device must perform the LCRA function to relay the DHCP messages between the end hosts and the remote DHCP server. When it comes to the lightweight 4over6 scenario, if the end host cannot perform as a lwB4, but still wants to get an public IPv4 address, then the data plane function of lwB4 must be performed by the gateway device, and the LCRA on the gateway must extract the port-set information (i.e. the DHCP Port-Set Option defined in [I-D.sun-dhc-port-set-option]) from the DHCP response from the DHCP server, and help the gateway device maintains the state of binding between the identifier of the end host and the port-set. Chen, et al. Expires August 28, 2013 [Page 3] Internet-Draft Gateway-Initiated 4over6 February 2013 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]. Chen, et al. Expires August 28, 2013 [Page 4] Internet-Draft Gateway-Initiated 4over6 February 2013 3. Terminology This document uses the terms defined in [I-D.ietf-dhc-dhcpv4-over-ipv6], [I-D.ietf-softwire-public-4over6], [I-D.cui-softwire-b4-translated-ds-lite] and [I-D.sun-dhc-port-set-option]. The other terms used are described as follows: Customer End Host: The end host in the customer IPv4 network behinds the 4over6 Gateway. It should perform as a DHCP client and communicate with DHCP server on the tunnel concentrator through DHCPv4 over IPv6 mechanism. 4over6 Gateway: The gateway device located at the border of the customer IPv4 network and the IPv6 ISP network. In the Public 4over6 scenario, the 4over6 Gateway should perform the 4over6 CE function. And in the Lightweight 4over6 scenario, the 4over6 Gateway should act as the LwB4. 4over6 Tunnel Concentrator: The border router located between the IPv6 ISP network and the Internet. In the Public 4over6 scenario, the 4over6 Tunnel Concentrator refers to 4over6 CE. And in the Lightweight 4over6 scenario, the 4over6 Tunnel Concentrator refers to LwAFTR. EX-LCRA: The LCRA with the extended function described in the document. It is assumed to be co-located with the 4over6 Gateway. It could be deployed in ohter ways depending on the actual deployment requirements, and they are out of the scope of this document. Chen, et al. Expires August 28, 2013 [Page 5] Internet-Draft Gateway-Initiated 4over6 February 2013 4. GI-4over6 Architecture The general architecture of GI-4over6 is illustrated as Figure 1. The Customer End Host in the Customer IPv4 Network could be an IPv4 or dual-stack host. The 4over6 Gateway is a dual-stack gateway device provided by the ISP, and has been already enabled to support EX-LCRA. +------------------+ +-------------------------+ | +----------+ | | | | | Customer | +-+-----------+-+ +-+-------------+ +----------+ | | End Host +---+ 4over6 | IPv4-in-IPv6 tunnel | 4over6 Tunnel | | | | +----------+ | Gateway |=====================| Concentrator +---+ Internet | | +----------+ | (with EX-LCRA)| | (with TSV) | | | | | Customer +---+ | IPv6 ISP Network +-+-------------+ +----------+ | | End Host | +-+-----------+-+ | | +----------+ | | | | Customer IPv4 | +-------------------------+ | Network | +------------------+ Figure 1 GI-4over6 Architecture There are two major scenarios: Public 4over6 Scenario and Lightweight 4over6 Scenario. We assume that in both of the scenario the Customer End Host needs to get public IPv4 access, and the DHCP client on the Customer End Host has to stay traditional (i.e. without any extension to support DHCPv4 over IPv6 transport or Port-Set Option). Hence the actual 4over6 tunnel initiator should be the 4over6 Gateway. And in both scenarios, we assume that there is a 4over6 tunnel that has been established already between the 4over6 Gateway and the 4over6 Tunnel Concentrator. Chen, et al. Expires August 28, 2013 [Page 6] Internet-Draft Gateway-Initiated 4over6 February 2013 5. 4over6 Gateway Behaviors The 4over6 Gateway should act differently in the two major scenarios, which means that the 4over6 Gateway has 2 modes of behaviors. We name them with Public 4over6 Mode and Lightweight 4over6 Mode. The EX-LCRA MUST function in either of the two modes at the same time, depending on the actual scenario it is in. 5.1. Public 4over6 Mode In the Public 4over6 Scenario, the 4over6 Gateway must perform the 4over6 CE function on the data plane. The Customer End Hosts should get the full public IPv4 addresses directly from the TSV, not any other DHCP server. Therefore, the EX-LCRA must perform the LCRA function described in the Section 6 of [I-D.ietf-dhc-dhcpv4-over-ipv6]. Note that if there is a Port-Set Option in any of the DHCP message going through, the EX-LCRA MUST discard the message. 5.2. Lightweight 4over6 Mode In the Lightweight 4over6 Scenario, the 4over6 Gateway must perform the LwB4 function on the data plane. The Customer End Hosts should get the public IPv4 addresses and available ports from the TSV, not any other DHCP server. In this case, the EX-LCRA must perform the LCRA function described in the Seciton 6 of [I-D.ietf-dhc-dhcpv4-over-ipv6], and the EX-LCRA MUST also handle the Port-Set Option of the DHCP messages. For the DHCPDISCOVER message sent by Customer End Host, the EX-LCRA MUST add the Option Code of the Port-Set Option into the DHCP Parameter Request List Option (Option Code 55) of the message. For the DHCPOFFER message sent by TSV, the EX-LCRA MUST extract the Port-Set Option from the message, and store the match of Client Identifier and the values of Port Set Index and Port Set Mask of the Port-Set Option in a binding table. The EX-LCRA MAY erase the Port- Set Option from the DHCPOFFER message then. Note that if the received DHCPOFFER message doesn't include the Port-Set Option, the EX-LCRA MUST discard the message. For the DHCPREQUEST message sent by Customer End Host, the EX-LCRA should look into the binding table and search for the Client Identifier carried by the message. If there is an entry that matches, the EX-LCRA should get the values of the Port Set Index and Port Set Mask from the entry, and add the Port-Set Option with theses values into the DHCPREQUEST message. Chen, et al. Expires August 28, 2013 [Page 7] Internet-Draft Gateway-Initiated 4over6 February 2013 For the DHCPACK message sent by TSV, the EX-LCRA MUST extract the Port-Set Option from the message, and look into the binding table and search for the Client Identifier carried by the message. If there is an entry that matches, the EX-LCRA should update the values of the Port Set Index and Port Set Mask of the entry with the values of the corresponding field of the Port-Set Option in the DHCPACK message, and enable the binding on the data plane of the 4over6 Gateway. Chen, et al. Expires August 28, 2013 [Page 8] Internet-Draft Gateway-Initiated 4over6 February 2013 6. Relative Considerations 6.1. Consideration for IPv4 Gateway of Customer End Hosts As the TSV is co-located with the 4over6 Tunnel Concentrator and is not in the local IPv4 network, it may not include the correct IPv4 address of the 4over6 Gateway in the DHCP Router Option (Option Code 3), which is the actual gateway and access entrance for the Customer End Hosts. Thus the outbound IPv4 sessions on the Customer End Host may fail because of the lack of default gateway information. In order to get rid of this issue, the EX-LCRA may modify the value of the DHCP Router Option of the DHCP response messages from the remote DHCP server, and input the IPv4 address of the 4over6 Gateway on the LAN side as the value of the DHCP Router Option, when the messages are going to pass through. Chen, et al. Expires August 28, 2013 [Page 9] Internet-Draft Gateway-Initiated 4over6 February 2013 7. Security Considerations The security considerations of the document is well described in all the references, and the document raises barely new security issues. Chen, et al. Expires August 28, 2013 [Page 10] Internet-Draft Gateway-Initiated 4over6 February 2013 8. References 8.1. Normative References [I-D.cui-softwire-b4-translated-ds-lite] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", draft-cui-softwire-b4-translated-ds-lite-10 (work in progress), February 2013. [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in progress), September 2012. [I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public IPv4 over IPv6 Access Network", draft-ietf-softwire-public-4over6-04 (work in progress), October 2012. [I-D.sun-dhc-port-set-option] Sun, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, "Dynamic Host Configuration Protocol (DHCP) Option for Port Set Assignment", draft-sun-dhc-port-set-option-00 (work in progress), October 2012. 8.2. Informative 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. [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. Chen, et al. Expires August 28, 2013 [Page 11] Internet-Draft Gateway-Initiated 4over6 February 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 Chen, et al. Expires August 28, 2013 [Page 12]