Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

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

Again, one reason is that Advertise response to a Solicit is not necessarily the "final" information the client is allowed to use - Reply is used to communicate that (after Request or Information-Request). And the Request, Renew, Rebind are all about communicating bindings - for example if Solicit/Advertise is same as Information-Request/Reply, if client wants to refresh options, does it use Renew/Reply or Information-Request/Reply.

With the proposed changes we are actually a bit closer to supporting this because if the client wants addresses or bindings but only got other config options earlier, it would perhaps be acceptable to let it Request or Renew or Rebind with the bindings to attempt to get those bindings. But we did not take this step as it would require a few more tweaks. (Rebind may be the best choice here as that allows other servers to respond.) But this needs to be more carefully thought through and I am not sure it is worth it to do this. And in any case, perhaps done as a separate work.

---

Agreed that more review / comments especially from client implementers as to whether the changes proposed in the draft are appropriate. As the CableLabs (DOCSIS) community were pushing for this, we really need more of them to respond. If they don't, perhaps it means there is no issue and this work isn't needed as current client implementations have already figured out how to deal with the situation in an acceptable mannor.

- Bernie

On Sep 13, 2012, at 9:34 AM, "Wes Beebee (wbeebee)" <[e-mail]> wrote:

> My comments fall under the category of "optimization".
> 
> Certainly the client can drop the original transaction and issue another
> Information-Request set of messages for the rest of the information
> already contained in the original transaction.  Just out of curiosity, why
> is this behavior mandated?
> 
> While I think this work is very important, I would like to see more
> comments from others on the significant changes to the protocol that are
> contained in the document.
> 
> - Wes
> 
> On 9/7/12 12:18 PM, "Bernie Volz (volz)" <[e-mail]> wrote:
> 
>> I believe Wes' and Hemant's issues were:
>> 
>> Wes (message on Thu 8/16/2012):
>> 
>>  Why MUST the client ignore an Advertise message with no bindings?
>>  What if stateful and stateless options are carried in the same message?
>>  Does this mean the stateless options will be ignored just because the
>> stateful Options failed?
>> 
>> ---
>> 
>> Ole's answer was that basically this is how RFC 3315 operates today and
>> we didn't want to change this (we are fixing what happens if IA_NA and
>> IA_PD are requested in a Solicit and only one of these is available) --
>> which is different than the no bindings at all case. RFC 3315 basically
>> expects clients to use Information-Request in this case.
>> 
>> A while back, Ralph and I considered that this might be a good change -
>> especially given the case when M says to use stateful but the server is
>> not configured to give (the requesting client) any stateful bindings.
>> Server could effectively respond with the other configuration options.
>> But an Advertise is not the same as a Reply, so if the client was going
>> to do a Request/Reply, we'd have to change that processing to and so why
>> doesn¹t the client just do an Information-Request? (Sure, if Rapid Commit
>> is requested, server would just Reply and client would be done.)
>> 
>> If the WG feels that would be a useful change, we can certainly do this
>> change. But for this particular work, we didn't feel that change was
>> warranted. And, it might be best to do under a separate document? Or
>> something for a 3315bis?
>> 
>> 
>> Hemant (message on 8/17/2012) and Ole's response (using Ole's email on
>> 8/20/2012):
>> 
>>> +1 to Wes' comment that this document is addressing a very important
>>> problem space and the solutions are needed urgently.  However, more
>>> thought is required for the solutions.
>>> 
>>> In regards to section 4.4, if the server only checks the network
>>> configuration to reply to a Confirm message, how is it possible for most
>>> network configurations that the server determines an IA_PD is on-link?
>>> I suspect that is why RFC 3633 prohibited use of the Confirm for the
>>> IA_PD.  In any case this document should explain why did RFC 3633 have a
>>> restriction on using the Confirm for the IA_PD.  Or does network
>>> configuration include looking up the prefix pool configured on the
>>> server for allocation?  In contrast, to make an on-link determination
>>> for an IA_NA IA_Address, all the server has to do is match
>>> (longest-prefix match) all IPv6 addresses configured on the machine that
>>> the server is running on.  These addresses are clearly network
>>> configuration.  
>> 
>> right, either the server has the binding, or the server has configuration
>> that it can look up in, to verify if the client has moved or not. if it
>> has no information it MUST not reply.
>> 
>>> Section 4.1:  
>>> 
>>> # In relation to the first paragraph the document is addressing the
>>> fact that one server replies with, say, an IA_NA, while another server
>>> replies back with only the IA_PD.   Then why in section 4.7 the case of
>>> section 4.1 is deemed out of scope?   I also do not understand what does
>>> "equal" in section 4.7 mean.  Does it mean each server replies with all
>>> IAs that the deployment needs?
>> 
>> the assumption in 3315/3633 is that a client is connected to a single
>> administrative dhc domain on an interface.
>> scenarios where a client finds two DHCP servers, that are administered by
>> two different entities, are outside of the scope of 3315/3633 and
>> therefore also outside the scope of this update. there is as far as I
>> know separate work in progress on this.
>> 
>>> # In relation to the text in the last paragraph of section 4.1, if the
>>> client does not restart the Solicit retransmissions timers, what does
>>> the client do?
>> 
>> continues with the timers it has.
>> otherwise as the text says, a received advertise with a consequent
>> restart of solicit timers would result in a solicit storm.
>> 
>>> 
>>> # Other comment:  Shouldn't the header of the document have an Updates
>>> tag to signify this document updates RFC 3315?
>> 
>> good point. both 3315 and 3633.
>> 
>> ---
>> 
>> I guess the one change that I see is to assure we update the document
>> header. We can respin the document for this change.
>> 
>> Section 4.4 is just extending the Confirm to include prefixes - this
>> issue is already covered in RFC 3315 for Confirm processing:
>> 
>>                                                              If the
>> server is unable to perform
>>  this test (for example, the server does not have information about
>>  prefixes on the link to which the client is connected), or there were
>>  no addresses in any of the IAs sent by the client, the server MUST
>>  NOT send a reply to the client.
>> 
>> The section 4.1 / 4.7 issue is the single vs multiple provisioning
>> domains - we assume a single in this document.
>> 
>> 
>> If Wes or Hemant would like other changes to clarify any of their
>> concerns, we would appreciate text to be added/modified.
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: Ted Lemon [mailto:[e-mail]]
>> Sent: Friday, September 07, 2012 11:38 AM
>> To: Bernie Volz (volz)
>> Cc: dhc WG
>> Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
>> 
>> On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) <[e-mail]> wrote:
>>> Where does this Last Call stand? August 24th has passed ...
>> 
>> There were a lot of comments in the WGLC, and lot of support for what is
>> to be accomplished here, but several people raised concerns as well.
>> There were a few responses in favor of advancing the current document;
>> Hemant Singh had some suggestions, to which Ole responded.   I do not
>> know if the responses satisfied Hemant's concerns.   I raised some
>> concerns which were not really addressed.   Wes Beebe raised a concern
>> which Ole responded to, but again I don't know if Wes was satisfied with
>> Ole's response.
>> 
>> 
>> So I think this is borderline.   There's clearly widespread support for
>> what this draft is trying to do; I would like to hear from Hemant and Wes
>> as to whether they are satisfied with Ole's responses.   I tend to agree
>> with Wes' sentiment that we need to think this through very carefully; I
>> would like to see a new draft that addresses Hemant's and Wes' concerns,
>> if possible, and then do a second last call to get more review.   Does
>> that work for the authors?
>