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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 24 Nov 2013 21:56:59 +0000

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

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, June 10, 2013 3:55 PM
To: [email-masked]
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, May 13, 2013 2:04 PM
To: [email-masked]<mailto:[email-masked]>
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

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Nov 2013 13:49:09 +0100

Bernie,

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

cheers,
Ole

> 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).
>  
>    the link to which the client’s interface is attached according to the
>    server’s explicit configuration information, the server SHOULD send
>    to which the client’s interface is attached according to the server’s
> 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):
> 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.
> 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: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 25 Nov 2013 14:30:45 +0000

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

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

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 25 Nov 2013 20:53:53 +0100

> So, I will once again solicit feedback as to whether people support this
Yes, I still strongly support this work going forward.

I had a questions about placement of status codes (will post it once I
get back home next week), but regardless how my question is answered, I
support this work moving forward.

Cheers from base of the Stromboli volcano,
Tomek

---

From: Timothy Winters <[email-masked]>
Date: Mon, 25 Nov 2013 14:56:18 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Tue, 26 Nov 2013 02:10:17 +0000

This work is important and I support this document. 

-Gaurav

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, November 26, 2013 1:24 AM
To: [email-masked]
Subject: Re: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

I had a questions about placement of status codes (will post it once I get back home next week), but regardless how my question is answered, I support this work moving forward.

Cheers from base of the Stromboli volcano, Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 Nov 2013 14:04:19 +0000

Great that there is support. But what about the suggested changes?? That's what I need comments on.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Gaurav Halwasia (ghalwasi)
Sent: Monday, November 25, 2013 9:10 PM
To: Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

-Gaurav

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 27 Nov 2013 10:25:38 +0800

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

If DHC-WG really wants a RFC3315bis, I suppose we definitely need its scope.

Will 3315bis obsolete 3315 only, or cover the scope of both 3315 and 3633? 

If the answer is the later, I guess 3315bis will also cover this piece of
work.

Best Regards,

Leaf

Ps. http://www.ietf.org/proceedings/88/minutes/minutes-88-dhc 

<quote>

Tomek Mrugalski then presented the RFC-3315bis design team slides.

    Tomek: Kick off RFC3315 bis and Design Team Formation

    Tomek: - using issue tracker for WG

           - call volunteers to joint in "Editorial Team",5-6 persons

    Suresh Krishnan: site-local addrs still in use

    Tomek: ok, solved

    Jinmei Tatuya: we can go over the email archive for checking issues

    Tomek: big task

    Alex Petrescu: split the work

    Suresh: separate a mailing list for design team, ask authors of

      RFC3315 first, the issue trackers to be managed well

    Kim Kinnear: How are old RFCs deprecated?

The following volunteered during the meeting to be on the design team:

Suresh Krishnan, Andrew Yourtchenko, Alexandru Petrescu, Sheng Jiang,

Daniel Migault, Marcin Siodelski, Tomek Mrugalski, and Bernie Volz.

Michael Richardson volunteered immediately after the meeting. Tomek

and Bernie will review and follow up with team.

Note: Everyone is encouraged to provide RFC 3316/3633 corrections and

areas with interoperability issues or needing clarification.

</quote>

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, November 25, 2013 5:57 AM
To: [email-masked]
Cc: Ole Troan (otroan); Ralph Droms (rdroms)
Subject: Re: [dhcwg] 3rd & *FINAL* try before ABANDONING
draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

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.

RFC 3315bis work .

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz (volz)
Sent: Monday, June 10, 2013 3:55 PM
To: [email-masked]
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).

   for that client.

   see section 22.14).

   18.2.

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.

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.

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Volz (volz)
Sent: Monday, May 13, 2013 2:04 PM
To: [email-masked]
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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Nov 2013 02:29:23 +0000

Yes the later -- I believe we view merging 3315 and 3633 as one key goal for the 3315bis work.

This is to clean up, as much as possible, the processing of multiple IA_* types within a single request and to provide for a client to keep them in one transaction even if one IA_* type might not be available.

-          Bernie

From: Leaf Yeh [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 9:26 PM
To: Bernie Volz (volz); [email-masked]
Cc: Ole Troan (otroan); Ralph Droms (rdroms)
Subject: RE: [dhcwg] 3rd & *FINAL* try before ABANDONING draft-ietf-dhc-dhcpv6-stateful-issues-04.txt

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

If the answer is the later, I guess 3315bis will also cover this piece of work.

Best Regards,
Leaf

-          Bernie

-          Bernie

Hi:

-          Bernie