One document matched: draft-hu-dhc-dhcpv6-for-dual-stack-hosts-01.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!--<!DOCTYPE rfc SYSTEM "rfc4748.dtd"> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3046 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc3993 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993.xml'>
<!ENTITY rfc4477 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4477.xml'>
<!ENTITY rfc4649 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'>
<!ENTITY rfc4580 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-hu-dhc-dhcpv6-for-dual-stack-hosts-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<front>
<title>DHCPV6 for dual-stack hosts</title>
<author initials="Y" surname="Hu" fullname="Yuxing Hu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>4F,RD Building 2,Zijinghua Road</street>
<region>Yuhuatai District,Nanjing 210012</region>
<country>P.R.China</country>
</postal>
<email>hu.yuxing@zte.com.cn</email>
</address>
</author>
<date day='11' month='Aug' year="2011"/>
<area>Internet</area>
<workgroup>DHC Working Group</workgroup>
<keyword>Request for Comments</keyword>
<keyword>RFC</keyword>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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<xref target="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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
</section>
<section title="Conventions used in this document">
<t>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.</t>
<section title="Abbreviations">
<t>DHCP: Dynamic Host Configuration Protocol</t>
<t>DHCPv4: Dynamic Host Configuration Protocol for IPv4</t>
<t>DHCPv6: Dynamic Host Configuration Protocol for IPv6</t>
<t>CPE: Customer Premises Equipment</t>
<t>BRAS: Broadband Remote Access Server</t>
</section>
<section title="Definitions and Terminology">
<t> </t>
</section>
</section>
<section title="Scenario and Network architecture">
<t> This section will describe two typical scenarioes.</t>
<section title="Get all ip settings using dhcpv6 protocol">
<figure anchor="Figure 1" title="GET IP SETTINGS USING DHCPV6 PROTOCOL">
<artwork align="center">
<![CDATA[
+------+------+
| 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.
|____________|
]]>
</artwork>
</figure>
<t>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.</t>
<t>In this scenario,the dhcpv6 client software must be modified and updated to support that.</t>
</section>
<section title="Get ipv4 settings via protocol translation">
<figure anchor="Figure 2" title="COMPATIBILITY AND PROTOCOL TRANSLATION">
<artwork align="center">
<![CDATA[
+------+------+
| 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 |
|____________|
]]>
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Host's implementation and behavior">
<t>There would be 3 types of dual stack hosts:</t>
<t>Type 1:old type dual stack, having DHCPv4 client and DHCPv6 client,the DHCPv6 client was not modified.</t>
<t>Type 2:new type dual stack, having DHCPv4 client and DHCPv6 client,the DHCPv6 client has been modified and updated.</t>
<t>Type 3:DHCPv6 only client.</t>
<section title="Tyep 1 dual stack host">
<figure anchor="Figure 3" title="PROTOCOL STACK OF TYPE1 HOST">
<artwork align="center">
<![CDATA[
+------+------+ +------+------+
| DHCPv6 | | DHCPv4 |
| Client | | Client |
+------+------+ +------+------+
| |
+------+------+ +------+------+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +------+------+
| |
+------+----------------+------+
| Link Layer |
+------+----------------+------+
]]>
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Tyep 2 dual stack host">
<figure anchor="Figure 4" title="PROTOCOL STACK OF TYPE2 HOST">
<artwork align="center">
<![CDATA[
+---------+-----------+ +----+---+
| DHCPv6 | | DHCPv4 |
| Client | | Client |
+-----+------------+--+ +----+---+
+ + +
+-----+-------+ +-+----------+---+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +-------+--------+
| |
+------+-----------------+--------+
| Link Layer |
+------+-----------------+--------+
]]>
</artwork>
</figure>
<t>Hosts of type 2 can certainly get IPv4/IPv6 settings using DHCPv4/DHCPv6 client,they can also use DHCPv6 client to get IPv4 settings.</t>
</section>
<section title="Tyep 3 dual stack host">
<figure anchor="Figure 5" title="PROTOCOL STACK OF TYPE3 HOST">
<artwork align="center">
<![CDATA[
+------+----------------+------+
| DHCPv6 |
| Client |
+------+----------------+------+
| |
+------+------+ +------+------+
| IPv6 | | IPv4 |
| Stack | | Stack |
+------+------+ +------+------+
| |
+------+----------------+------+
| Link Layer |
+------+----------------+------+
]]>
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<section title="Server's implementation and behavior">
<figure anchor="Figure 6" title="CONCEPTIONAL IMPLEMENTAION MODEL OF SERVER">
<artwork align="center">
<![CDATA[
+---------------+ +----------------+
| IPv6 settings | | IPv4 settings |
| ----------- | | ------------ |
| |IPv6 prefix| | | |IPv4 Address| |
| ----------- | | ------------ |
| ----------- | | ----------- |
| | DNS | | | | DNS | |
| ----------- | | ----------- |
| ... | | ... |
| | | |
+------+--------+ +--------+-------+
| |
| |
+-----------------------------------+
| -------------- -------------- |
| |IPv6 Related | | IPv4 Related | |
| | Strategy | | Strategy | |
| -------------- -------------- |
| Strategy Management |
+-----------------------------------+
| |
+------+--------------------+-------+
| GENERAL DHCPv6 MESSAGE PROCESS |
| |
+------+--------------------+-------+
]]>
</artwork>
</figure>
<t>The servers are DHCPv6 only,they can only process DHCPv6 messages,so a general DHCPv6 message process modual must be implemented.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Network's behavior">
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
<section title="General Considerations and protocol translation">
<section title="New DHCPv6 Options for IPv4 Parameters">
<t>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.</t>
<t>The new options will be defined in other document.</t>
</section>
<section title="Protocol translation">
<t>In Figure 2, the protocol translation was executed in CPE, in this section,we will disccuss the scenario where BRAS do the protocol translation.</t>
<figure anchor="Figure 7" title="PROTOCOL TRANSLATION IN BRAS">
<artwork align="center">
<![CDATA[
+------+------+
| DHCPv6 |
| Server |
+------+--/\--+
_________|__||_______
/ || \
| ISP Core Network |
\____________||_______/
| ||
| ||------DHCPv6 message
+------+--\/--+
| BRAS(PE) |
| | ------Protocol translation
+------+--/ \-+
| |||------DHCPv4 message
_________|__\ /____
/ \
| Access Network |
\____________/ \____/
| |||------DHCPv4 message
| |||
+------+--\ /-+
| CPE |
+------+--/ \-+
| |||------DHCPv4 message
_____|__\ /_
| dual-stack |
| host |
|____________|
]]>
</artwork>
</figure>
<t>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. </t>
<t>The translation can also be executed in Access Node.</t>
</section>
</section>
<section title="Other Considerations">
<section title="Options for location identifing">
<t>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).</t>
<t>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.</t>
</section>
</section>
<section title="IANA Considerations">
<t> TBD.</t>
</section>
<section title="Security Considerations">
<t> TBD.</t>
</section>
<section title="Acknowledgement">
<t>Thanks for the authors of RFC4477.</t>
</section>
</middle>
<back>
<references title="Normative references">
&rfc3046;
&rfc3315;
&rfc3993;
&rfc4477;
&rfc4649;
&rfc4580;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:50:58 |