1 / 7

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

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.

gannon-winters
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-dhc-stateless-dhcpv6-renumbering-01 Tim Chown tjc@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 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?

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

  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

More Related