Re: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

[Timothy Winters <[e-mail]>]

Hi Bernie,
	I'm also very interested in seeing this draft progressing.   There has been some confusion among CE Routers about interaction of stateful options that this document helps clear up.  

	I have some more comments that I will be sending along shortly.

Regards,
Tim

On Nov 25, 2013, at 9:30 AM, STARK, BARBARA H <[e-mail]> wrote:

>>> The 04 draft has expired and I'd like to publish a revised draft.
>>> 
>>> However, as this is a WG document, I can't just make changes on my own -
>> I need support for the WG for changes.
>>> 
>>> And I sent this out a while back (twice) but, to my knowledge, received NO
>> input.
>>> 
>>> So, I will once again solicit feedback as to whether people support this or
>> not.
>>> 
>>> If I do NOT receive any feedback (either positive or negative), the only
>> course of action is to ABANDON the stateful-issues work as it seems that
>> there is NO interest in this work and therefore no reason to continue it.
>>> 
>>> I'm really surprised at the lack of feedback given that the community at one
>> time was very interested in this work and wanted to resolve the issues with
>> "combining" RFC 3315 and 3633. This also was supposed to be input into the
>> RFC 3315bis work ...
>> 
>> I for one is very supportive of this work.
>> I don't think you can build an IPv6 CPE without it.
>> 
>> I also thought Tim Winters from UNH strongly supported this, based on IPv6
>> CE ready logo testing?
> 
> I definitely think the draft is important.
> For the specific rebinding issue being asked about -- the suggested approach makes sense to me, but I don't have enough detailed DHCPv6 expertise to take a strong stance.
> Barbara
> 
>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Bernie Volz (volz)
>>> Sent: Monday, June 10, 2013 3:55 PM
>>> To: [e-mail]
>>> Cc: Kim Kinnear (kkinnear); Ole Troan (otroan); Ralph Droms (rdroms)
>>> Subject: [dhcwg] 2nd Try - draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
>>> 
>>> As this is a WG document, I would like some feedback from people about
>> whether the proposed change is "valid". I received no feedback or discussion
>> about this Rebind issue. While this technically doesn't change 3315 as 3315
>> permits a Rebind to return the NoBinding status in the Reply and 18.2.4 never
>> mentions adding 'new' addresses, I think this may well be a valid
>> interpretation of what is not said in 18.2.4.
>>> 
>>> To perhaps make the intended change more clear, here's some potential
>> wording for replacement text of 18.2.4 of RFC 3315. Some text was moved
>> and new text has + in column 1. This may not be the final text (suggestions to
>> improve greatly welcome).
>>> 
>>> 18.2.4. Receipt of Rebind Messages
>>> 
>>>   When the server receives a Rebind message that contains an IA option
>>>   from a client, it locates the client's binding and verifies that the
>>>   information in the IA from the client matches the information stored
>>>   for that client.
>>> 
>>> +  If the server finds the addresses in the IA for the client and the
>>>   server determines that the addresses in the IA are appropriate for
>>>   the link to which the client's interface is attached according to the
>>>   server's explicit configuration information, the server SHOULD send
>>>   back the IA to the client with new lifetimes and T1/T2 times.
>>> 
>>>   If the server cannot find a client entry for the IA and the server
>>>   determines that the addresses in the IA are not appropriate for the
>>>   link to which the client's interface is attached according to the
>>>   server's explicit configuration information, the server MAY send a
>>>   Reply message to the client containing the client's IA, with the
>>>   lifetimes for the addresses in the IA set to zero.  This Reply
>>>   constitutes an explicit notification to the client that the addresses
>>>   in the IA are no longer valid.  In this situation, if the server does
>>>   not send a Reply message it silently discards the Rebind message.
>>> 
>>> +  If the server cannot find a client entry for the IA and the server
>>>   determines that the addresses in the IA are appropriate for the link
>>>   to which the client's interface is attached according to the server's
>>>   explicit configuration information, and the addresses are not in use,
>>>   the server MAY assign the addresses to the client and send a Reply
>>>   message to the client with new lifetimes and 1T1/T2 time for the
>>>   bindings. If the server cannot assign the addresses to the client,
>>>   the server returns the IA containing no addresses with a Status Code
>>>   option set to NoBinding in the Reply message.
>>> 
>>> +  Note: A server SHOULD NOT provide additional bindings to the client
>>>   as the client could accept a Reply from a different server (this is
>>>   the same issue as in the Discussion under the Rapid Commit option,
>>>   see section 22.14).
>>> 
>>>   The server constructs a Reply message by setting the "msg-type" field
>>>   to REPLY, and copying the transaction ID from the Rebind message into
>>>   the transaction-id field.
>>> 
>>>   The server MUST include a Server Identifier option containing the
>>>   server's DUID and the Client Identifier option from the Rebind
>>>   message in the Reply message.
>>> 
>>>   The server includes other options containing configuration
>>>   information to be returned to the client as described in section
>>>   18.2.
>>> 
>>> 
>>> There are four possible response to a Rebind (note that I'm restricting my
>> wording here to addresses as that is all RFC 3315 speaks to, but you can
>> replace "address" with "delegated prefix" for 3633):
>>> 1.       No response. This is used when the server does not have a record of
>> the bindings and cannot determine whether the bindings are on-link. As the
>> addresses may be valid, but this server has insufficient information to
>> determine this, it is best it remain silent. If other servers respond, the client
>> will have its information. Otherwise, the client will deal with the issues when
>> the lifetimes expire.
>>> 2.       Reply with Bindings with 0 lifetimes. This is used when the server
>> determines that the bindings are not on-link.
>>> 3.       Reply with NoBinding status code(s) response. This is used when the
>> server is unable to assign the addresses requested or the client needs "new"
>> information. As this will cause the client to return to sending Request, it
>> provides the server another and better chance to provide the client
>> complete information.
>>> 4.       Reply with updated lifetimes and T1/T2 times. This is when the server
>> has a record of bindings and they are still valid or is able to assign what the
>> client already has.
>>> Based on other changes to stateful-issues, I'd also indicate that the server
>> MUST pick one of these for ALL of the IA_* options. And, I think the server
>> should pick the lowest numbered respond based on processing each binding.
>>> 
>>> Note again the server should NOT allocate any "new" addresses to the
>> client even if its current configuration would dictate as it would not know if
>> the client uses this information, UNLESS the server is configured honor Rapid
>> Commit. If there is new information that should go to the client, the server
>> should either respond as in case 3 above or initiate a Reconfigure of the
>> client.
>>> 
>>> -          Bernie
>>> 
>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Bernie Volz (volz)
>>> Sent: Monday, May 13, 2013 2:04 PM
>>> To: [e-mail]
>>> Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-04.txt
>>> 
>>> Hi:
>>> 
>>> This is an updated version of this document. It includes a few minor
>> changes from the WG last call and is there mostly to restore this document as
>> it has expired a few days ago.
>>> 
>>> I still have a bunch of the comments from the WG Last Call in
>> January/February to address.
>>> 
>>> There is also one key issue that will need some discussion from the WG. In
>> particular, handling of Rebind requests.
>>> 
>>> One major flaw with respect to the Rebind message handling in RFC 3315
>> and this draft is that as the client has sent the Rebind to multiple servers, all
>> of which could respond, there is no way for a particular server to know
>> whether its Reply will be accepted by the client. This is essentially the same
>> issue with using Rapid Commit in a Solicit when there are multiple servers
>> available.
>>> 
>>> I think the Rebind processing should essentially be changed so that a server
>> will either return everything the client requested to be rebound (and nothing
>> more) or nothing (in which case it returns NoBinding status for all bindings).
>>> 
>>> If the server is willing to extend (or grant) the existing leases, the Rebind is
>> fine. If the server is unwilling or unable, then it should force the client back
>> into a Request phase as described in RFC 3315 section  18.1.8. That 18.1.8
>> section is also the only place a NoBinding status appears to be mentioned in
>> terms of the Rebind.
>>> 
>>> -          Bernie
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg