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]