RE: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?

["Bernie Volz" <[e-mail]>]

There was some discussion about adding a "configuration lifetime" option for
Information-Request/Reply messages. This would be similar to the address
lifetimes and the idea would be that this would give the client an
indication of when to obtain updated configuration information. While this
does not solve the problem completely, it would help solve the problem when
scheduled changes in the network are planned.

We may also want to have clients that initiate an Information-Request after
detecting a configuration change that may invalidate existing information
(such as prefixes in configuration information that are no longer valid) use
a random delay before sending the Information-Request (just as they would
for the 'first' Information-Request). Perhaps this just means clarifying
what is meant in section 18.1.5 (RFC 3115) by first:

   The first Information-request message from the client on the
   interface MUST be delayed by a random amount of time between 0 and
   INF_MAX_DELAY.

There are also larger issues here when renumbering happens as the client may
need to its DNS information (dynamic DNS), etc. So, when renumbering happens
(new addresses are added or old ones are deprecated), the client needs to do
some thinking and one of the outcomes is to obtain updated configuration
information.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tim
Chown
Sent: Thursday, November 13, 2003 4:00 PM
To: SHIRASAKI Yasuhiro
Cc: [e-mail]; [e-mail]
Subject: Re: [dhcwg] Renumbering DNS with stateless DHCPv6 - bug?

> Both setting the trigger of re-request on renumbering of prefix in RA,
> and a multicast Reconfigure message might cause all nodes to rush on
> the single DHCPv6-lite server for information-request reply exchange.
> It could work with small number of clients though.

I guess you could add some random delays, but you should also scale your
DHCPv6 server provision to have multiple servers?

I guess we can say that:

(1) Automatic renumbering is broken if people hard-code data in clients

(2) If a secure environment for reconfigure is needed, a multicast message
    adds some complexity

(3) The Reconfigure message is really designed for a fully stateful DHCPv6
    environment, not a purely stateless one providing options info (?)

(4) Periodic polling of the DHCPv6 server by clients allows renumbering
    but is not a full solution for more rapid (unplanned) renumbering.

(5) There isn't really a ethod now for a client to be informed of a
    renumbering event of a stateless DHCPv6 option (DNS, NTP)

(6) We don't want to use RA method because that would also mean an NTP
    extension for RA (?)

(7) If the network renumbers, statelessly configuring hosts should/could
    use the new prefix seen on an RA as a hint to re-request DHCPv6
    options if the O bit is set.

So is something overlooked, or do we not feel we need a solution to (5),
given we could use (7)?   Not sure how explicit (7) is...

Tim

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg




_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg