Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

From: Sunil Gandhewar <[email-masked]>
Date: Mon, 17 Aug 2015 02:01:03 +0000

I am glad that someone came up with this draft. When we implemented such a feature, we also came across number of concerns. This document provides guidelines nicely. I have few comments.

1.       I think it should be clarified that when both the prefix and prefix-length is included in the hint, then server should give priority to what, prefix or the prefix-length. It is possible that server has different address pools and it can allocate different lengths from different address pools. In my opinion it should be prefix and not prefix-length.

2.       Section 4.2 does not mention about the combination of same or different IAID. If IAID is same then server should treat it as the client is releasing the old one and asking for new one.

3.       Server should include different combination of prefixes and prefix-lengths in Advertise (multiple choices client can have) and let client choose which matches it’s needs and request only that one. Instead of relying on Advertise from multiple servers, one server can send possible combinations. It saves a lot.

4.       Section 4.4 – here client should use new IA_ID to indicate that it is looking for new IA_PD with different hint

5.       Include reference to RFC 7550 as the new IAs are being requested during Renew and Rebind

I am thinking may be it would be better to use the word Release instead of deprecate e.g.
the client could use the
two prefixes at the same time and deprecate the old prefix after some
time interval.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, July 27, 2015 8:26 PM
To: tianxiang li; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

Please let’s keep this document focused on the prefix length hint issue. It already is clear that this is only applicable when implementing RFC 3633.

   DHCPv6 Prefix Delegation [RFC3633<https://tools.ietf.org/html/rfc3633>] allows a client to set a hint
   value in the prefix-length field of the IA_PD option to indicate a
   preference for the size of the prefix to be delegated, but is unclear
   about how the client and server should act in different situations
   involving the prefix length hint.  This document provides a summary
   of the existing problems with the prefix length hint and guidance on
   what the client and server could do in the different situation
   involving the the prefix length hint.

I’d also like to stay away from other issues (such as sending RAs). That should already be pretty clear – it would be dumb to send RAs about a prefix which has been released or is no longer valid (valid lifetime has expired) and is not a new problem related to the hints but normal operation when prefixes change (through some configuration mechanism) and is not really related to DHCPv6 at all. If you want to work on those issues, I would recommend you consider 6man.

And again, just for correctness, NoPrefixAvail is the Status Code related to PD.

-          Bernie

From: tianxiang li [mailto:[email-masked]]
Sent: Monday, July 27, 2015 9:11 AM
To: Bernie Volz (volz); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

Thank you for providing the comments.

For #1 I agree with Bernie and Alexandru. There are two cases when a server cannot provide a prefix:

1.  Servers which support prefix delegation, will not include an IA_PD option in the Advertise   message.
2. Servers which support prefix delegation but cannot provide a prefix and the time being, will return a status code of Noaddrsavail in the IA_PD option.

The current document does assume all the servers could support prefix delegation. I think we could add some text in “Receipt of Advertise message by the Client” (section 3.3&4.3) describing these cases.

For #2 Yes, the client should stop sending RAs on its other interfaces. I think we could add this text to section 4.1 “Creation of Solicit Message by the Client”

> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <alexandru.petrescu at gmail.com<http://gmail.com>> wrote:

> Hello,

> I just read draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.

> I am happy this draft exists and I have two comments.  One is more

> general question in this context, and the other a potential improvement,

> but not a request.

> The draft assumes the Client is a Host which may request a prefix len at

> some point, and another one maybe later.  It seems the prefix is to be

> used on the interface which has issued that Solicit.  And it seems to

> face a Server sure to be willing to deliver a prefix.

> 1. What is the best way to query a DHCPv6 Server to ask it whether or

> not it supports Prefix Delegation at all?

> 2. when this Router changes mind and requests a different prefix, maybe

> with a different length, a specification like

> draft-cui-dhc-dhcpv6-prefix-length-hint-issue could recommend to

> deprecate that prefix with specific consideration to below it, not just

> to the Server.

> I mean this something like this:

> Current text:

>> 1.Deprecate the old prefix right away by sending a Release message to

>> the server, and switch over to the new prefix.

> New text:

>> 1.Deprecate the old prefix right away by sending a Release message to

>> the server, and switch over to the new prefix.  And by stopping

>> sending RAs on its other interfaces with the old prefix, stop

>> propagating it in the routing protocol.

> Alex

> _______________________________________________

> dhcwg mailing list

> dhcwg at ietf.org<http://ietf.org>

> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "李天翔" <[email-masked]>
Date: Tue, 18 Aug 2015 00:25:28 +0800

Thank you for providing the valuable comments. The following are my thoughts for each bullet.

>1. I think it should be clarified that when both the prefix and prefix-length is included in the hint, then server should give priority to what, prefix or the prefix-length. It is possible that serv…

This document mainly focuses on issues with the prefix-length hint. I’m not sure when a client would request for a specific prefix, or include both the prefix hint and prefix-length hint, could you specify the use case? If the client does include both the prefix hint and the prefix-length hint, then the prefix hint would probably be given a higher priority. The server should see which of its address pools contain the prefix matching the prefix hint, if no match is found, then the server should try to honor the prefix-length hint.

>2.Section 4.2 does not mention about the combination of same or different IAID. If IAID is same then server should treat it as the client is releasing the old one and asking for new one.

Currently, the document states that if the client wants a different prefix, it would send a different IAID. As Bernie mentioned before, the best way to assure a completely new delegated prefix, is to send a new IAID in the IA_PD. The client can release the old prefix or just let it gracefully expire. Could you specify when the client would send the same IAID asking for a different prefix?

>3. Server should include different combination of prefixes and prefix-lengths in Advertise (multiple choices client can have) and let client choose which matches it’s needs and request only that one…

If the server has different address pools with different prefixes and prefix-lengths, then the selection process would be a bit complicated, because there will be different combinations of prefixes and prefix-lengths. So maybe we should try to avoid this complexity and focus on the prefix-length. I guess the question here is that even if the server is able to signify to the client the different prefix-lengths it could provide in the Advertise message, can the client decide which one best suites it? The document currently leaves the selection process to the server, as stated in section 4.2: The server should try to provide a prefix which length is no longer than the hint and closest to the hint. E.g. If the server could only provide prefixes with lengths /30,/48, and /56, and the client is requesting for a /50 in the prefix length hint, then the server should provide the /48 to the client.

>4. Section 4.4 – here client should use new IA_ID to indicate that it is looking for new IA_PD with different hint

I agree, the client should use a new IA_ID to ask for the new prefix, and use the old IA_ID to extend life time of the old prefix.

>5. Include reference to RFC 7550 as the new IAs are being requested during Renew and Rebind

Requesting for a new IA during Renew or Rebind is mentioned in RFC7550, a reference could be added.

Regards,
Tianxiang

------------------ 原始邮件 ------------------
发件人: "Sunil Gandhewar";<[email-masked]>;
发送时间: 2015年8月17日(星期一) 上午10:01
收件人: "[email-masked]"<[email-masked]>; 
抄送: "Sunil Gandhewar"<[email-masked]>; 
主题: Re: [dhcwg] two comments ondraft-cui-dhc-dhcpv6-prefix-length-hint-issue

 

 

 

the client could use the

time interval.

Regards,
 
Sunil Gandhewar
 
Juniper Networks, Inc.
 
[email-masked]

   

 
   DHCPv6 Prefix Delegation [RFC3633]  allows a client to set a hint

 

 

 

 
-          Bernie

From: tianxiang li [mailto:[email-masked]] 
 Sent: Monday, July 27, 2015 9:11 AM
 To: Bernie Volz (volz); [email-masked]; [email-masked]
 Cc: [email-masked]
 Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

 

 

 

 
  > On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <alexandru.petrescu at gmail.com> wrote: >  > Hello, >  > I just read draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00. >  > I am happy this draft exists and I have two comments.  One is more > general question in this context, and the other a potential improvement, > but not a request. >  > The draft assumes the Client is a Host which may request a prefix len at > some point, and another one maybe later.  It seems the prefix is to be > used on the interface which has issued that Solicit.  And it seems to > face a Server sure to be willing to deliver a prefix. >  > 1. What is the best way to query a DHCPv6 Server to ask it whether or > not it supports Prefix Delegation at all? >  > 2. when this Router changes mind and requests a different prefix, maybe > with a different length, a specification like > draft-cui-dhc-dhcpv6-prefix-length-hint-issue could recommend to > deprecate that prefix with specific consideration to below it, not just > to the Server. >  > I mean this something like this: >  > Current text: >> 1.Deprecate the old prefix right away by sending a Release message to >> the server, and switch over to the new prefix. >  > New text: >> 1.Deprecate the old prefix right away by sending a Release message to >> the server, and switch over to the new prefix.  And by stopping >> sending RAs on its other interfaces with the old prefix, stop >> propagating it in the routing protocol. >  > Alex >  > _______________________________________________ > dhcwg mailing list > dhcwg at ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Aug 2015 20:00:08 +0000

Hi … some comments inline below (BV>).

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Sunil Gandhewar
Sent: Sunday, August 16, 2015 10:01 PM
To: [email-masked]
Cc: Sunil Gandhewar
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

1.       I think it should be clarified that when both the prefix and prefix-length is included in the hint, then server should give priority to what, prefix or the prefix-length. It is possible that server has different address pools and it can allocate different lengths from different address pools. In my opinion it should be prefix and not prefix-length.
BV> A non-zero ipv6-prefix field in the IAPREFIX (with of course a non-zero prefix-length) should be treated as a request for THAT prefix. Nothing else.
BV> A hint is when the ipv6-prefix field in the IAPREFIX is all 0s and the prefix-length field is non-zero.
BV> A 0 in the prefix-length field (and a non-zero ipv6-prefix) is kind of an invalid request. Not clear how this should be handled – send IAPREFIX with 0 lifetimes or ignore? Might be an issue to consider for 3315bis.

2.       Section 4.2 does not mention about the combination of same or different IAID. If IAID is same then server should treat it as the client is releasing the old one and asking for new one.
BV> Can you clarify this. I believe you mean if a client sends IA_PD with IAPREFIX with current delegated prefix and another IAPREFIX with just a hint, it is up to the server as how this is handled. I think this should mean that the client is interested in a prefix of the delegated length and is using the prefix provided; the server has the following choices:

a)      Renew the existing prefix. (Ignore prefix hint.)

