draft-ietf-dhc-stateless-dhcpv6-renumbering-01

1
draft-ietf-dhc-stateless-dhcpv6-renumbering-01

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

2
The crux

• When a node is using only Stateless DHCPv6
  (RFC3736), how can the node be informed of
  changes in other configuration options, e.g. new
  or replacement DNS server, DNS search path, etc?
• This issue is important for a number of
  scenarios, including network renumbering (see
  draft-baker-ipv6-renumber-procedure-01)
• At present there no good method for this

3
Scenarios

• Include
• Site renumbering (planned or unplanned)
• DNS server renumbering
• New NTP server
• Change in DNS search path

4
Stateless DHCPv6

• Stateless DHCPv6 only handles/serves non-address
  data/options.
• It doesnt maintain state about clients that
  query it, thus it cannot target a unicast
  Reconfigure message at clients to which options
  have been served
• There is no lifetime associated with the served
  options
• So how can the host learn of changes?

5
Requirements

• It should support planned renumbering it is
  desirable to support unplanned renumbering.
• Security is important e.g., avoiding denial of
  service attacks mounted through Reconfigure
  messages sent from an attacker.
• It must be possible to update options even if the
  network is not renumbered.
• It is desirable to maintain the "stateless"
  property i.e., no per-client state should need
  to be kept in the server.

6
Solution space

• Adding a Lifetime timer to clients for stateless
  DHCPv6 options
• Good for planned events, or with a small timeout
  maybe for unplanned events
• Using new observed RA as a hint to request new
  information
• But doesnt cover case of new NTP server, for
  example
• A new multicast Reconfigure message
• Changing RFC2462 O flag semantics
• Toggling value could trigger Information-Request

7
Progressing this?

• Should draft discuss the preferred solution for
  posterity?
• Might be Lifetime Option, based on list
• Have proposal drafts for Lifetime and Multicast
  reconfigure message
• Lifetime option seems to meet requirements the
  best (being discussed next on agenda)
• What to do with this draft now?
• Could move discussion text to preferred solution
  draft