Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

[Tim Chown <[e-mail]>]

On Sat, Nov 15, 2003 at 12:48:23PM -0500, Bernie Volz wrote:
> DHCPv6 is no different from what we have with DHCPv4. DHCPINFORM in DHCPv4
> has no "lease time" or "lifetime" for the parameters obtained. The implied
> behavior for DHCPv4, as it should be for DHCPv6, is that when the address is
> reassigned (through some other means), the client should naturally assume
> that its current configuration parameters are suspect and hence send a new
> DHCPINFORM (or DHCPv6 Information-Request).

Hi Bernie, thanks for the comments.

I think that in IPv6 we should be trying to incorporate aids to easy(er)
renumbering, for a number of good reasons.  Also in IPv6 networks it is now 
quite probable that many networks will statelessly autoconfigure addresses 
but use stateless DHCPv6 for options (DNS and NTP in particular).  So it's
a bit different to IPv4.

> There is no prohibition against a client issuing (DHCPv6)
> Information-Request messages (or DHCPv4 DHCPINFORM) whenever it believes the
> previously obtained configuration information may be out of date. Note also
> that DHCPv6 servers may send Reconfigure messages as well (though
> draft-ietf-dhc-dhcpv6-stateless-01.txt is silent as to whether stateless
> clients support this).

But this is the point - the DHCPv6 server can't send a Reconfigure message
to the client, because the client is not using DHCPv6 for stateful address
assignment, only for the DNS/NTP/other options (and so I believe the stateless 
DHCPv6 server won't have a client list to unicast the messages to?).

There could at the very least be a timer for the valid lifetime of the
stateless DHCPv6 options, so that planned ("make before break") renumbering 
as per draft-baker-ipv6-renumber-procedure-01 can be more readily achieved.  
That would not necessarily help with other renumbering events, but it would 
seem useful to have.
 
> When a client detects that it may be on a different network, whether that is
> because it has detected a link state change (such as because the network
> cable was reconnected), been powered on (such as from a standby state), or
> has its address(es) reconfigured through some non-DHCP mechanism (perhaps
> via router advertisements), it should take steps to validate its
> configuration information.

I agree you could use a new RA (with O bit set) as a cue to get new DHCPv6 
option information; this has also been suggested on the dhcwg list.  But it
wouldn't include the case where the DNS or NTP server is renumbered within 
the existing network.
 
> We probably should have added to RFC 3315 a similar section for
> Information-Request as exists for the stateful case (see section 18.1.2,
> Creation and Transmission of Confirm Messages).

I think anything we can add now to make IPv6 renumbering more easy to do
(both compared to IPv4, and because of existing IPv6 limitations like having
no PI address space) should be considered, including a method to deliver a 
stateless DHCPv6 Reconfigure message to clients.

Tim

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