On 22.01.2013 00:24, Bernie Volz (volz) wrote:
>> The original text says to return an IA_* with no addr/prefix and a
>> status code "NoBinding". Now, if we cannot fulfill the binding, we
>> do the same thing, but we don't include a status code. Is that
>> right?
> 
> Hum ... perhaps it is best to follow the Request and return
> NoAddrsAvail status in the IA_* option (of course we'd need to update
> RFC 3633 text then as well to return NoPrefixAvail).
> 
> The choices now seem to be: 1. Just return the IA_* option (empty). 
> 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) --
> following Request logic. 3. Return IA_* option with NoBinding --
> following existing Renew logic for unknown bindings. 4. Don't return
> the IA_* option (I think this is not a good choice and believe you
> don't either).
> 
> Perhaps new #2 is the best as it matches the Request ... Renew and
> Request are really very similar anyway - the main differences were: -
> We are telling the server the client is renewing (thus is using the
> leases) - No new bindings were 'allowed' -- this is now not true and
> what we are proposing to change.
Agree. Include IA_* with status code (#2 or #3, depending on the
situation) in it is my preference as well. Ideally we should do that for
every response server generates, regardless of the message type that
triggered it (solicit, request, renew, rebind, but also decline and
confirm).

A question about NoAddrsAvail status. The typical meaning is obvious (we
run out of addresses), but some implementations (e.g. dibbler) allows
you to specify that each client can get up to specified maximum number
of addresses. If you configure that to two, and client sends three
IA_NAs, two of them will be assigned and the third one will get
NoAddrsAvail status (within 3rd IA_NA). Is this allowed behavior within
the proposed text?

The text should clarify that while there are currently 3 IA types
defined (IA_NA, IA_TA, IA_PD), there may be more defined in the future
and the same approach will apply to them. I'm not sure how likely new IA
types are, but there's one DHC draft that defines IA_PA and it seems to
be alive (draft-ietf-dhc-host-gen-id-04).

Another aspect I'd like this draft to clarify is whether REPLY sent as a
response to REQUEST must include exactly the addresses/prefixes sent in
REQUEST. Currently strict interpretation of the 18.2.1 section of
RFC3315 (6th paragraph) says that is must reject it:

   If the server cannot assign any addresses to an IA in the message
   from the client, the server MUST include the IA in the Reply message
   with no addresses in the IA and a Status Code option in the IA
   containing status code NoAddrsAvail.

We should update that text to allow other addresses being assigned if
that specified address/prefix is no longer available. Here's a rationale
for it. Currently when server sends Advertise, it should keep the
addresses and prefixes in a not well defined state. They are not leased
yet (there's specific text that forbids forming lease at that time), but
they are reserved for a short time with the expectation that the client
will send Request shortly. This short-term reservation is annoying and
unnecessary. It would be much simpler if the server sends address X in
Advertise, but when the client sends Request with X in it, server sends
Reply with address Y instead. ("sorry, someone else got X, here's Y for
you"). There's a specific scenario, where this is very helpful. Imagine
a case where large network recovers after blackout and you have
thousands of clients trying to get addresses. Server will respond faster
if it only needs to complete address/prefix selection and send the
advertise (without needing to update its database to mark the address as
temporary reserved).

Also, some comments about specific sections of the text:

Section 4.2
It would be better to says failure status codes (i.e. other than
Success), rather than enumerate them explicitly.

As said above, I very much prefer to include status codes in IA. I think
the argument about status codes in global scope in somewhat dubious. Old
clients that will not find status code in global scope will try to get
an address from IA and find out that it is not there.

Anyway, if you care about backward compability, I propose to add the
following text: Server MUST include status code in each IA and MAY
include in global scope.

Imagine a case, where client requests IA_NA, IA_TA and IA_PD. Server
assigns only non-temporary (NA) address, but no temporary or prefix.
What would the global status be: Success, NoAddrsAvail or NoPrefixAvail?
There's no valid answer to that question.

Section 4.5
Since this proposal extends CONFIRM to cover IA_PD as well, it would be
useful to have the capability to say: this address is valid here, but
that prefix is not. For the we need the capability to provide per IA
response. I would like to have section 18.2.2 of RFC3315 updated.

We can add the same text as proposed in section 4.2 (MUST include status
in IA, MAY include in global scope). I think this approach would be
backwards compatible - old clients would just ignore received extra IA
options in CONFIRM.

Section 4.6
How would the "client get back a lease" work? This is all happening on
the server side, right? The server remembers that the client used
address X last time and since it is free when client tries to renew it,
server may as well assign it again. That's my interpretation and I hope
you meant that. The other interpretation would be "the client can use
its address past its expiration time, just needs to send RENEW". We
should reword this section to make it clear that this is not the case.
I think rewording it as "A client can attempt to get back a lease by
using RENEW message, but must adhere to server's response". This is
basic common sense for anyone dealing with DHCP, but I've heard scary
ideas on more than one occasion, so it's better to be very clear.

I would very much prefer that client that released address or prefix
used Request rather than Renew. I don't like the idea, but since Renew
and Request will be almost identical, I can live with it.

I strongly support this work going forward (with or without my comments).

Tomek

p.s.
A request for Bernie and Ole: Once you guys are done with this draft,
please don't throw away your notes and comments that you chose to not
include. They'll be useful once we decide to start rfc3315bis work.





> 
> We could do the same for the Rebind.
> 
> BTW: The case for a Rebind where the server can't find the client
> entry for the IA is not covered in RFC 3315 (it is if the addresses
> are no longer appropriate, but not otherwise). In some ways, this
> missing text leaves it up to the server (which for some cases, may be
> good - for example, Failover may trust the client and if there is no
> conflict, the server may want to respond -- that is what we do in
> V4). In other instances, the server might want to drop the Rebind or
> respond with NoBindings to force client back to Solicit? Also, the
> Rebind is missing the text that allows the server to change the
> addresses as appears in Renew.
> 
> Opinions?
> 
> - Bernie
> 
> -----Original Message----- From: dhcwg-bounces@ietf.org
> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent:
> Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG;
> Ted Lemon Subject: Re: [dhcwg] WGLC:
> draft-ietf-dhc-dhcpv6-stateful-issues-03
> 
>> Regarding 4.2, how is that? It always means no addresses available
>> but may mean prefixes available.
> 
> Yes of course; I should have reviewed 3633.
> 
>> Regarding 4.4, I would expect the server to return the IA_* option
>> but without any IAADDR/IAPREFIX options. (The server would not
>> really create a record of this binding since it has no leases.)
>> Perhaps the text should be clarified regarding this.
> 
> The original text says to return an IA_* with no addr/prefix and a
> status code "NoBinding". Now, if we cannot fulfill the binding, we do
> the same thing, but we don't include a status code. Is that right?
> 
>> Note that perhaps a question exists as to which behavior to
>> document for the Reply in this case: 1. Return the IA_* option,
>> empty. 2. Do not return the IA_* option. Either approach would
>> work. 1 may provide more information to the client (but client
>> implementers may prefer 2) -- it is also sending back what the
>> client sent (since it had no IAADDR/IAPREFIXes to include).
> 
> (1) makes more sense to me because the server is explicitly
> acknowledging the IA_*.
> 
> - Bud
> 
>> Regarding 4.5, ok one of those edits can be done in a -04 (after
>> 28th when WGLC ends). Usually the RFC-Editor also catches things
>> like this, but best to give them a better document to start with.
>> 
>> - Bernie
>> 
>> -----Original Message----- From: dhcwg-bounces@ietf.org
>> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bud Millwood Sent:
>> Monday, January 21, 2013 10:28 AM To: Gaurav Halwasia (ghalwasi) 
>> Cc: dhc WG; Bernie Volz (volz); Ted Lemon Subject: Re: [dhcwg]
>> WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03
>> 
>> 4.2: Proposed solution: No change.  For backwards compatibility,
>> the NoAddrsAvail Status Code option when no addresses are available
>> will be kept in the global scope for Advertise messages.
>> 
>> Question: Does it need to be further clarified that in Advertise,
>> "NoAddrsAvail" now may mean "SomeAddrsAvail"?
>> 
>> 4.4: Note that clients that communicate with servers that do not
>> support this updated Renew processing will receive the NoBinding
>> status for the IA which had no bindings.
>> 
>> Question: isn't this also a valid response if the server does
>> support updated Renew processing, but cannot fulfill the binding
>> for the IA?
>> 
>> 4.5: It lets a server without a binding to reply to the message,
>> under the assumption that the server only needs knowledge about the
>> prefix(es) on the link, to inform the client that the address is
>> likely valid or not.
>> 
>> - Change "lets" to "enables" or "allows", alt. remove "to" between
>> "binding" and "reply".
>> 
>> - Bud
>> 
>> 
>> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi)
>> <ghalwasi@cisco.com> wrote:
>>> Thanks for taking care of comments. I agree with you point
>>> regarding point (3).
>>> 
>>> -Gaurav
>>> 
>>> -----Original Message----- From: Bernie Volz (volz) Sent:
>>> Wednesday, January 16, 2013 2:38 AM To: Gaurav Halwasia
>>> (ghalwasi); Ted Lemon; dhc WG Subject: RE: WGLC:
>>> draft-ietf-dhc-dhcpv6-stateful-issues-03
>>> 
>>> Hi:
>>> 
>>> Thanks for the comments, I've made some comments below (BV>).
>>> 
>>> Let's wait until the 28th before I draft the -04 version.
>>> Hopefully there will be more comments!
>>> 
>>> - Bernie
>>> 
>>> -----Original Message----- From: dhcwg-bounces@ietf.org
>>> [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia
>>> (ghalwasi) Sent: Monday, January 14, 2013 10:47 PM To: Ted Lemon;
>>> dhc WG Subject: Re: [dhcwg] WGLC:
>>> draft-ietf-dhc-dhcpv6-stateful-issues-03
>>> 
>>> I read/reviewed this document and I support this document to move
>>> forward.
>>> 
>>> I do have some comments and it would be good if authors can
>>> consider them. Even otherwise I support this document.
>>> 
>>> 1.) In Abstract :-
>>> 
>>> "Implementation experience of the CPE model described in has
>>> shown multiple issues" I think you wanted to specify RFC6204
>>> after "described in"
>>> 
>>> BV> Yes.
>>> 
>>> 2.) Section 4.2 Placement of Status codes. In Reply messages IA
>>> specific status codes (NoAddrsAvail, NotOnlink, NoBinding) are
>>> encapsulated in the IA option. I think we should include
>>> "NoPrefixAvail" as well in the above line. I see no reason why it
>>> should not be.
>>> 
>>> BV> Yes. Might be best to use (i.e.) too so that it is clear that
>>> this is just a partial list.
>>> 
>>> 3.) For Confirm message. As I understand, we are now allowing
>>> CONFIRM message for IA_PD. I think we should update the
>>> definition of CONFIRM message in RFC3315 which currently only
>>> talks about *address*
>>> 
>>> <snip> CONFIRM (4)        A client sends a Confirm message to
>>> any available server to determine whether the addresses it was
>>> assigned are still appropriate to the link to which the client is
>>> connected. </snip>
>>> 
>>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix
>>> allocation. A RFC 3315bis would definitely want to reword it as
>>> such (as I would expect it to combine 3315 and 3633). This really
>>> falls into the changes to RFC 3633 that it would extend Confirm
>>> to include prefixes. We tried (I hope) to keep the RFC 3315
>>> changes consistent with what RFC 3315 contained and PD changes to
>>> RFC 3633. There might be more we could add to RFC 3633, but do we
>>> really think that is necessary? I guess we could replace
>>> "addresses" with something more generic ("configuration
>>> information explicitly assigned to the client", which comes from
>>> the definition of binding in RFC 3315), but I think that doesn't
>>> really improve anything.
>>> 
>>> BV> Thus, I will not make this change.
>>> 
>>> 
>>> Thanks, Gaurav -----Original Message----- From:
>>> dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
>>> Of Ted Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG 
>>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03
>>> 
>>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) <volz@cisco.com>
>>> wrote:
>>>> A 2nd Query regarding this as I heard nothing since the first.
>>> 
>>> Oops, sorry about that, Bernie.
>>> 
>>> Folks, the authors of this draft feel it's ready for a WGLC.
>>> There's been substantial discussion and comment already.   This
>>> is pretty important IPv6 deployment work, so more eyes are
>>> better.   Please review the draft and indicate whether or not you
>>> feel it is ready to be published.   We have been getting very
>>> anemic responses to working group messages recently.   Your
>>> response matters, so please do respond.
>>> 
>>> We will evaluate consensus after January 28.   Thanks!
>>> 
>>> _______________________________________________ dhcwg mailing
>>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 
>>> _______________________________________________ dhcwg mailing
>>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 
>>> _______________________________________________ dhcwg mailing
>>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________ dhcwg mailing list 
>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 
>> _______________________________________________ dhcwg mailing list 
>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________ dhcwg mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg 
> _______________________________________________ dhcwg mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>