RFC 4477

Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues

📅 published May 2006, from ietf

RFC 4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues 💖

okay so this is RFC 4477 and it's giving heads-up-for-the-dual-stack-girlies energy 🎀. It's an Informational doc from May 2006, so it's not a standard, just a super smart guide to a messy problem. The authors are T. Chown (University of Southampton), S. Venaas (UNINETT), and C. Strauf (Clausthal University of Technology) 👑. Its header doesn't list any RFC it obsoletes or updates, so it's standing on its own ✨.

Status of This Memo 🌸

okay this part is the boring legal bit but it matters 🙈. This memo gives info to the Internet community. It is not an Internet standard of any kind. And distribution of it is unlimited, so share the vibes 🦋.

Copyright (C) The Internet Society (2006).

Abstract ✨

so picture this: a node can speak IPv4, IPv6, or both 🧚. Nodes like that often want their config (IPv4 and/or IPv6 settings) from the Dynamic Host Configuration Protocol, aka DHCP. The original DHCP (RFC 2131) was built for IPv4, and now there's a new DHCPv6 (RFC 3315) for IPv6 💜. This doc talks about the problems that pop up when both IP versions use DHCP together. The biggest one is how a client should deal with config info coming from both DHCPv4 and DHCPv6 servers, which is literally the main character drama 😭. It gives a general strategy for handling this and lists future work to be done 🔥.

Table of Contents 🍓

1. Introduction ....................................................3
2. Configuration Scenarios .........................................3
3. Dual-Stack Issues ...............................................4
   3.1. Handling Multiple Responses ................................4
   3.2. Different Administrative Management ........................5
   3.3. Multiple Interfaces ........................................5
   3.4. DNS Load Balancing .........................................5
   3.5. DNS Search Path Issues .....................................5
   3.6. Protocol Startup Sequence ..................................6
   3.7. DHCP Option Variations .....................................6
   3.8. Security Issues ............................................6
4. Potential Solutions .............................................7
   4.1. Separate DHCP Servers ......................................7
   4.2. Single DHCPv6 Server .......................................8
   4.3. Optimising for Failure with Lists of Addresses .............9
   4.4. Administrative and Other Areas ............................10
5. Summary ........................................................10
6. Security Considerations ........................................12
7. Acknowledgements ...............................................12
8. Informative References .........................................12

1. Introduction 🎀

okay so the original DHCP spec was made with only IPv4 in mind 🙈. It got revised over time, and the latest version is cited as [1]. Then IPv6 showed up, so a new DHCP spec for it was designed and published as DHCPv6 [4] 💖.

These protocols let nodes talk over IPv4 or IPv6 (respectively) to grab config settings for running in a managed environment 🫶. An IPv6 node can already get its address-related settings through IPv6 stateless address autoconfiguration [2]. But it may still want stateless DHCPv6 [5] for other admin-set options, like DNS or NTP 🌈.

In early IPv6 rollouts, dual-stack is the usual move ✨. So there will be nodes that need both IPv4 and IPv6 config settings, and this doc is all about the issues with getting those settings in a dual-stack setup 💅.

There's also a general multihoming problem for DHCP that still needs solving 🦋. A host might be connected to several networks run by several different parties. And IPv4 and IPv6 might even be managed by separate people. These issues get a quick mention here, but the real focus is on running DHCP in a mixed (usually dual-stack) IPv4 and IPv6 environment inside a single administrative domain 🔥.

Quick definitions so we're on the same page 💜. A "DHCP server" is a server implementing the original DHCP [1]. A "DHCPv6 server" is a server implementing DHCPv6 [4] or its stateless subset [5] 🧚.

2. Configuration Scenarios 🌸

if a node lives in an IPv4-only or IPv6-only world, picking a DHCP server is easy-peasy 💅. It's a DHCP server for IPv4, or a DHCPv6 server for IPv6. Done ✨.

It gets more interesting in dual-stack 👑. A node in a managed environment needs to get both IPv4 and IPv6 config settings, things like these 🦋:

  • IPv4 address
  • IPv6 address
  • NTP server
  • DNS server
  • NIS server
  • DNS search path

