DHCP: Dual-Stack Issues draft-ietf-dhc-dual-stack-01

1
DHCP Dual-Stack Issuesdraft-ietf-dhc-dual-stack-
01

• Tim Chown
• tjc_at_ecs.soton.ac.uk
• dhc WG, IETF 60, San Diego,
• August 2, 2004

2
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?

3
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)

4
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

5
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.

6
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?

7
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

8
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

9
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

10
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?

11
Issue 7 DHCP option variations

• Some DHCPv4 options arent 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?

12
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?

13
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 wont 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?

14
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

15
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?

16
Single DHCPv6 server (2)

• A number of potential problems/issues arise
• IPv4-only nodes cant use DHCPv4 any more if you
  do run DHCPv4 for these nodes, you then still
  have duplication of information
• An IPv6-only node cant use DHCPv4 responses
• What if a responding DHCPv6 server isnt 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

17
Way forward?

• Can we agree one path?
• The list seems to lean towards separate servers,
  but its 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