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

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

Hi Jinmei:

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).

These are clearly concerns we have and it would be great to hear from client implementers to understand whether there are any potential nasty impacts. It may also be an interesting area to perform some tests on a 'updated' server to see how a sampling of client implementations handle these situations.

Regarding revising Section 18.1.8 and providing the text in the draft, if I recall that was plan and part of the reason to hold off on making this change - there wasn't sufficient time to do this 'properly' before the deadline.

Thanks for your review and comments!!!

- Bernie

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

At Mon, 30 Jun 2014 16:55:59 +0000,
"Bernie Volz (volz)" <[e-mail]> wrote:

> There is one outstanding issue that we'd like to get feedback on from folks (as well as of course the other changes made). We can discuss on the mailing list but will also discuss at the Toronto IETF DHC WG Session.
>
> This is the issue of which status codes Renew and Rebind should use when a server is unable to provide "leases" for a binding. Presently the text says to use NoBinding and part of that reason was that this is consistent with what is currently written in RFC 3315. But it may be better to use NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this some and here is some data regarding this issue:

Many points are discussed after these paragraphs, and I cannot easily say which is the best with confidence.  But I figure out that it's at least incompatible with existing client implementations if the server returns something other than NoBinding.  According to RFC 3315, the client will subsequently send a Request for the IA to (re-)establish the binding.  If the server doesn't return NoBinding, and if the client doesn't regard it as the need for some recovery action (sending Request or Solicit), then the binding for the IA will eventually expire (from a quick look at the code, this seems to be what would happen with the WIDE DHCPv6 client implementation:
http://sourceforge.net/projects/wide-dhcpv6/).  It doesn't seem to be a good idea to break backward compatibility this way unless there's a strong reason for that.

BTW, as I read the entire draft it occurred to me that this draft should probably describe what a client should do upon receiving a Reply (in response to various types of messages) more specifically, and with specific proposed text to revise Section 18.1.8 of RFC 3315.
Discussions on the client behavior on receiving a Reply will also be related to the question on NoBinding vs others.

--
JINMEI, Tatuya