The format of address settings depends on the IP version, sure 🙈. But the node might get an IPv4 or IPv6 address for some settings, like DNS or NTP, as long as those services are reachable over IPv4 or IPv6 transport. Right now, a DHCP server hands back IPv4 data and a DHCPv6 server hands back IPv6 data 💖.

Here's a tea moment ☕. In an IPv4 environment with a DHCP server, the node decides whether to use DHCP at all 🧚. In an IPv6 environment, the managed and other bits in the Router Advertisement can give the node a hint about whether to do full DHCPv6 or the stateless version 🌈. It's honestly not clear whether a dual-stack node should still do DHCP for IPv4 when both the Managed and OtherConfig flags in the Router Advertisement are off 😭. The most sensible answer seems to be that the decision to use DHCP for IPv4 should be made as if the host were IPv4-only 🫶.

4. Potential Solutions ✨

okay bestie, the IETF dhc working group came up with two big strategy ideas 💅 Strategy one is to run separate DHCP and DHCPv6 servers, with the client merging info from both where it needs to, or maybe asking one version first. Strategy two is to run only a DHCPv6 server and carry the IPv4 config stuff inside new IPv4 configuration options. Let's get into it 🦋

4.1. Separate DHCP Servers

okay so solution one is running separate DHCP and DHCPv6 servers 🎀 They might live on the same physical node or they might not. The info they serve could come from one single database instance so everything stays consistent ✨ You could even have one server instance that supports both DHCPv4 and DHCPv6, which is so efficient 😭

Here's the catch, though. Best practice guidance is needed for how multiple responses get handled or merged 💅 The admins have the onus to keep things consistent, like scripts that generate the common DHCP and DHCPv6 config files. Lowkey a lot of responsibility on them 🙈

Sometimes inconsistencies just don't matter 💖 For example, an NTP server gives the same time whether you reach it over IPv4 or IPv6. If different recursive DNS servers come from DHCP and DHCPv6, those name servers should still give the same answer to a given query 🫶 Sites running a "two-faced DNS" setup will still be fine, as long as the node sits at the same topological point on the network from both the IPv4 and IPv6 perspective. The order of DNS servers in a node's config doesn't matter, unless DNS load balancing is needed 🌸

Other times, inconsistencies are a real problem 💀 When lists of values come back, you need an algorithm to merge them, like "alternate, DHCPv6 first" ✨ You can also end up with values that just don't fit together. DHCPv6 might hand out domain names (like the SMTP or POP servers) while DHCPv4 only gives IPv4 addresses. Not it 🙅‍♀️

With separate servers, some options (like the DNS search path) aren't tied to any particular IP protocol context anyway 🦋

The multiple server approach is also simpler in some ways 🌈 The DHCPv4 and DHCPv6 servers might hand out the exact same value for a parameter, and then there's zero conflict. Sometimes the value is different but the effect is the same, like an NTP server. The real crux is figuring out where the differences can happen and where they'd actually change how the node behaves 🧚

One possible fix is per-host preferences, or an ordered list of them 💜 Examples are "use manually configured", "prefer DHCPv4", or "prefer DHCPv6", assuming the host can act based on which protocol was used. Then it's on the site admin to make sure the values from either DHCP are consistent. This idea extends to other methods too, like NIS or Service Location Protocol (SLP) 👑

4.2. Single DHCPv6 Server

okay bestie, there's a real argument for NOT having to configure and run both DHCP and DHCPv6 servers in a dual-stack site 🎀 Running both can also mean you serve the same info twice, which is just redundant 🙄 So one solution is to change DHCPv6 so it can return IPv4 info too ✨ The DHCPv6 [4] spec basically hints at this, saying: "If there is sufficient interest and demand, integration can be specified in a document that extends DHCPv6 to carry IPv4 addresses and configuration information." Iconic foreshadowing 😭 With this, DHCP for IPv4 could be completely replaced by DHCPv6 plus extra IPv4 information options, for dual-stack nodes 💅

