Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

["Bernie Volz (volz)" <[e-mail]>]

This is indeed an interesting case to consider.

First, my own feeling is that at least for a Renew, if the server has no record of the client at all [on that particular link], I think it should definitely return NoBinding. The intent with the being able to add a 'new' binding to an existing set in the Renew was not to allow a client to essentially 'start at Renew'. I didn't check the latest Stateful Issues text but if we don't have that there, we do need to clean this up to add it. This would I think solve this issue for Renew. Note also that for any addresses/prefixes that the client claims it is using (i.e., by providing them in the Renew) but the server does not have, the server must either (1) assign the address/prefix if there is no conflict or (2) return 0 lifetimes if there is a conflict.

Rebind in this particular case is more difficult, since the server doesn't know whether the bindings are 'existing' or 'additional' (except perhaps whether any addresses/prefixes are present in the Rebind). But in this case we're not really in trouble at all since the server SHOULD be assigning the client any existing addresses or prefixes in the Rebind request - unless it is unable to do so because it has conflicting information. The NoAddrAvail/NoPrefixAvail is only in the case where the binding has no leases and the server is unable to allocate ones.

The important point here is that Rebind is always assumed to assign the addresses/prefixes the client claims it is currently using (of course if the server has conflicting information, it can return the addresses/prefixes with 0 lifetimes).

The points that are important here:
- For a Solicit and Request, the server assumes that the client is NOT presently using any of the addresses/prefixes specified. Therefore, it is much freer to ignore these (i.e., treat them as very "mild" hints).
- For a Renew and Rebind, the server MUST assume that the client is presently using any of the addresses/prefixes specified (excepting a hint with 0::0). The server MUST either allocate the address/prefix (if not already existing) or must return 0 lifetimes to indicate to the client to stop using the addresses/prefixes.

Note also that it is important for a client to send its current addresses/prefixes when sending a Renew/Rebind.


So, I don't think there are any issue with this case if on theRenew/Rebind the server sends the NoAddrsAvail/NoPrefixAvail for a 'new' binding that has no 'in-use' address/prefix present by the client.


Note: This situation is a bit tricky anyway since there is no way for the server to know what addresses/prefixes are in use. And the server may well assign a client that sends a Solicit (/Request) an address or prefix that is already in use by another client, before that other client sends a Renew/Rebind. (This is one of the reasons that Failover has worked out well in DHCPv4 - since it provides another place for the data to be stored to avoid loss of state). I guess one "solution" might be to not allow new addresses/prefixes to be assigned for whatever lifetime would assure at lease a Renew (i.e., >50% of the lease time). But that is not nice to new clients either :).

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Monday, July 07, 2014 2:31 PM
To: Bernie Volz (volz)
Cc: [e-mail]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

At Thu, 3 Jul 2014 18:26:10 +0000,
"Bernie Volz (volz)" <[e-mail]> wrote:

> Yes, that is the one issue with changing the status codes - it breaks backwards compatibility. However, we already have changes that technically break this (such as the Advertise status codes). The risk for these changes should be fairly small as (1) clients are hopefully robust enough that they will handle unknown/unexpected status codes and either 'ignore' the binding (since it contains no addresses/prefixes) or restart at Solicit and (2) these are edge cases that may not have been well tested in all cases and are likely to occur rarely (i.e., mostly impact Rebinds when 'new' bindings appear which are probably not that common).

I've thought this original behavior of RFC3315 intended recovery from a server crash.  If a server crashes due to unexpected power cycle, a serious implementation bug, etc, and forgets all bindings it assigned before the crash, then the server will eventually receive a Renew (or
Rebind) from clients that it previously served but "the server cannot find a client entry" (quoting 18.2.3 of RFC3315).  With the original behavior, the server returns NoBindng, and the client will react to it by sending a Request.  The server would probably be able to create the same binding(s) for the Request as it previously did, in which case the server crash is almost an opaque event for the client('s user).

If the server returns NoAddrsAvail, and the client behaves similar to WIDE DHCPv6, however, the client will just ignore the Renew (and subsequently Rebind), and end up with using the "dangling" binding for much longer, increasing the risk of letting that binding be assigned to some other client.

A server crash would be a rare event, but shouldn't be that rare that we cannot ignore IMO.  So I'd be more careful if we change how to handle such cases.

--
JINMEI, Tatuya