| DHC Working Group | Y. Hu |
| Internet-Draft | ZTE Corporation |
| Intended status: Standards Track | Aug 11, 2011 |
DHCPV6 for dual-stack hosts
draft-hu-dhc-dhcpv6-for-dual-stack-hosts-01
A dual-stack host may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP).Network operators deploy seperate DHCPv4 servers and DHCPv6 servers,hosts get IPv4 parameters via DHCPv4 servers and IPv6 parameters via DHCPv6 servers. This document describes a solution,there is only a single intergrated DHCPv6 server deployed in the ISP network,hosts obtain both IPv4 and IPv6 configuration settings from this server.
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."
Copyright (c) 2011 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.
RFC4477 describes issues identified with dual IP version DHCP interactions and also promotes potential solutions to solve these issues.There are mainly two solutions:1/ seperate DHCP servers for IPv6 and IPv4; 2/ a single DHCPv6 server for both IPv6 and IPv4. The second solution may be to modify DHCPv6 to be able to return IPv4 information.This solution is hinted in the DHCPv6 specification[RFC3315]:"If there is sufficient interest and demand,integration can be specified in a document that extends DHCPv6 to carry IPv4 addresses and configuration information." This solution may allow DHCP for IPv4 to be completely replaced by DHCPv6 with additional IPv4 information options, for dual-stack nodes.
This solution would avoid redundancy and simplify management for servers. But as RFC4477 described,there are also a number of potential problems with this approach,the most important problem is:the IPv4 only nodes would not have any DHCP service available to them,DHCPv4 servers need to be configured anyway to support IPv4-only hosts.This problem also exists for the dual-stack hosts which can't obtain IPv4 information using DHCPv6,because the DHCPv6 client software on these hosts has not been modified and updated.
This document will develop the solution in details,deploying single DHCPv6 sever which can serve for both IPv6/IPv4 hosts or dual-stack hosts. The considered aspect of the solution include: host's implementation and behave/sever's implementation and behave/network's behave.
In this document, we focus on the specific solution for operating DHCP in a mixed (typically dual-stack) IPv4 and IPv6 environment within a single administrative domain.
The Chair said that they had discussed this solution years ago,but pretty much rejected it because it would add a lot of complexity and the functionality is only useful during the transitional period when hosts are running dual-stack. But the transitional period will last a very long time,maybe ten or more years. So£¬we should consider this solution again.
Actully,DHCPv6 is better designed than DHCPv4,it has many good machnism that DHCPv4 hasn't.For example, the Relay Agent Encapsulation Machnism discussed in draft-ietf-dhc-dhcpv4-relay-encapsulation-01.
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.
DHCP: Dynamic Host Configuration Protocol
DHCPv4: Dynamic Host Configuration Protocol for IPv4
DHCPv6: Dynamic Host Configuration Protocol for IPv6
CPE: Customer Premises Equipment
BRAS: Broadband Remote Access Server
This section will describe two typical scenarioes.
+------+------+
| DHCPv6 | A single DHCPv6 Server which maintains both
| Server | IPv4 and IPv6 setting for endusers(hosts).
+------+--/\--+
_________|__||_______
/ || \
| ISP Core Network |
\____________||_______/
| ||
| ||
+------+--\/--+
| BRAS(PE) | A BRAS or Provider Edge Router.
| | User management/DHCPv6 relay agent
+------+--/\--+
| ||
_________|__\/_____
/ \
| Access Network |
\____________/\_____/
| ||
| ||
+------+--\/--+
| CPE |
+------+--/\--+ /Dual-stack host obtain IPv4/IPv6 settings
| || ------| by sending a DHCPv6 request msg,and
_____|__\/__ | would receive a DHCPv6 reply msg
| dual-stack | | containing the parameters
| host | \which are requested.
|____________|
In the isp network, a DHCPv6 server would be deployed to config both IPv4 and IPv6 parameters for hosts. Dual-stack host can certainly obtain IPv6 settings using DHCPv6 protocol.If it wish to obtain IPv4 settings,it send a DHCPv6 request message containning the new options designed for IPv4,and the server also return a DHCPv6 reply message containing the parameters which are requested.
In this scenario,the dhcpv6 client software must be modified and updated to support that.
+------+------+
| DHCPv6 | A single DHCPv6 Server which maintains both
| Server | IPv4 and IPv6 setting for endusers(hosts).
+------+--/\--+ Can only process DHCPv6 messages.
_________|__||_______
/ || \
| ISP Core Network |
\____________||_______/
| ||
| || /
+------+--\/--+ ________ |The DHCPv4 msg send by host should be
| BRAS(PE) | | |translated to DHCPv6 msg and send to
| | | |Server.
+------+--/\--+ | |Also,the DHCPv6 msg replied by Server
| || |----|should be translated to DHCPv4 msg and
_________|__\/_____ | |returned to host.
/ \ | |
| Access Network | | |The point to do translation may be
\____________/\_____/ | |CPE,Access Node or BRAS.In this figure,
| || | \the msg be translated in CPE.
| || |
+------+--\/--+ ________|
| CPE |
+------+--/ \-+ / Dual-stack host can not send a DHCPv6
| ||| -------| request msg to obtain IPv4 settings.
_____|__\ /_ | It is the old type,can only send and
| dual-stack | \ receive DHCPv4 msgs to config IPv4 parameters
| host |
|____________|
In this scenario,the DHCPv6 client software on the host has not been modified and updated,the hosts can only send and receive DHCPv4 messages to config IPv4 parameters. But the server is DHCPv6 only,can only process DHCPv6 messages,so the DHCPv4 message send by host should be translated to DHCPv6 message in somewhere and then send to server.Also, the DHCPv6 message replied by Server should be translated to DHCPv4 message and then returned to host. The translation point may be CPE,Access Node or BRAS.
There would be 3 types of dual stack hosts:
Type 1:old type dual stack, having DHCPv4 client and DHCPv6 client,the DHCPv6 client was not modified.
Type 2:new type dual stack, having DHCPv4 client and DHCPv6 client,the DHCPv6 client has been modified and updated.
Type 3:DHCPv6 only client.
+------+------+ +------+------+
| DHCPv6 | | DHCPv4 |
| Client | | Client |
+------+------+ +------+------+
| |
+------+------+ +------+------+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +------+------+
| |
+------+----------------+------+
| Link Layer |
+------+----------------+------+
Hosts of this type have not modified the DHCPv6 client software,so they can not obtain IPv4 settings using DHCPv6 protocol£¬they can only use DHCPv4 protocol to get IPv4 parameters.
+---------+-----------+ +----+---+
| DHCPv6 | | DHCPv4 |
| Client | | Client |
+-----+------------+--+ +----+---+
+ + +
+-----+-------+ +-+----------+---+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +-------+--------+
| |
+------+-----------------+--------+
| Link Layer |
+------+-----------------+--------+
Hosts of type 2 can certainly get IPv4/IPv6 settings using DHCPv4/DHCPv6 client,they can also use DHCPv6 client to get IPv4 settings.
+------+----------------+------+
| DHCPv6 |
| Client |
+------+----------------+------+
| |
+------+------+ +------+------+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +------+------+
| |
+------+----------------+------+
| Link Layer |
+------+----------------+------+
Hosts of type 3 have only DHCPv6 client, they obtain both IPv6 settings and IPv4 settings using the DHCPv6 only client.But this type is the future type, we will mainly disscuss the type 1 and type 2.
+---------------+ +----------------+
| IPv6 settings | | IPv4 settings |
| ----------- | | ------------ |
| |IPv6 prefix| | | |IPv4 Address| |
| ----------- | | ------------ |
| ----------- | | ----------- |
| | DNS | | | | DNS | |
| ----------- | | ----------- |
| ... | | ... |
| | | |
+------+--------+ +--------+-------+
| |
| |
+-----------------------------------+
| -------------- -------------- |
| |IPv6 Related | | IPv4 Related | |
| | Strategy | | Strategy | |
| -------------- -------------- |
| Strategy Management |
+-----------------------------------+
| |
+------+--------------------+-------+
| GENERAL DHCPv6 MESSAGE PROCESS |
| |
+------+--------------------+-------+
The servers are DHCPv6 only,they can only process DHCPv6 messages,so a general DHCPv6 message process modual must be implemented.
The servers must maintain both ipv6 and ipv4 settings for hosts,these settings may be:IPv6 prefixs which would be designated or allocated,IPv4 address pool,information about DNS, and so on.
A Strategy Management Modual should be implemented to decide how to designate or allocate IP settings for hosts.There would be seperate strategy for IPv6 or IPv4,and also common strategy for both IPv6 and IPv4.
If an ISP has deployed a DHCPv6 server in it's network,which would serve for dual stack hosts,and the hosts can be divided into Type 1 and Type 2.
Hosts of Type 1 would send DHCPv6 messages to request IPv6 parameters and send DHCPv4 messages to request IPv4 parameters,if the CPE in home network can't translate the DHCPv4 messages to DHCPv6 ones,the messages must be translated in the ISP network, may be in Access Node or BRAS.
Consider a host of Type 2,how dose it know to request IPv4 settings using DHCPv4 or DHCPv6? There are two possible solutions:1/the strategy been manually configured in host; 2/a mechanism for the ISP network to notify the host,like the mechanism using the M bit and O bit in RA message(RFC2461 section4.2).
In RFC3315 and other RFCs related to DHCPv6,many options have been defined to carry IPv6 information and parameters, but there are no DHCPv6 options been defined to carry IPv4 settings,so new DHCPv6 options need be defined to carry IPv4 information such as IPv4 address.
The new options will be defined in other document.
In Figure 2, the protocol translation was executed in CPE, in this section,we will disccuss the scenario where BRAS do the protocol translation.
+------+------+
| DHCPv6 |
| Server |
+------+--/\--+
_________|__||_______
/ || \
| ISP Core Network |
\____________||_______/
| ||
| ||------DHCPv6 message
+------+--\/--+
| BRAS(PE) |
| | ------Protocol translation
+------+--/ \-+
| |||------DHCPv4 message
_________|__\ /____
/ \
| Access Network |
\____________/ \____/
| |||------DHCPv4 message
| |||
+------+--\ /-+
| CPE |
+------+--/ \-+
| |||------DHCPv4 message
_____|__\ /_
| dual-stack |
| host |
|____________|
The DHCPv4 messages send by hosts arrive at the BRAS device,then BRAS translates the DHCPv4 messages to DHCPv6 correspondent ones and send to the DHCPv6 server.
The translation can also be executed in Access Node.
There are DHCP options defined to identify the remote connection of the circuit or used as a host identifier;these options are defined seperately for DHCPv6 and DHCPv4.For example:RFC3046 defined DHCPv4 option 82(Relay Agent Imformation Option) and 2 suboptions(Agent Circuit ID Sub-option/Agent Remote ID Sub-option),RFC3993 defined a sub-option of option82(Subscriber-ID Suboption),while RFC4649 defined DHCPv6 option 37(Relay Agent Remote-ID Option) and RFC4580 defined DHCPv6 option 38(Relay Agent Subscriber-ID Option).
These options are added by the DHCP relay agent and may be processed by DHCP server.When the DHCP protocol translation be executed, these options should be processed carefully.
TBD.
TBD.
Thanks for the authors of RFC4477.
| [RFC3046] | Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC3993] | Johnson, R., Palaniappan, T. and M. Stapp, "Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 3993, March 2005. |
| [RFC4477] | Chown, T., Venaas, S. and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006. |
| [RFC4649] | Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006. |
| [RFC4580] | Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 2006. |