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

[神明達哉 <[e-mail]>]

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