draft-ietf-dhc-dual-stack-02.txt   draft-ietf-dhc-dual-stack-03.txt 
Dynamic Host Congiguration T. Chown Dynamic Host Congiguration T. Chown
Internet-Draft University of Southampton Internet-Draft University of Southampton
Expires: April 25, 2005 S. Venaas Expires: January 12, 2006 S. Venaas
UNINETT UNINETT
C. Strauf C. Strauf
Technical University of Clausthal Technical University of Clausthal
October 25, 2004 July 11, 2005
DHCP: IPv4 and IPv6 Dual-Stack Issues DHCP: IPv4 and IPv6 Dual-Stack Issues
draft-ietf-dhc-dual-stack-02 draft-ietf-dhc-dual-stack-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005. This Internet-Draft will expire on January 12, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
A node may have support for communications using IPv4 and/or IPv6 A node may have support for communications using IPv4 and/or IPv6
protocols. Such a node may wish to obtain IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6
configuration settings via the Dynamic Host Configuration Protocol configuration settings via the Dynamic Host Configuration Protocol
(DHCP). The original version of DHCP [1] designed for IPv4 has now (DHCP). The original version of DHCP [1] designed for IPv4 has now
been complemented by a new DHCPv6 [4] for IPv6. This document been complemented by a new DHCPv6 [4] for IPv6. This document
describes issues identified with dual IP version DHCP interactions, describes issues identified with dual IP version DHCP interactions,
the most important aspect of which is how to handle potential the most important aspect of which is how to handle potential
skipping to change at page 2, line 26 skipping to change at page 2, line 27
3.2 Different administrative management . . . . . . . . . . . 5 3.2 Different administrative management . . . . . . . . . . . 5
3.3 Multiple interfaces . . . . . . . . . . . . . . . . . . . 5 3.3 Multiple interfaces . . . . . . . . . . . . . . . . . . . 5
3.4 DNS load balancing . . . . . . . . . . . . . . . . . . . . 5 3.4 DNS load balancing . . . . . . . . . . . . . . . . . . . . 5
3.5 DNS search path issues . . . . . . . . . . . . . . . . . . 5 3.5 DNS search path issues . . . . . . . . . . . . . . . . . . 5
3.6 Protocol startup sequence . . . . . . . . . . . . . . . . 5 3.6 Protocol startup sequence . . . . . . . . . . . . . . . . 5
3.7 DHCP option variations . . . . . . . . . . . . . . . . . . 6 3.7 DHCP option variations . . . . . . . . . . . . . . . . . . 6
3.8 Security issues . . . . . . . . . . . . . . . . . . . . . 6 3.8 Security issues . . . . . . . . . . . . . . . . . . . . . 6
4. Potential solutions . . . . . . . . . . . . . . . . . . . . . 6 4. Potential solutions . . . . . . . . . . . . . . . . . . . . . 6
4.1 Separate DHCP servers . . . . . . . . . . . . . . . . . . 6 4.1 Separate DHCP servers . . . . . . . . . . . . . . . . . . 6
4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . 7 4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . 7
4.3 Optimising for failure with lists of addresses . . . . . . 8 4.3 Optimising for failure with lists of addresses . . . . . . 9
4.4 Administrative and other areas . . . . . . . . . . . . . . 9 4.4 Administrative and other areas . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 13
1. Introduction 1. Introduction
The original specification of the Dynamic Host Configuration Protocol The original specification of the Dynamic Host Configuration Protocol
(DHCP) was made with only IPv4 in mind. That specification has been (DHCP) was made with only IPv4 in mind. That specification has been
subsequently revised, up to the latest version of DHCP [1]. With the subsequently revised, up to the latest version of DHCP [1]. With the
arrival of IPv6, a new DHCP specification for IPv6 has been designed, arrival of IPv6, a new DHCP specification for IPv6 has been designed,
and published as DHCPv6 [4]. and published as DHCPv6 [4].
skipping to change at page 3, line 25 skipping to change at page 3, line 25
environment. While an IPv6 node may acquire address-related environment. While an IPv6 node may acquire address-related
configuration settings via IPv6 stateless address autoconfiguration configuration settings via IPv6 stateless address autoconfiguration
[2], such a node may wish to use stateless DHCPv6 [5] for other [2], such a node may wish to use stateless DHCPv6 [5] for other
administratively configured options, such as DNS or NTP. administratively configured options, such as DNS or NTP.
In early IPv6 deployments, a dual-stack mode of operation is In early IPv6 deployments, a dual-stack mode of operation is
typically used. There will thus be nodes that require both IPv4 and typically used. There will thus be nodes that require both IPv4 and
IPv6 configuration settings. This document discusses issues with IPv6 configuration settings. This document discusses issues with
obtaining such settings in a dual-stack environment. obtaining such settings in a dual-stack environment.
While there is a more general multihoming issue to be solved for DHC,
in this text we focus on the specific issues for operating DHCP in a
mixed (typically dual-stack) IPv4 and IPv6 environment.
In this document, we refer to a "DHCP server" as a server In this document, we refer to a "DHCP server" as a server
implementing the original DHCP [1], and a "DHCPv6 server" as a server implementing the original DHCP [1], and a "DHCPv6 server" as a server
implementing DHCPv6 [4] or its stateless subset [5]. implementing DHCPv6 [4] or its stateless subset [5].
2. Configuration scenarios 2. Configuration scenarios
For a node in an IPv4-only or IPv6-only environment, the choice of For a node in an IPv4-only or IPv6-only environment, the choice of
DHCP server is a straightforward one; a DHCP server for IPv4, or a DHCP server is a straightforward one; a DHCP server for IPv4, or a
DHCPv6 server for IPv6. DHCPv6 server for IPv6.
skipping to change at page 7, line 10 skipping to change at page 7, line 13
instance for consistency. instance for consistency.
In this approach, some best practice guidance is required for how In this approach, some best practice guidance is required for how
multiple responses are handled or merged. Administrators have the multiple responses are handled or merged. Administrators have the
onus to maintain consistency (for example, scripts may generate onus to maintain consistency (for example, scripts may generate
common DHCP and DHCPv6 configuration files). common DHCP and DHCPv6 configuration files).
In some cases, inconsistencies may not matter. In a simple case, an In some cases, inconsistencies may not matter. In a simple case, an
NTP server will give the same time whether accessed by IPv4 or IPv6. NTP server will give the same time whether accessed by IPv4 or IPv6.
Even if different recursive DNS servers are offered via DHCP or Even if different recursive DNS servers are offered via DHCP or
DHCPv6, those name servers will provide the same response to a given DHCPv6, then those name servers should provide the same response to a
query. The order of DNS servers in a node's configuration is not given query. In cases where sites may be operating a 'two-faced DNS'
important, unless DNS load balancing is required. this will still hold true given the node is on the same topological
point on the network from an IPv4 or IPv6 perspective. The order of
DNS servers in a node's configuration is not important, unless DNS
load balancing is required.
In other cases, inconsistencies may be an issue, for example where In other cases, inconsistencies may be an issue, for example where
lists of values are returned, an algorithm is needed for list merger lists of values are returned, an algorithm is needed for list merger
(e.g. "alternate, DHCPv6 first"). Or there may be incompatible (e.g. "alternate, DHCPv6 first"). Or there may be incompatible
configuration values where, for example, DHCPv6 supplies domain names configuration values where, for example, DHCPv6 supplies domain names
(such the SMTP or POP servers) whereas DHCPv4 provided only IPv4 (such the SMTP or POP servers) whereas DHCPv4 provided only IPv4
addresses. addresses.
In the case of separate servers, there are some options like DNS In the case of separate servers, there are some options like DNS
search path, that aren't used in a specific IP protocol context. search path, that aren't used in a specific IP protocol context.
skipping to change at page 8, line 37 skipping to change at page 8, line 41
However, there are a number of potential problems with this approach: However, there are a number of potential problems with this approach:
o IPv4-only nodes would not have any DHCP service available to them; o IPv4-only nodes would not have any DHCP service available to them;
such an approach is only possible in a fully dual-stack such an approach is only possible in a fully dual-stack
environment. environment.
o The client node may then be IPv6-only and receiving IPv4 o The client node may then be IPv6-only and receiving IPv4
configuration settings that it does not want or be able to configuration settings that it does not want or be able to
meaningfully handle. meaningfully handle.
o The DHCPv4 servers need to be configured anyway to support o The DHCPv4 servers need to be configured anyway to support IPv4-
IPv4-only hosts, so there is still duplication of information. only hosts, so there is still duplication of information.
o What happens if there are DHCPv6 servers that don't return IPv4 o What happens if there are DHCPv6 servers that don't return IPv4
information? Does this mean the client can't run IPv4 (since it information? Does this mean the client can't run IPv4 (since it
won't do DHCPv4)? won't do DHCPv4)?
o If IPv4 information is served from a DHCPv6 server as well as an o If IPv4 information is served from a DHCPv6 server as well as an
IPv4 DHCP server, IPv4 address space will need to be allocated to IPv4 DHCP server, IPv4 address space will need to be allocated to
both servers, fragmenting the potentially precious IPv4 global both servers, fragmenting the potentially precious IPv4 global
address resource for the site. address resource for the site.
skipping to change at page 9, line 20 skipping to change at page 9, line 24
DHCPv6, and the client has no way to really "try a different server", DHCPv6, and the client has no way to really "try a different server",
since that information is lost by the protocol, even though it may be since that information is lost by the protocol, even though it may be
known by the server. known by the server.
Just putting merging heuristics in the client cannot provide the best Just putting merging heuristics in the client cannot provide the best
behaviour, since information is lost. By comparison, if IPv4-mapped behaviour, since information is lost. By comparison, if IPv4-mapped
addresses were included in the DHCPv6 option along with IPv6 addresses were included in the DHCPv6 option along with IPv6
addresses, the DHCP server can give an intelligent order that takes addresses, the DHCP server can give an intelligent order that takes
into account which addresses are of the same DNS/whatever server. into account which addresses are of the same DNS/whatever server.
IPv6-only clients have to know to discard the IPv4-mapped addresses IPv6-only clients have to know to discard the IPv4-mapped addresses
in this solution, and it's much easier to solve this in the in this solution, and it's much easier to solve this in the combined-
combined-DHCP-server case than in the two-server case. DHCP-server case than in the two-server case.
One can argue this is only an optimisation, and in many cases the One can argue this is only an optimisation, and in many cases the
list has only two elements, so the "next" choice is forced. However, list has only two elements, so the "next" choice is forced. However,
this particular issue highlights the subtleties of merging responses this particular issue highlights the subtleties of merging responses
from separate servers. from separate servers.
4.4 Administrative and other areas 4.4 Administrative and other areas
There are also administrative issues or best practice that could be There are also administrative issues or best practice that could be
promoted. For example, it may be recommended that sites do not split promoted. For example, it may be recommended that sites do not split
their DNS name space for IPv6-specific testbeds. their DNS name space for IPv6-specific testbeds.
It may be worth considering whether separate manual configuration It may be worth considering whether separate manual configuration
files should be kept for IPv4 and IPv6 settings, such as separate / files should be kept for IPv4 and IPv6 settings, such as separate
etc/resolv.conf files for DNS settings on UNIX systems. However, /etc/resolv.conf files for DNS settings on UNIX systems. However,
this seems a complex solution that should be better solved by other this seems a complex solution that should be better solved by other
more generalised methods. more generalised methods.
Some differences in DHCP and DHCPv6 may not be reconciled, but may Some differences in DHCP and DHCPv6 may not be reconciled, but may
not need to be, such as different ways to assign addresses by DUID in not need to be, such as different ways to assign addresses by DUID in
DHCPv6, or the non-aligned option numbers for DHCP and DHCPv6. DHCPv6, or the non-aligned option numbers for DHCP and DHCPv6.
5. Summary 5. Summary
There are a number of issues in the operation of DHCP and DHCPv6 There are a number of issues in the operation of DHCP and DHCPv6
servers for nodes in dual-stack environments that should be servers for nodes in dual-stack environments that should be
clarified. While some differences in the protocols may not be clarified. While some differences in the protocols may not be
reconciled, there may not be a need to do so. However, for general reconciled, there may not be a need to do so. However, for general
operation some best practice should be agreed, the principle choice operation some best practice should be agreed, the principle choice
being whether separate DHCP and DHCPv6 servers should be maintained being whether separate DHCP and DHCPv6 servers should be maintained
by a site, or whether DHCPv6 should be extended to carry IPv4 by a site, or whether DHCPv6 should be extended to carry IPv4
configuration settings for dual-stack nodes. configuration settings for dual-stack nodes.
It can certainly be argued that until a site is completely It can certainly be argued that until a site is completely dual-
dual-stack, an IPv4 DHCP service will always be required (for example stack, an IPv4 DHCP service will always be required (for example
while there are still legacy printers, IP webcams or devices which while there are still legacy printers, IP webcams or devices which
still configure via DHCPv4), and a single IPv6 transport DHCP server still configure via DHCPv4), and a single IPv6 transport DHCP server
offering configuration information for both protocols will then not offering configuration information for both protocols will then not
be sufficient. In that case, IPv4 DHCP is required, and thus there be sufficient. In that case, IPv4 DHCP is required, and thus there
is a good rationale for focusing effort on how to combine the is a good rationale for focusing effort on how to combine the
information received from separate IPv4 DHCP and (stateless) DHCPv6 information received from separate IPv4 DHCP and (stateless) DHCPv6
servers. servers.
In theory, it should be relatively straightforward to write a In theory, it should be relatively straightforward to write a
configuration manager that would accept a single configuration configuration manager that would accept a single configuration
skipping to change at page 11, line 4 skipping to change at page 11, line 7
Having reached this concensus, future work is now required to Having reached this concensus, future work is now required to
determine best practice for merging information from multiple determine best practice for merging information from multiple
servers, including merger of lists of addresses where options carry servers, including merger of lists of addresses where options carry
such information. such information.
As a footnote, we note that this work has overlap with multihoming As a footnote, we note that this work has overlap with multihoming
and multi-interface configuration issues. It is also interwoven with and multi-interface configuration issues. It is also interwoven with
the Detecting Network Attachment area, for example where a node may the Detecting Network Attachment area, for example where a node may
move from an IPv4-only network to a dual-stack network, or vice move from an IPv4-only network to a dual-stack network, or vice
versa. Both aspects may be best abstracted for discussion and versa. Both aspects may be best abstracted for discussion and
progression in the respective IETF multi6 and dna WGs, in parallel progression in the respective IETF multi6, shim6 and dna WGs, in
with the two-server progression in the dhc WG. parallel with the two-server progression in the dhc WG.
6. Security Considerations 6. IANA Considerations
There are no IANA considerations for this document.
7. Security Considerations
There are no security considerations in this problem statement per There are no security considerations in this problem statement per
se, as it does not propose a new protocol. se, as it does not propose a new protocol.
7. Acknowledgements 8. Acknowledgements
The authors thank the following people for input to this document: The authors thank the following people for input to this document:
Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz, Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz,
Changming Liu, Margaret Wasserman, Dave Thaler and Greg Daley. The Changming Liu, Margaret Wasserman, Dave Thaler and Greg Daley. The
document may not necessarily fully reflect the views of each of these document may not necessarily fully reflect the views of each of these
individuals. individuals.
The authors would also like to thank colleagues on the 6NET project The authors would also like to thank colleagues on the 6NET project
for contributions to this document. for contributions to this document.
8 Informative References 9. Informative References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address [2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003. RFC 3315, July 2003.
[5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) [5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004. Service for IPv6", RFC 3736, April 2004.
[6] Lemon, T., "Node-Specific Client Identifiers for DHCPv4", [6] Sommerfeld, B. and T. Lemon, "Node-Specific Client Identifiers
draft-ietf-dhc-3315id-for-v4-03 (work in progress), July 2004. for DHCPv4", draft-ietf-dhc-3315id-for-v4-05 (work in progress),
June 2005.
Authors' Addresses Authors' Addresses
Tim Chown Tim Chown
University of Southampton University of Southampton
School of Electronics and Computer Science School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
EMail: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Stig Venaas Stig Venaas
UNINETT UNINETT
Trondheim NO 7465 Trondheim NO 7465
Norway Norway
EMail: venaas@uninett.no Email: venaas@uninett.no
Christian Strauf Christian Strauf
Technical University of Clausthal Technical University of Clausthal
Erzstr. 51 Erzstr. 51
Clausthal-Zellerfeld D-38678 Clausthal-Zellerfeld D-38678
Germany Germany
EMail: strauf@rz.tu-clausthal.de Email: strauf@rz.tu-clausthal.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 13, line 41 skipping to change at page 13, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/