DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01 Tim Chown dhc WG, IETF 60, San Diego, August 2, 2004

The crux Nodes in a dual-stack environment may require IPv4 and IPv6 configuration (addresses and/or options). Should we advocate separate DHCPv4 and DHCPv6, or add options to DHCPv6 to handle serving DHCPv4 information? If we choose to have separate servers, how do we ensure the multiple sources of configuration information are handled by the clients?

DHCP servers DHCPv4 (RFC2131) –DHCP for IPv4 DHCPv6 (RFC3315) –For IPv6 nodes using full stateful autoconfiguration for address and other configuration options Stateless DHCPv6 (RFC3736) –For IPv6 nodes using IPv6 stateless address autoconfiguration (RFC2462), only using DHCP for configuration options (DNS, etc)

Configuration information For example: –IPv4 address –IPv6 address –DNS server –NTP server –NIS server –DNS search path May receive IPv4 and/or IPv6 addresses for configuration options

Issue 1: multiple responses How to handle multiple responses? –Use most recent data? –Prefer DHCPv6 served data or option addresses? –Round robin? In some cases this may not be an issue, e.g. two different DNS servers should give consistent responses to DNS queries. There may be other sources of configuration data, e.g. NIS, manually configured files, etc.

Issue 2: administration It may be the case that DHCPv4 and DHCPv6 servers are maintained by different administrative entities –This can be argued to be a multihoming issue?

Issue 3: multiple interfaces IPv4 and/or IPv6 may be run on different node interfaces –So are the received configuration data and settings per interface or per node? DHCPv6 has the DHCP Unique Identifier (DUID) concept to supercede MAC address, DHCP for IPv4 is introducing this concept –draft-ietf-dhc-3315id-for-v4-02

Issue 4: DNS load balancing The DHCP server returns different DNS data to different nodes to load balance between multiple local resolvers –May be problematic if trying to balance with DHCPv4 and DHPCv6 servers both used Could apply to other services, e.g. NTP

Issue 5: DNS search path The search path may vary for administrative reasons For example, new IPv6 services may be offered for foo.com under *.ipv6.foo.com

Issue 6: Protocol startup (This has been added in -01 draft) What happens if the IPv6 interface (transport) is started after DHCPv4 was used to configure the client? –Should that data be discarded, or merged with any subsequent DHCPv6 response –Is the timing issue important?

Issue 7: DHCP option variations Some DHCPv4 options aren’t present in DHCPv6 IP version limitations exist, e.g. only IPv6 servers may be in an IPv6 NTP option DHCP and DHCPv6 option numbers may be different Some sites may use IPv4-mapped addresses in DHCPv6-based options - is this a bad thing? Should DHCPv6 options exist that can carry IPv4 and IPv6 addresses?

Two solutions Run separate DHCP and DHCPv6 servers Run a single DHCPv6 server, and add capability to serve IPv4 addresses and options Can we agree on a preferred approach?

Separate servers (1) Servers may or may not be on same node –Server configuration data could be generated from a single database Implies client has heuristics to handle (merge) multiple server responses –In some cases inconsistencies won’t matter –Need a per-host preference method, e.g. “Prefer DHCPv6” –Need a method to merge “list” responses, e.g. “alternate, DHCPv6 first” –How to handle merging names and addresses?

Separate servers (2) If we take this approach, we need to identify situations where differences in DHCPv4 and DHCPv6 responses may impact node behaviour –We must place some faith in the site administrator to configure the DHCPv4 and DHCPv6 servers consistently –But we need to be confident that functionality is retained (e.g. DNS load balancing) If we take this path, we need to complete this task

Single DHCPv6 server (1) Have just one (DHCPv6) server Modify DHCPv6 to return IPv4 information (over IPv6 transport/lookup) Possibility is hinted at in RFC3315 Single server and transport leads to simplicity and predictability, and less failure modes Do we want dual-stack nodes to use separate DHCPv4 and DHCPv6 servers for the next 10 or 20 years?

Single DHCPv6 server (2) A number of potential problems/issues arise: –IPv4-only nodes can’t use DHCPv4 any more; if you do run DHCPv4 for these nodes, you then still have duplication of information –An IPv6-only node can’t use DHCPv4 responses –What if a responding DHCPv6 server isn’t able or configured to serve IPv4 information? –If IPv4 addresses are allocated from DHCPv4 and DHPCv6 servers, more stress is placed on valuable IPv4 address space –The DHCPv6 specification will become more complex and bloated to enable this capability

Way forward? Can we agree one path? –The list seems to lean towards separate servers, but it’s not clear the consensus is strong? –If we adopt the two server approach, we need to do more analysis of inconsistency impact, methods to specify preferences, etc. –There is one early implementation of preferences Should we abstract the multihoming/dna issues? Need to answer these two and edit to -02 version before any WGLC could be considered