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

[Thomas Narten <[e-mail]>]

Tim Chown <[e-mail]> writes:

> With DHCPv6 Light for DNS option configuration, how is the client told
> that DNS options have changed?  The reconfigure message seems to be
> unicast to the clients, but if the DHCPv6 server is stateless, it won't
> have a list of clients (with leased IPs) to send that Reconfigure
> message to?

note that there are issues with unicast reconfigure. During the IESG
review of the DHCv6 spec, concerns were raised about the
appropriateness of _requiring_ that all nodes have an open port on
which DHC messages could be sent. This is viewed as a security
issue. E.g., for security reasons, some sites require that clients
have no open ports on which they are listening for arbitrary packets
from anyone. Consequently, the DHCPv6 spec was revised to make the use
of this feature more of a negotiation between the client and
server. See the RFC for details.

Point is, requiring that a node always be ready to receive an
asynchronous message from an arbitrary DHC server is potentially
problematical in practice.

Personally, I think something along the lines of Bernie's suggestion
seems the simplest. E.g., just define a lifetime that applies to all
options that don't themselves have a lifetime.  Client can then
recheck at appropriate intervals.

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

> 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

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