The general argument is that which DHCP protocol you use (over IPv4 or IPv6) shouldn't change what kinds of addresses you can get configured 🦋 Simplicity and predictability come from using one server over one transport. Also, IPv4-capable hosts will likely stick around for at least 10 years, probably way longer 💀 So the big question is: do we really want dual-stack hosts (which are going to become the norm) to run both DHCPv4 and DHCPv6 forever? If you need both servers just to get addresses and other configs, you're relying on two separate protocols to work together (servers, relays, and so on) before the host can behave correctly. That's a lot 😩

This approach might mean listing a mix of IPv4 and IPv6 addresses in one option 🌸 That could be considered when new IPv6 options get introduced. There could be just two options needed: one new option for address delegation, and one for doing encapsulation ✨

Also, there are a bunch of DHCPv6 paradigms that DHCPv4 never got 🌈 One example is moving away from using MAC addresses for per-host address assignment, and instead using DHCP Unique Identifier (DUIDs) or Identity Association Identifiers (IAIDs). As stated in Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients for selecting configuration parameters and for associating IAs with clients. DHCPv6 clients use DUIDs to identify a server in messages where the server needs to be identified 🧚 The twist is that this new DHCPv6 functionality has recently been retrofitted to IPv4 through a spec for DUIDs for DHCPv4 [6] 💜

But there are a bunch of potential problems with this approach, and I'm not gonna pretend otherwise 💀

  • IPv4-only nodes wouldn't have any DHCP service available to them. This approach only works in a fully dual-stack environment 😭
  • The client node might be IPv6-only and receive IPv4 config settings it doesn't want, or can't handle meaningfully 🙈
  • The DHCPv4 servers still need to be configured anyway to support IPv4-only hosts, so the info is still duplicated 🍓
  • What happens if there are DHCPv6 servers that don't return IPv4 information? Does that mean the client can't run IPv4, since it won't do DHCPv4? 👀
  • If IPv4 info is served from a DHCPv6 server as well as an IPv4 DHCP server, IPv4 address space has to be allocated to both servers. That fragments the potentially precious IPv4 global address resource for the site 💔

4.3. Optimising for Failure with Lists of Addresses

okay so there's a generic issue with any option that includes a list of server addresses, like DNS server addresses 💖 The list exists for resilience, in case a listed server itself fails or connectivity to that server fails. If the client doesn't know what caused the failure, its best move is to try a different server, via a different protocol 🦋 The problem today is that the IPv4 list comes back over DHCPv4 and the IPv6 list over DHCPv6. The client really has no way to "try a different server", because that info gets lost in the protocol, even though the server might know it 😭

Merging heuristics in the client just can't give the best behaviour, since the information is already lost ⚠️

Compare that with including IPv4-mapped addresses in the DHCPv6 option alongside the IPv6 addresses 🎀 Then the DHCP server can give an intelligent order that takes into account which addresses belong to the same DNS (or whatever) server ✨ IPv6-only clients would have to know to discard the IPv4-mapped addresses in this solution. And it's way easier to solve this in the combined-DHCP-server case than in the two-server case 👑

One could argue this is only an optimisation, and in lots of cases the list only has two elements, so the "next" choice is forced anyway 🙄 But this particular issue shows just how subtle merging responses from separate servers can be 🫶

4.4. Administrative and Other Areas

there are also administrative issues and best practices that could be promoted 🌸 For example, it may be recommended that sites don't split their DNS name space for IPv6-specific testbeds 🧚

It may be worth thinking about whether separate manual config files should be kept for IPv4 and IPv6 settings, like separate /etc/resolv.conf files for DNS settings on UNIX systems 💅 But honestly, this seems like a complex solution. The problem should be better solved by other, more generalised methods 🌈

It might also matter, at times, to be able to tell DHCP client and server identities apart 💜 DHCPv6 introduces the idea of a DHCP Unique Identifier (DUID). The DUID concept has also been retrofitted to DHCPv4 [6], so it might form part of the solution space for this problem ✨

