On Thu, 2013-06-27 at 22:45 -0700, Mark ZZZ Smith wrote:
> 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.
That's debatable according to Microsoft. Send an RA past with the M flag
unset and watch the addresses get dropped! Valid schmalid. I consider
that behaviour a bug, but opinions do apparently differ. The way you
describe it is how it should be, but sometimes isn't.
> 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.
There is no session...? Not sure what you are saying here.
> 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
Not to those values, but the RFC does say that they should be set with
reference to the preferred and valid lifetimes:
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any addresses in the IA_NA before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are .5 and .8 times the
shortest preferred lifetime of the addresses in the IA that the
server is willing to extend, respectively. If the "shortest"
preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
T2 values are also 0xffffffff.
But it can be left to the client, which would then presumably choose
not-dissimilar values:
If the time at which the addresses in an IA_NA are to be renewed
is to be left to the discretion of the client, the server sets
T1 and T2 to 0.
> 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.
There is no session...? The RFC *does* say that if the client cannot
renew its addresses before they expire it must stop using them. It must
also remove them if, during RENEW or REBIND, the responding server
authoritatively rejects them (see sections 18.2.4 and 19.4.5) by setting
their lifetimes to zero.
> 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.
well - yes - but the responding server might set them to zero. Or it
might return the same values as last time, refreshing the lease. It
could even shorten the lease without terminating it. But from the
client's perspective, the RENEW and REBIND messages are absolutely about
the client seeking to extend its use of its addresses. I'm not sure I
see the distinction in your statement above.
> 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.
Well, no. How does the host know they've "disappeared" anyway? There is
no "session". If the host doesn't see RAs for long enough the valid
lifetime of a SLAAC expires and the address must be dropped. If the host
doesn't get answers to RENEW and REBIND messages, the valid lifetime of
a an address acquired via DHCPv6 expires and the address must be
dropped. It's a pretty simple setup, really.
The question that started all this was whether a REBIND can ever be used
by a server to extend the lease on an address it didn't allocate. Short
answer is "no". The longer answer is "no, unless there is some kind of
sharing of IAs happening, which is not specified in RFC3315".
Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email protected])
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