b)      Assign a new prefix of the requested length (or as close as possible to the request length; though obviously not of the same length as the existing delegated prefix) and either deprecate (0 lifetimes) the existing or provide 0 preferred time with a non-zero (but ‘short’) valid lifetime.

c)       Do both (a) and (b). Though this one is probably less than optimal.

3.       Server should include different combination of prefixes and prefix-lengths in Advertise (multiple choices client can have) and let client choose which matches it’s needs and request only that one. Instead of relying on Advertise from multiple servers, one server can send possible combinations. It saves a lot.
BV> I do not think that is a good idea. What would be the benefit of this?

4.       Section 4.4 – here client should use new IA_ID to indicate that it is looking for new IA_PD with different hint
BV> I think we want to be careful about causing an IAID change. While this seems simple and is indeed a proper way to ‘change’ PDs, it has some issues. In particular:

-          It requires that the client have state to remember that it is now using a different IAID then it started with. For some devices, this may be difficult.

-          In cases where the desired prefix length isn’t available, the client may end up with two delegated prefix with the same prefix length (i.e., the one it got for the first IAID and the one for the 2nd). Likely the client would release one (2nd), but that increases the load on the client and server.
I much prefer a single IAID with two IAPREFIX options – one for the existing prefix and the end for a hint as to what the client wants (see #2 above).

BV> Note also that we really want the hint to be just that – it is not a hard and fast requirement that servers honor the hint. So, you also want to be careful with how we handle this for servers that will ignore this (hence why #4 above is a bit more complex).

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]<mailto:[email-masked]>

To: tianxiang li; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

-          Bernie

---

From: Sunil Gandhewar <[email-masked]>
Date: Sun, 23 Aug 2015 17:15:39 +0000

Please see inline with {SMG]

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Saturday, August 22, 2015 1:30 AM
To: Sunil Gandhewar; [email-masked]
Subject: RE: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Sunil Gandhewar
Sent: Sunday, August 16, 2015 10:01 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Sunil Gandhewar
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

1.       I think it should be clarified that when both the prefix and prefix-length is included in the hint, then server should give priority to what, prefix or the prefix-length. It is possible that server has different address pools and it can allocate different lengths from different address pools. In my opinion it should be prefix and not prefix-length.
BV> A non-zero ipv6-prefix field in the IAPREFIX (with of course a non-zero prefix-length) should be treated as a request for THAT prefix. Nothing else.
[SMG] In the cable scenario, the requestor is expecting us to send prefix with prefix-length, if available. If not then asking me to choose another prefix with the prefix-length from hint. So basically higher priority for prefix-length and prefix. I think it’s incorrect. So it would be great if this draft can clarify these guidelines.

c)       Do both (a) and (b). Though this one is probably less than optimal.
[SMG] I think it should use the IAID in all these combinations to decide. Otherwise what is the use of IAID same or different?

3.       Server should include different combination of prefixes and prefix-lengths in Advertise (multiple choices client can have) and let client choose which matches it’s needs and request only that one. Instead of relying on Advertise from multiple servers, one server can send possible combinations. It saves a lot.
BV> I do not think that is a good idea. What would be the benefit of this?
[SMG] I know it will make it complex but Client can avoid sending SOLICIT multiple times till it satisfies. But I agree, that would make the implementation complex.

-          It requires that the client have state to remember that it is now using a different IAID then it started with. For some devices, this may be difficult.
[SMG] But this is what the draft mentions at other places to use different IAID when a new prefix is requested. Same thing needs to be mentioned in section 4.4

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

-          Bernie