70 likes | 170 Views
draft-ietf-dhc-stateless-dhcpv6-renumbering-01. Tim Chown tjc@ecs.soton.ac.uk dhc WG, IETF 60, San Diego, August 2, 2004. The crux.
E N D
draft-ietf-dhc-stateless-dhcpv6-renumbering-01 Tim Chown tjc@ecs.soton.ac.uk dhc WG, IETF 60, San Diego, August 2, 2004
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
Scenarios • Include: • Site renumbering (planned or “unplanned”) • DNS server renumbering • New NTP server • Change in DNS search path
Stateless DHCPv6 • Stateless DHCPv6 only handles/serves non-address data/options. • It doesn’t 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?
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.
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 doesn’t cover case of new NTP server, for example • A new multicast Reconfigure message • Changing RFC2462 ‘O’ flag semantics • Toggling value could trigger Information-Request
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