Network Working Group C. Xie Internet-Draft Q. Sun Intended status: Standards Track China Telecom Expires: January 9, 2014 Y. Lee Comcast T. Tsou Huawei Technologies (USA) Y. Chen Tsinghua University July 8, 2013 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Lightweight 4over6 draft-sun-softwire-lw4over6-dhcpv6-00 Abstract Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is an extension to DS-Lite which moves the Network Address Translation function from the DS-Lite AFTR to the B4. It can be deployed in a DS-Lite network to gradually reduce the load of Carrier Grade NAT in the AFTR. However, when DS-Lite and lw4over6 co-exist in the same network, B4 elemtns and lwB4 elements may want to signal the DHCPv6 server the type of AFTR (i.e. AFTR or lwAFTR) they request. In this memo, a new DHCPv6 option is proposed for lwB4 element to request the IPv6 address of its corresponding lwAFTR. 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 9, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the Xie, et al. Expires January 9, 2014 [Page 1] Internet-Draft DHCPv6 Option for lw4over6 July 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 3 4. The lwAFTR-Name DHCPv6 Option . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Xie, et al. Expires January 9, 2014 [Page 2] Internet-Draft DHCPv6 Option for lw4over6 July 2013 1. Introduction Lightweight 4over6 (lw4o6) [I-D.ietf-softwire-lw4over6] defines a model for providing IPv4 access over an IPv6 network in which the Network Address Translation (NAT) function is performed by the Customer-Premises Equipment (CPE) instead of being centralized on a Carrier-Grade NAT (CGN). It removes the requirement for a Carrier Grade NAT function in the AFTR, and reduces the amount of centralized state in the AFTR. The DHCPv4 over DHCPv6 Transport [I.D-ietf-dhc-dhcpv4-over-dhcpv6] and Dynamic Host Configuration Protocol (DHCP) Option for Port Set [I.D-sun-dhc-port-set-option] can be used for lwB4 to be provisoned with the public IPv4 address and port set. To discover the lwAFTR's FQDN, [I-D.ietf-softwire-lw4over6] re-uses the DS-Lite DHCPv6 option defined in [RFC6334]. However, for operators who have deployed DS- Lite and will deploy lw4over6 in the same network using the same DHCPv6 option, the DHCPv6 server will not be able to distinguish between DS-Lite subscriber and lw4over6 subscriber. In this memo, we define a new DHCPv6 option for lwB4 [I-D.ietf-softwire-lw4over6] to request the DHCPv6 server its corresponding lwAFTR. This new DHCPv6 option enables the DHCPv6 server to distinguish between DS-Lite subscriber and lw4over6 subscriber and offer the requested resources to the subscribers. This removes the requirement to pre-provision the subscriber type (i.e., DS-Lite or lw4over6) in the provision system. This option is particularly helpful in a scenario where operators offer both DS-Lite and lw4over6 in the same network. 2. Terminology 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]. Terminology defined in [I-D.ietf-softwire-lw4over6] is used extensively in this document. 3. Application Scenario There are several possible deployment scenarios in which DS-Lite and lw4over6 co-exist in the same network. In scenario 1, DS-Lite and lw4over6 are deployed in the same AFTR (depicted in Figure1). Xie, et al. Expires January 9, 2014 [Page 3] Internet-Draft DHCPv6 Option for lw4over6 July 2013 +---------------+--------------| + | | +---------+ +------+---+ +--+--+ | | Host | | LW 4over6| | | | | |--| Initiator| ======-| BNG | === +-------------+ +-----------+ +---------+ +----------+ +--|--+ |LW 4over6 | | IPv4 | | lwAFTR | | Internet | +---------+ +------+---+ +--+--+ |DS-Lite AFTR | | | | Host |--| DS-Lite | =======| | ====+-------------+ +-----------+ | | | B4 | | BNG | | +---------+ +----------+ +--|--+ | + | | +---------------+--------------+ Figure 1: DS-Lite Coexistence scenario with Integrated AFTR The AFTR needs to distinguish the traffic from two transition mechanisms. The first option is to distinguish using the client's source IPv4 address. Two transition mechanisms can share the same tunnel endpoint address. However, this requires the network element to examine every packet and may introduce significant overhead to the AFTR element. The second option is to use separate tunnel endpoint addresses for DS-Lite and lw4over6. This can be easily supported in the network element. The second option is more practical and recommended. This option requires the B4 element to discover the AFTR's FQDN and lwB4 element to discover lwAFTR's FQDN. In scenario 2, DS-Lite AFTR and lw4over6 lwAFTR do not co-locate in the same network element (as depicted in Figure2) and are usually configured with different tunnel endpoint address. Similar to scenario 1 option 2, lwB4 also needs to discover a the lwAFTR's FQDN rather than the AFTR's FQDN. +---+---------------+-----------------| + | | +---------+ +------+---+ +------+-----+ | | Host | | LW 4over6| | BNG | | | |--| Initiator| ======-|DS-Lite AFTR| === +------------+ +-----------+ +---------+ +----------+ +------+-----+ |LW 4over6 | | IPv4 | | lwAFTR |---| Internet | +---------+ +------+---+ +------+-----+ | | | | | Host |--| DS-Lite | =======| BNG | ====+------------+ +-----------+ | | | B4 | |DS-Lite AFTR| | +---------+ +----------+ +------+-----+ | + | | +-------------------+-----------------+ Figure 2: DS-Lite Coexistence scenario with Seperated AFTR Xie, et al. Expires January 9, 2014 [Page 4] Internet-Draft DHCPv6 Option for lw4over6 July 2013 There are two possible solutions for an lw4over6 lwB4 to discover its the lwAFTR's IPv6 address. 1. Subscriber Type Pre-configuration In this approach, the operator must pre-provision the subscriber type (e.g. Alice is lw4over6 subscriber and Bob is DS-Lite subscriber) in the provisioning system, this information will be used to instruct the DHCPv6 server to offer AFTR or lwAFTR to the subscriber in the DHCPv6 reply. +----+-----+ +----+-----+ +------+------+ +------+------+ | B4 | | lwB4 | | BNG | | AAA | | DS-Lite | | lw4over6 | ======-|DHCPv6 Server| | | +----+-----+ +----+-----+ +------+------+ +------+------+ | | dhcpv6 option64 | | | |-------------------->| subscriber type | | | | identification | | | |--------------------->| | | | lw4over6.example.com | | |lw4over6.example.com |<---------------------| | |<--------------------| | | dhcpv6 option64 | | |----------------------------------->| | | | subscriber type | | | identification | | |--------------------->| | | dslite.example.com | | |<---------------------| | dslite.example.com | | |<-----------------------------------| | Figure 3: Workflow of Subscriber Type Pre-configuration This approach requires operators to pre-provision static subscriber information in the provisioning system. This requires modification in the provisioning system to include this new subscriber information. Besides, when a subscriber migrates from DS-Lite to lw4over6, this will require update in the provisioning system. 2. lw4over6 DHCPv6 option This approach is to use a new DHCPv6 option for lw4over6 lwB4. The DHCPv6 server can identify a lw4over6 subscriber by the lw4over6 DHCPv6 request and offer lwAFTR's FQDN (depicted in the Figure4) to the lwB4 element. Xie, et al. Expires January 9, 2014 [Page 5] Internet-Draft DHCPv6 Option for lw4over6 July 2013 +----+-----+ +----+-----+ +------+------+ | B4 | | lwB4 | | BNG | | DS-Lite | | lw4over6 | =========-|DHCPv6 Server| +----+-----+ +----+-----+ +------+------+ | | dhcpv6 option(lw4over6)| | |----------------------->| | | lw4over6.example.com | | |<-----------------------| | | | dhcpv6 option64 | |-------------------------------------->| | dslite.example.com | |<--------------------------------------| Figure 4: Workflow of lw4over6 DHCPv6 option The new DHCPv6 option enables the DHCPv6 server to offer the lwAFTR's FQDN to lwB4, the provisioning system does not need to be upgraded to identify the subscriber's type. At migration, operators simply configure the B4 element to support NAT and this new DHCPv6 option, and this will be done. Therefore, a new lw4over6 DHCPv6 option is recommended. 4. The lwAFTR-Name DHCPv6 Option The format of lwAFTR-Name option is the same as DS-Lite AFTR-Name option with a new option-code. It is shown in Figure5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | OPTION_lwAFTR_NAME: X | option-len | +-------------------------------+-------------------------------+ | | | tunnel-endpoint-name (FQDN) | | | +---------------------------------------------------------------+ OPTION_lwAFTR_NAME: TBD option-len: Length of the tunnel-endpoint-name field in octets. tunnel-endpoint-name: A fully qualified domain name of the lwAFTR tunnel endpoint. Xie, et al. Expires January 9, 2014 [Page 6] Internet-Draft DHCPv6 Option for lw4over6 July 2013 Figure 5: Format of lwAFTR-Name DHCPv6 Option Format The server behavior and the client behavior is exactly the same with DS-Lite AFTR-Name DHCPv6 Option ([RFC6334] section 4 and section5). 5. IANA Considerations IANA is requested to allocate single DHCPv6 option code referencing this document, delineating OPTION_lwAFTR_NAME. 6. Acknowledgements The authors would like to thank the following individuals who have participated in the drafting, review, and discussion of this memo: TO BE COMPLETED 7. References 7.1. Normative References [I-D.ietf-pcp-port-set] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", draft-ietf-pcp-port-set-00 (work in progress), March 2013. [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-00 (work in progress), April 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. Xie, et al. Expires January 9, 2014 [Page 7] Internet-Draft DHCPv6 Option for lw4over6 July 2013 7.2. Informative References [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. Authors' Addresses Chongfeng Xie China Telecom P.R.China Phone: 86 10 58552116 Email: xiechf@ctbri.com.cn Qiong Sun China Telecom P.R.China Phone: 86 10 58552936 Email: sunqiong@ctbri.com.cn Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 USA Email: yiu_lee@cable.comcast.com Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1 408 330 4424 Email: Tina.Tsou.Zouting@huawei.com Xie, et al. Expires January 9, 2014 [Page 8] Internet-Draft DHCPv6 Option for lw4over6 July 2013 Yuchi Chen Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: peng-wu@foxmail.com Xie, et al. Expires January 9, 2014 [Page 9]