Internet Engineering Task Force T. Yang Internet-Draft L. Li Intended status: Standards Track Q. Ma Expires: April 15, 2013 China Mobile Oct 12, 2012 IPv6 Transition Technologies Selection using DHCP/DHCPv6 draft-yang-v6ops-ipv6tran-select-00 Abstract Nowadays, many IPv6 transition technologies has been proposed, such as Dual-Stack, DS-Lite, 6rd and so on. An CPE may support some of them instead of only one. But ISPs usually deploy just an unique transition technology in an area, for example, under a BRAS/SR or in a MAN. So they must control all the CPEs to ues the exact transition tech through the CPEs' management system or configuring them before issuing to the customers. Another question is that if subscriber buy a new CPE from supermarket to substitute the one received from the ISP, he may not access internet because of the wrong configuration. To solve these problems,this document defines a new DHCP/DHCPv6 option named TRAN_TYPE which can control CPEs to select the appropriate IPv6 transition technology which ISP deployed instend of the CPEs' default configration. This method can also solve the configurating problem when various CPEs work together without a uniform configuration in advance. Status of this Memo This Internet-Draft is submitted to IETF 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 April 15, 2013. Copyright Notice Yang, et al. Expires April 15, 2013 [Page 1] Internet-Draft IPv6tran-select Oct 2012 Copyright (c) 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. DHCP Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DHCPv6 Solution . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Other questions . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Refrences . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Yang, et al. Expires April 15, 2013 [Page 2] Internet-Draft IPv6tran-select Oct 2012 1. Introduction Nowadays, many IPv6 transitioning technologies has been proposed such as Dual-Stack, DS-Lite, 6rd and so on. Each of them proposes individual requirment to the CPEs. To promote the competitive ability of products,the CPE manufacturers certainly will try to support more technologies as much as possible. Meanwhile, the operators tend to use single or less technologies. Moreover, users can buy and use their own equipments instead of using the one which operator gives them, that will bring the diversity of CPEs. Assume that an operator uses one transitioning strategy in its network. There are two ways to make the CPEs available. The first one is to make a pre-configuration for each CPE in advance. But, when the users modify the configuration or change to their own equipment, the connection will fail. The Second method is to deploy Network Management System (NMS) to configurate all the CPEs. Various CPEs from different manufactories usually need different NMS which means either the operator needs to maintains multiple NMS in their network or operator can only use one manufacturer's product in a subnet. What's worse, when users buy and use their own CPE instead of using the original one, there will be no any solutions to configurate correctly except visiting service. DHCP and DHCPv6 solutions are presented in this document to solve the problem mentioned above. By supporting this option, the operator can configurate the CPEs simple and directly by delivering DHCP or DHCPv6 options. 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]. 3. DHCP Solution DHCP protocol will be used during the configuration process of CPE in IPoE scenario. Here, a new option named OPTION_TRAN_TYPE is defined. This option is sent by a server to a CPE to affect the selection of transition strategy by the client. The format of the OPTION_TRAN_TYPE option is: Yang, et al. Expires April 15, 2013 [Page 3] Internet-Draft IPv6tran-select Oct 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code | length | mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: OPTION_TRAN_TYPE code OPTION_TRAN_TYPE (TBD). length 2. mode The value for the transition technology. The process of this operation is: 1. The DHCP module in CPE broadcasts the Discover Message. 2. The DHCP module in Server (such as BRAS/SR) replies the Offer Message. 3. CPE MUST send Request message with OPTION_TRAN_TYPE option code in option55[Parameter Request List, RFC2131,section 9.8] to Server. 4. Server replies ACK message with OPTION_TRA_TYPE option to CPE, which may allow or allocate a transition strategy (such as mode = 1). A server MAY include a TRAN_TYPE option in any DHCP message to control the transition strategy selection of the CPE, including Discover, Offer, Request, Reply, and Inform Messages. The server can also send the OPTION_TRA_TYPE option in Offer Message or ACK Message directly without the request OPTION code in Discover or Request Message from CPE. To avoid OPTION_TRAN_TYPE meanings ambiguity, the 'mode' field must be consisitent in any CPE and server. The list of all the transition technologies must be defined by IANA or other organizations. For example, the 'mode' field list is set as below. Yang, et al. Expires April 15, 2013 [Page 4] Internet-Draft IPv6tran-select Oct 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mode | transition tech. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Dual Stack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | DS-Lite | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | ... ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: meanings of mode field 4. DHCPv6 Solution In IPv6oE scenario, CPE must support DHCPv6 which can be used during the configuration process. As above, we can also define a new option named OPTION_TRAN_TYPE to unify the transition technology of CPE and server. This option is sent by a server to a CPE to affect the selection of transition strategy of the client. The format of the OPTION_TRAN_TYPE option is: 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-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: OPTION_TRAN_TYPE option-code OPTION_TRAN_TYPE (TBD). option-len 2. mode The value for the transition strategy. The process of this operation is: 1. The DHCPv6 module in CPE broadcasts the Solicit Message. 2. The DHCPv6 module in Server (such as BRAS/SR) replies the Yang, et al. Expires April 15, 2013 [Page 5] Internet-Draft IPv6tran-select Oct 2012 Advertise Message. 3. CPE MUST send Request message with OPTION_TRAN_TYPE option code in Option Request Option [RFC3115,section 22.7] to Server. 4. Server replies Confirm message with OPTION_TRAN_TYPE option to CPE, which may allow or allocate a transition strategy (such as mode = 1). A server MAY include a TRAN_TYPE option in any DHCPv6 message to control the transition strategy selection of the CPE, including Solicit, Advertise, Request, Confirm, Renew, Rebind, Information- Request Messages. The server can also send the OPTION_TRA_TYPE option in Advertise Message or Confirm Message directly without the request OPTION in Solicit or Request Message from CPE. To avoid OPTION_TRAN_TYPE meanings ambiguity, the 'mode' field must be consisitent in any CPE and server in the same way in DHCP. 5. Other questions 1. If there is a DHCP/DHCPv6 Relay between the CPE and server, it must forward the messages including this option transparently. 2. Why choose DHCP and DHCPv6 to take this important option, not just one of them? Because some of the transition technologies only use IPv4 or IPv6 in the CPEs' WAN interface. Obviously, if CPE choose 6RD as its default transition technology, it can only support DHCP. Contrarily, DS-Lite CPE only support IPv6 in its WAN in the default configuration. 3. Although DHCP/DHCPv6 must be used in IPoE scenario, it may not be launched in PPPoE network, which is a popular protocol in the fixed access networks. Then we must use other solutions to solve this problem. 6. Security Considerations The security problem is under disscussion. 7. IANA Considerations 1. IANA is requested to assign an option code from the "DHCP Option Yang, et al. Expires April 15, 2013 [Page 6] Internet-Draft IPv6tran-select Oct 2012 Codes" and "DHCPv6 Option Codes" Registry for OPTION_TRAN_TYPE. 2. IANA is also requested to assign a uniform serial number for the 'mode' field. 8. Refrences (1) RFC[2131] Dynamic Host Configuration Protocol (2) RFC[2132] DHCP Options and BOOTP Vendor Extensions (3) RFC[3315] Dynamic Host Configuration Protocol for IPv6(DHCPv6) Authors' Addresses Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: yangtianle@chinamobile.com Li Lianyuan China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: lilianyuan@chinamobile.com Qiongfang Ma China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: maqiongfang@chinamobile.com Yang, et al. Expires April 15, 2013 [Page 7]