draft-ietf-dhc-dual-stack-03.txt   draft-ietf-dhc-dual-stack-04.txt 
Dynamic Host Congiguration T. Chown Dynamic Host Congiguration T. Chown
Internet-Draft University of Southampton Internet-Draft University of Southampton
Expires: January 12, 2006 S. Venaas Expires: April 27, 2006 S. Venaas
UNINETT UNINETT
C. Strauf C. Strauf
Technical University of Clausthal Technical University of Clausthal
July 11, 2005 October 24, 2005
DHCP: IPv4 and IPv6 Dual-Stack Issues DHCP: IPv4 and IPv6 Dual-Stack Issues
draft-ietf-dhc-dual-stack-03 draft-ietf-dhc-dual-stack-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 12, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Configuration scenarios . . . . . . . . . . . . . . . . . . . 3 2. Configuration scenarios . . . . . . . . . . . . . . . . . . . 3
3. Dual-stack issues . . . . . . . . . . . . . . . . . . . . . . 4 3. Dual-stack issues . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Handling multiple responses . . . . . . . . . . . . . . . 4 3.1 Handling multiple responses . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 7
4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . 7 4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . 8
4.3 Optimising for failure with lists of addresses . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14
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].
These protocols allow nodes to communicate via IPv4 or IPv6 to These protocols allow nodes to communicate via IPv4 or IPv6 to
skipping to change at page 5, line 15 skipping to change at page 5, line 15
settings from the DHCP response may then overwrite the manual IPv6 settings from the DHCP response may then overwrite the manual IPv6
DNS setting. DNS setting.
3.2 Different administrative management 3.2 Different administrative management
In some deployments, the IPv4 and IPv6 services may not be In some deployments, the IPv4 and IPv6 services may not be
administered by the same organisation or people, such as in a administered by the same organisation or people, such as in a
community wireless environment. This poses problems for consistency community wireless environment. This poses problems for consistency
of data offered by either DHCP version. of data offered by either DHCP version.
There may also be different connectivity for the protocols, and the
client may gain advantage from knowing which 'administrative domain'
is supplying which information. A client may need to use different
received information depending on which connectivity is being used.
In the example of the community wireless environment, the question of
which connectivity is 'better' is a separate issue.
3.3 Multiple interfaces 3.3 Multiple interfaces
A node may have multiple interfaces and run IPv4 and IPv6 on A node may have multiple interfaces and run IPv4 and IPv6 on
different interfaces. A question then is whether the settings are different interfaces. A question then is whether the settings are
per interface or per node? DHCPv6 introduces the idea of a DHCP per interface or per node?
Unique Identifier (DUID) which does not yet exist for DHCP; some
effort is being made to retrofit the concept to DHCPv4 [6].
Per interface settings can be complex because a client node needs to Per interface settings can be complex because a client node needs to
know from which interface system settings like NTP server came from. know which interface system settings like NTP server came from. And
And it may not be apparent which setting should be used, if e.g. an it may not be apparent which setting should be used, if e.g. an NTP
NTP server option is received on multiple interfaces, potentially server option is received on multiple interfaces, potentially over
over different protocols. different protocols.
3.4 DNS load balancing 3.4 DNS load balancing
In some cases it is preferable to list DNS server information in an In some cases it is preferable to list DNS server information in an
ordered way per node for load balancing, giving different responses ordered way per node for load balancing, giving different responses
to different clients. Responses from different DHCP and DHCPv6 to different clients. Responses from different DHCP and DHCPv6
servers may make such configuration problematic, if the knowledge of servers may make such configuration problematic, if the knowledge of
the load balancing is not available to both servers. the load balancing is not available to both servers.
3.5 DNS search path issues 3.5 DNS search path issues
skipping to change at page 6, line 4 skipping to change at page 6, line 11
confident of offering a full dual-stack service under its main confident of offering a full dual-stack service under its main
domain. The subtlety here is that the DNS search path then affects domain. The subtlety here is that the DNS search path then affects
choice of protocol used, such as IPv6 for nodes in ipv6.foo.com. choice of protocol used, such as IPv6 for nodes in ipv6.foo.com.
3.6 Protocol startup sequence 3.6 Protocol startup sequence
In the dual-stack environment, one needs to consider what happens if, In the dual-stack environment, one needs to consider what happens if,
for example, the IPv6 interface (transport) is started after DHCPv4 for example, the IPv6 interface (transport) is started after DHCPv4
was used to configure the client. Should the client then simply was used to configure the client. Should the client then simply
discard the current IPv4 information, or merge it with a subsequent discard the current IPv4 information, or merge it with a subsequent
IPv6 response? IPv6 response? It may also be possible that one protocol is shut
down or started while the system is running. There are similarities
here to issues when DHCP renewals have information that may appear
that previously was not available (or no longer carry information
that has been removed).
3.7 DHCP option variations 3.7 DHCP option variations
Some options in DHCP are not available in DHCPv6 and vice-versa. Some options in DHCP are not available in DHCPv6 and vice-versa.
Some IP-version limitations naturally apply, such as only IPv6 Some IP-version limitations naturally apply, such as only IPv6
addresses can be in an IPv6 NTP option. The DHCP and DHCPv6 option addresses can be in an IPv6 NTP option. The DHCP and DHCPv6 option
numbers may be different. numbers may be different.
Some sites may choose to use IPv4-mapped addresses in DHCPv6-based Some sites may choose to use IPv4-mapped addresses in DHCPv6-based
options. The merits and drawbacks of such an approach need options. The merits and drawbacks of such an approach need
skipping to change at page 6, line 50 skipping to change at page 7, line 12
(with the client merging information received from both where (with the client merging information received from both where
necessary, or perhaps choosing to query a particular version first), necessary, or perhaps choosing to query a particular version first),
the second is to run only a DHCPv6 server, and relay IPv4 the second is to run only a DHCPv6 server, and relay IPv4
configuration information within (new) IPv4 configuration options. configuration information within (new) IPv4 configuration options.
4.1 Separate DHCP servers 4.1 Separate DHCP servers
One solution is to run separate DHCP and DHCPv6 servers. These may One solution is to run separate DHCP and DHCPv6 servers. These may
or may not be run on the same physical node. The information served or may not be run on the same physical node. The information served
from the DHCP servers could be generated from a single database from the DHCP servers could be generated from a single database
instance for consistency. instance for consistency. One might have a single server instance
supporting both DHCPv4 and DHCPv6 protocols.
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, then those name servers should provide the same response to a DHCPv6, then those name servers should provide the same response to a
skipping to change at page 7, line 39 skipping to change at page 7, line 49
The multiple server approach will have some simplifications. The The multiple server approach will have some simplifications. The
DHCPv4 and DHCPv6 servers may provide the same value for a particular DHCPv4 and DHCPv6 servers may provide the same value for a particular
parameter, in which case there is no conflict. In some cases the parameter, in which case there is no conflict. In some cases the
value may be different, but the effect should be the same (such as an value may be different, but the effect should be the same (such as an
NTP server). The crux of the issue is to identify where differences NTP server). The crux of the issue is to identify where differences
may occur and where these differences will have an impact on node may occur and where these differences will have an impact on node
behaviour. behaviour.
One possible solution is to have per-host preferences, or an ordered One possible solution is to have per-host preferences, or an ordered
list of preferences, for example "use manually configured"", "prefer list of preferences, for example "use manually configured", "prefer
DHCPv4", or "prefer DHCPv6"", assuming the host can act based upon DHCPv4", or "prefer DHCPv6", assuming the host can act based upon
which protocol is used. It is then up to the site administrator to which protocol is used. It is then up to the site administrator to
ensure values returned from either DHCP are consistent (a principle ensure values returned from either DHCP are consistent (a principle
which extends if other methods are used, such as NIS or SLP). which extends if other methods are used, such as NIS or SLP).
4.2 Single DHCPv6 server 4.2 Single DHCPv6 server
There is an argument for not having to configure and operate both There is an argument for not having to configure and operate both
DHCP and DHCPv6 servers in a dual-stack site environment. The use of DHCP and DHCPv6 servers in a dual-stack site environment. The use of
both servers may also lead to some redundancy in the information both servers may also lead to some redundancy in the information
served. Thus one solution may be to modify DHCPv6 to be able to served. Thus one solution may be to modify DHCPv6 to be able to
skipping to change at page 8, line 27 skipping to change at page 8, line 38
then you rely on two separate protocols to work (servers and relays, then you rely on two separate protocols to work (servers and relays,
etc) in order for the host to behave correctly. etc) in order for the host to behave correctly.
This approach may require the listing of a mix of IPv4 and IPv6 This approach may require the listing of a mix of IPv4 and IPv6
addresses for an option. This could then be considered when new IPv6 addresses for an option. This could then be considered when new IPv6
options are introduced. There could be just two options needed, one options are introduced. There could be just two options needed, one
new option for the address delegation, and one for doing new option for the address delegation, and one for doing
encapsulation. encapsulation.
Also, there are a number of paradigms in DHCPv6 that we miss in Also, there are a number of paradigms in DHCPv6 that we miss in
DHCPv4, such as going away from using MAC addresses for per-host DHCPv4. An example is movement away from using MAC addresses for
address assignment but instead using DUIDs/IAIDs, etc (although there per-host address assignment and instead using DHCP Unique Identifier
is ongoing work to provide DUIDs for DHCPv4 [6]). (DUIDs) or Identity Association Identifiers (IAIDs). As stated in
Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients
for the selection of configuration parameters and in the association
of IAs with clients. DHCPv6 clients use DUIDs to identify a server
in messages where a server needs to be identified. There is now also
a specification for DUIDs for DHCPv4 [6].
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.
skipping to change at page 9, line 44 skipping to change at page 10, line 12
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.
It may be important at times to be able to distinguish DHCP clients
and server identities. DHCPv6 introduces the idea of a DHCP Unique
Identifier (DUID). The DUID concept has also been retrofitted to
DHCPv4 [6], and thus it may form the basis of part of the solution
space for the problem at hand.
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 lack of a comparable option in both DHCP versions.
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, with DHCPv6
operation some best practice should be agreed, the principle choice deployment growing, there is an operational requirement to determine
being whether separate DHCP and DHCPv6 servers should be maintained best practice for DHCP server provision in dual-stack environments,
by a site, or whether DHCPv6 should be extended to carry IPv4 which may or may not imply additional protocol requirements. The
configuration settings for dual-stack nodes. principle operational choice is whether separate DHCP and DHCPv6
servers should be maintained by a site, or whether DHCPv6 should be
extended to carry IPv4 configuration settings for dual-stack nodes.
It can certainly be argued that until a site is completely dual- It can certainly be argued that until a site is completely 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.
skipping to change at page 10, line 38 skipping to change at page 11, line 15
one implementation of separate DHCPv4 and DHCPv6 clients that is one implementation of separate DHCPv4 and DHCPv6 clients that is
using a preference option for assisting client-side merging of the using a preference option for assisting client-side merging of the
received information. received information.
Another issue for discussion is whether a combined DHCP service only Another issue for discussion is whether a combined DHCP service only
available over IPv6 transport is a desirable longer-term goal for available over IPv6 transport is a desirable longer-term goal for
networks containing only dual-stack or IPv6-only nodes (or IPv4-only networks containing only dual-stack or IPv6-only nodes (or IPv4-only
nodes where DHCPv4 is not needed). The transition to the long-term nodes where DHCPv4 is not needed). The transition to the long-term
position may easily take more than 10 years. position may easily take more than 10 years.
On reflection on the above observations, it was the strong concensus On reflection on the above observations, it was the strong consensus
of the dhc WG to adopt the two-server approach (separate DHCP and of the dhc WG to adopt the two-server approach (separate DHCP and
DHCPv6 servers) in favour to a combined, single server returning IPv4 DHCPv6 servers) in favour to a combined, single server returning IPv4
information over IPv6. The two servers may be co-located on a single information over IPv6. The two servers may be co-located on a single
node, and may have consistent configuration information generated node, and may have consistent configuration information generated
from a single asset database. from a single asset database.
Having reached this concensus, future work is now required to It should be noted that deployment experience of DHCPv6 is still in
determine best practice for merging information from multiple its infancy, thus a full understanding of the issues may only develop
servers, including merger of lists of addresses where options carry with time, but we feel we have reached best consensus given the
such information. current status. Having reached this concensus, future work is now
required to determine best practice for merging information from
multiple servers, including merger of lists of addresses where
options carry 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, shim6 and dna WGs, in progression in the respective IETF multi6, shim6 and dna WGs, in
parallel with the two-server progression in the dhc WG. parallel with the two-server progression in the dhc WG.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 11, line 23 skipping to change at page 11, line 51
7. Security Considerations 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.
8. 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, Mark Hollinger and
document may not necessarily fully reflect the views of each of these Greg Daley. The document may not necessarily fully reflect the views
individuals. of each of these 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.
9. 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
 End of changes. 22 change blocks. 
38 lines changed or deleted 64 lines changed or added

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