Some differences between DHCP and DHCPv6 might never get reconciled, and that's okay because they might not need to be 🦋 Examples are the different ways to assign addresses by DUID in DHCPv6, or the lack of a comparable option in both DHCP versions 🫶

5. Summary ✨

okay so bestie, let's talk about the big picture 🦋 DHCP (for IPv4) and DHCPv6 servers handing out config to dual-stack nodes have a bunch of issues that need sorting out. Some of the protocol differences might never get reconciled, and that's honestly fine, because maybe we don't need them to be. 💅 But DHCPv6 is growing, so sites need to figure out best practice for DHCP server setup in dual-stack environments. That might or might not mean new protocol rules. 🌸

The main question is whether a site should keep running separate DHCP and DHCPv6 services, or whether DHCPv6 should be extended to carry IPv4 config for dual-stack nodes. 👑

Here's the thing, though. Until a site is completely dual-stack, IPv4 DHCP is going to be needed 😭 Think legacy printers, IP webcams, and other devices that still configure themselves over DHCPv4. A single IPv6 transport DHCP server that offers config for both protocols just won't cut it in that case. So IPv4 DHCP is required, and that's a strong reason to focus on how to combine the info from separate IPv4 DHCP and (stateless) DHCPv6 servers. 🧚

In theory, it should be pretty straightforward to write a configuration manager. It would take one config spec from the service manager and push out correct, consistent configs to the DHCPv4 and DHCPv6 servers, whether they live on the same host or not. 🍓 Keeping two servers coordinated is an interface issue, not a protocol issue. The real question is whether the client has everything it needs to make reasonable choices. We know of one implementation of separate DHCPv4 and DHCPv6 clients that uses a preference option to help the client merge what it receives. ✨

Another thing to chat about: is a combined DHCP service that only runs over IPv6 transport a good longer-term goal? This would be for networks with only dual-stack or IPv6-only nodes (or IPv4-only nodes where DHCPv4 isn't needed). 🎀 Getting there may easily take more than 10 years, so bring snacks 🙈

So after thinking it all through, the dhc WG reached a strong consensus to go with the two-server approach (separate DHCP and DHCPv6 servers) instead of a combined single server returning IPv4 info over IPv6. 💖 The two servers can be co-located on one node, and they can have consistent config info generated from a single asset database. Iconic. 👑

Also, DHCPv6 deployment experience is still in its infancy 🍼 So a full understanding of the issues may only develop over time. We feel we've reached the best consensus for where things stand right now. Future work is needed to figure out best practice for merging info from multiple servers, including merging lists of addresses where options carry that kind of info. 🔥

A quick footnote: this work overlaps with multihoming and multi-interface config issues. It's also tangled up with the Detecting Network Attachment area, where a node might move from an IPv4-only network to a dual-stack network, or the other way around. 🌈 Both aspects may be best pulled out for discussion and progress in the respective IETF multi6, shim6, and dna WGs, in parallel with the two-server work in the dhc WG. Main character energy for sure 💜

6. Security Considerations 🔒

okay, this one is short but it's giving honesty. ✨

There are no security considerations in this problem statement per se, as it does not propose a new protocol. 🙈

7. Acknowledgements 🫶

The authors thank the following people for their input to this document: Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz, Changming Liu, Margaret Wasserman, Dave Thaler, Mark Hollinger, and Greg Daley. The document may not necessarily fully reflect the views of each of these individuals. 💖

The authors would also like to thank colleagues on the 6NET project for their contributions to this document. 🌸

8. Informative References 📚

  • [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
  • [3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
  • [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
  • [6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.

Authors' Addresses 📮

Tim Chown
University of Southampton
School of Electronics and Computer Science
Southampton, Hampshire  SO17 1BJ
United Kingdom

EMail: tjc@ecs.soton.ac.uk


Stig Venaas
UNINETT
Trondheim  NO 7465
Norway

EMail: venaas@uninett.no


Christian Strauf
Clausthal University of Technology
Erzstr. 51
Clausthal-Zellerfeld  D-38678
Germany

EMail: strauf@rz.tu-clausthal.de

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌈

📦 where this page comes from