Presentation on theme: "Draft-ietf-dhc-stateless-dhcpv6- renumbering-01 Tim Chown dhc WG, IETF 60, San Diego, August 2, 2004."— Presentation transcript:
draft-ietf-dhc-stateless-dhcpv6- renumbering-01 Tim Chown email@example.com 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