----- Original Message -----
> From: Karl Auer <ka...@biplane.com.au>
> To: IETF IPv6 <ipv6@ietf.org>
> Cc:
> Sent: Friday, 28 June 2013 10:32 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
>
> On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:
>> Perhaps a DHCPv6 server could have a "promiscuous mode" where it
>> accepts and permits the addresses it doesn't know about in REBIND
>> messages, with an upper total limit to prevent DoS.
>
> It needs to know about them at least in so far as the server is
> responsible for the range, and knows that the addresses concerned are
> appropriate for the client's link.
>
>> If a host resorts to a DHCPv6 REBIND, and the server doesn't know
>> about the addresses, the host should continue to use the addresses
>> while they continue to have a valid lifetime.
>
> *Stopping* using inappropriate addresses is thoroughly dealt with, both
> in RENEW and REBIND, and in the eventual expiry of addresses if neither
> of those mechanisms is working.
>
> The issue that REBIND is supposed to solve, though as it turns out, only
> with the addition of a moving part that no-one has actually built yet,
> is the problem of allowing a client to *continue* using an address,
I think a client is allowed to continue to use an address if the address's
valid lifetime is non-zero, regardless of how that address was acquired, be it
stateful DHCPv6, SLAAC or static.
Stateful DHCPv6 doesn't seem to tightly bind the state of addresses it issues
to the state of the DHCPv6 session, such that if the DHCPv6 session goes away
the addresses go away. If it did, I think there would be would be statements in
RFC3315 to set T1 and T2 timers to the values intended for prefix preferred and
valid lifetimes, there would be no need for preferred and valid lifetime fields
in the IAs for addresses, and there would be statements saying that if the
DHCPv6 session fails for any reason then the client MUST remove the addresses
acquired during that session.
I think this means that at RENEW or REBIND time, the client is only checking to
see if there are updated values for the addresses (and other options), and to
register a continuing interest in using the addresses. The client is not
seeking permission to continue to use the addresses, such that absence of the
DHCPv6 server would mean that it doesn't have permission any more. If the
client has non-zero valid lifetimes for the DHCPv6 supplied addresses, that is
all the permission it needs to continue to use them.
I think this is what allows SLAAC and stateful DHCPv6 to co-exist, which then
allows a transition between one method and the other. The only arbiter of
whether an address on a host is valid or deprecated is the host's own values of
the preferred and valid lifetimes. Stateful DHCPv6 or RA PIOs can be used to
change those values, indirectly controlling the address validity, but
disappearance of the DHCPv6 server or the router issuing PIO containing RAs
shouldn't cause the addresses that were configured using that method to then
immediately become invalid.
Regards,
Mark.
> even
> if the server that originally allocated that address is not answering
> the phone.
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
>
> GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
> Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
