Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

From: 神明達哉 <[email-masked]>
Date: Mon, 2 May 2016 10:45:33 -0700

At Sat, 30 Apr 2016 09:51:02 +0800,
tianxiang li <[email-masked]> wrote:

> Thank you reviewing the document and providing your comments. Unlike other
> hints such as T1 T2 lifetimes, which could be easily ignored by the server,
> completely ignoring the prefix-length hint would cause some functional
> issues for the client, how the prefix-length hint should be handled is a
> bit more complicated, and it should be given more considerations. We
> believe there is actual requirement for some ISPs to clarify how it should
> work, and understand the expectations of the client and server. E.g. If a
> server has an existing binding for a prefix length different from what the
> client is currently requesting, what should it do? This is the case when
> the client changed its home router configuration and it needs a shorter
> prefix. Also, if a client didn’t get the prefix it wanted, should it
> continue to ask for the preferred prefix (during Renew/Rebind)? Or should
> the server remember what the client originally requested, and assign it a
> new prefix if it should become available? These are some issues we are
> trying to clarify in the document, so that servers which DO want to
> understand the client’s actual prefix requirement, would know how the
> prefix-length hint should be handled, to make it work well. I'm not sure
> whether there is the same problem for addresses, it might be something
> worth discussing.

The above statement basically seems to be a statement of what's
written in the draft.  So the "problem statement" still seem to be
artificial to me.  Is there actually a service provider that is
willing to behave differently depending on the hint prefix length
specified by the requesting router, for example?  If there's such an
operational case, I see the need for the clarification.  But I've not
heard of such a practical motivation yet (it's quite possible that I
simply don't know it especially most of other wg members don't seem to
have this question.  so I'm happy to be corrected).

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 May 2016 17:57:20 +0000

Jinmei:

Here's I think a simple example ...

Requesting router solicits for a /56.  Delegating router has none to offer (perhaps temporary issue or the configuration doesn't currently allow). So, delegating router returns a /60. The requesting router uses this.

Now, it does periodic renewals. If it just sends the delegated-prefix (/60) in the IA_PD, the server will keep renewing this. Since the delegating router has no other information.

The current RFC3633 never says that the requesting router should continue to include a ::/56 as a hint in the renewal (though it also doesn't prohibit it).

Thus, even if the delegating router is reconfigured (or the temporary issue is resolved), the requesting router would continue to use the /60 (perhaps not being able to operate fully). Yet, if the requesting router included the ::/56 as a hint (in addition to the /60 delegated-prefix), the delegating router COULD assign it a /56 when it was able to.

There's also a separate issue of if the requesting router where to Solicit (and say for the /56 hint), should the server abandon the /60 that it might still have leased or prefer a /56 (or something shorter than a /60 it has)? That might be less of an issue for this case as that would generally just be up to the server's policy (as to how strong the hint it treated).

To handle the case I mentioned above, we did resort in our server to remembering the hint the client provided during the Solicit so that we can re-evaluate as to whether to keep renewing the current delegated prefix or re-evaluate whether we had something "better" to offer the client.

Note that this works both ways - a delegating router might only have had a /56 to delegated when the client requested a /60, but that generally is a less interesting case because the requesting router can just use the longer prefix.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, May 02, 2016 1:46 PM
To: tianxiang li <[email-masked]>
Cc: dhcwg <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

At Sat, 30 Apr 2016 09:51:02 +0800,
tianxiang li <[email-masked]> wrote:

> Thank you reviewing the document and providing your comments. Unlike 
> other hints such as T1 T2 lifetimes, which could be easily ignored by 
> the server, completely ignoring the prefix-length hint would cause 
> some functional issues for the client, how the prefix-length hint 
> should be handled is a bit more complicated, and it should be given 
> more considerations. We believe there is actual requirement for some 
> ISPs to clarify how it should work, and understand the expectations of 
> the client and server. E.g. If a server has an existing binding for a 
> prefix length different from what the client is currently requesting, 
> what should it do? This is the case when the client changed its home 
> router configuration and it needs a shorter prefix. Also, if a client 
> didn’t get the prefix it wanted, should it continue to ask for the 
> preferred prefix (during Renew/Rebind)? Or should the server remember 
> what the client originally requested, and assign it a new prefix if it 
> should become available? These are some issues we are trying to 
> clarify in the document, so that servers which DO want to understand 
> the client’s actual prefix requirement, would know how the 
> prefix-length hint should be handled, to make it work well. I'm not 
> sure whether there is the same problem for addresses, it might be something worth discussing.

The above statement basically seems to be a statement of what's written in the draft.  So the "problem statement" still seem to be artificial to me.  Is there actually a service provider that is willing to behave differently depending on the hint prefix length specified by the requesting router, for example?  If there's such an operational case, I see the need for the clarification.  But I've not heard of such a practical motivation yet (it's quite possible that I simply don't know it especially most of other wg members don't seem to have this question.  so I'm happy to be corrected).

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 3 May 2016 11:39:42 -0700

At Mon, 2 May 2016 17:57:20 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Requesting router solicits for a /56.  Delegating router has none to
> offer (perhaps temporary issue or the configuration doesn't
> currently allow). So, delegating router returns a /60. The
> requesting router uses this.

[...]

We could certainly come up with cases like this, but these generally
seem to me to be artificial, mainly from our imagination.  The
examples I've seen/heard so far also do not illustrate in which point
the hint for the prefix length is so special than the hint for other
parameters.

If, for example, there's actually a real operational need for this
like an ISP that plans to dynamically change assigned prefix lengths
quite often and wants to make sure the (re)negotiation of the prefix
length automatic through the protocol between the requesting and
delegating router, I understand the need for the clarification or even
protocol update.

Or, even if the case for auto-updating the prefix length is just an
imaginary idea, if the general wg consensus is to make it
standardized, then I wouldn't necessarily be opposed to the decision
(while I personally don't like to publish random RFCs that way).

For now, though, I'd like to see a more convincing and practical
reason for why we need to treat the prefix length so specially.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 3 May 2016 20:24:25 +0000

This is a real case, not something I dreamed up.

- Bernie

---

From: 神明達哉 <[email-masked]>
Date: Thu, 5 May 2016 10:52:41 -0700

At Tue, 3 May 2016 20:24:25 +0000,

> This is a real case, not something I dreamed up.

Okay, in that case I'd suggest explaining such a practical motivation
in the draft.  It doesn't have to be a specific existing/planned
service, but would have to be something more specific than what's
currently given in Introduction and "Problem" parts of subsequent
sections.  I'd also expect it will explain why the hint for the prefix
length is so special and requires special handling along with that
motivation.

And, going back to the very original question of this thread with the
above in mind...

>> Please respond with your comments as to whether this document
>> should be Informational or Standards Track by May 5th, 2016.

I think this should be a Standards Track document.  It may still
depend on how common the expected use case is (which I really don't
understand yet), but assuming it's at least moderately common, the
proposed behavior will substantially affect interoperability of the
use case.  For the same reason, IMO key requirements should be clearly
specified with RFC2119 keywords.

--
JINMEI, Tatuya

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 19 May 2016 01:28:56 -0700

On 05/02/16 10:57, Bernie Volz (volz) wrote:
> offer (perhaps temporary issue or the configuration doesn't currently
> allow). So, delegating router returns a /60. The requesting router
> uses this.
> 
> Now, it does periodic renewals. If it just sends the delegated-prefix
> (/60) in the IA_PD, the server will keep renewing this. Since the
> delegating router has no other information.
> 
> The current RFC3633 never says that the requesting router should
> continue to include a ::/56 as a hint in the renewal (though it also
> doesn't prohibit it).
> 
> Thus, even if the delegating router is reconfigured (or the temporary
> issue is resolved), the requesting router would continue to use the
> /60 (perhaps not being able to operate fully). Yet, if the requesting
> router included the ::/56 as a hint (in addition to the /60
> delegated-prefix), the delegating router COULD assign it a /56 when
> it was able to.
> 
> There's also a separate issue of if the requesting router where to
> Solicit (and say for the /56 hint), should the server abandon the /60
> that it might still have leased or prefer a /56 (or something shorter
> than a /60 it has)? That might be less of an issue for this case as
> that would generally just be up to the server's policy (as to how
> strong the hint it treated).
> 
> To handle the case I mentioned above, we did resort in our server to
> remembering the hint the client provided during the Solicit so that
> we can re-evaluate as to whether to keep renewing the current
> delegated prefix or re-evaluate whether we had something "better" to
> offer the client.
> 
> Note that this works both ways - a delegating router might only have
> had a /56 to delegated when the client requested a /60, but that
> generally is a less interesting case because the requesting router
> can just use the longer prefix.
> 

Funny enough, I just went to this list with the explicit intent to ask
some of the questions that I believe this document ought to answer, but
quite frankly it doesn't look from my reading that it does.

I am concerned about client behavior personally, so this is from this
perspective.  This comes from my having written a patchset (which I need
to update) for ISC dhclient to do prefix requests.

My concern is when the ::/n prefix hint should be included.  My
assumption has always been that a single IA_PD always correspond to
prefixes that are to be configured together, whereas multiple IA_PD
delegations would mean prefixes for separate entities.  If this is NOT
the intent it probably needs to be clarified.

It is also worth noting that a server which receives requests for
multiple IA_PD delegations is free to aggregate those if appropriate,
although I have no idea if actual servers in the field do.  It is still
unclear to me if it would be better for the client to push multiple
IA_PD options upstream -- giving the server the option to delegate or
not delegate -- or if it should forcibly aggregate at the client level.

Bernie raises several of the same issues that I tripped over, not
surprising.

Now, what I think IS clear from the client point of view:

a) When creating a SOLICIT message, and there currently is no lease for
an existing prefix of the required length, the SOLICIT message SHOULD
include the ::/n hint for the desired prefix length.

b) When creating a SOLICIT message and there are prefixes which have
been used in the past, they SHOULD be included even if they are too narrow.

Thus, an IA_PD request might look like:

	2001:db8:85a3:2345::/64
	::/60

meaning "please give me a /60 if you can, otherwise please give me
2001:db8:85a3:2345::/64 [again]".

What I think is NOT clear from the client point of view:

a) When creating a SOLICIT message, and we have had at least one prefix
of sufficient length, SHOULD ::/n be included?  That is, should an IA_PD
request look like:

	2001:db8:85a3:7890::/60
	::/60

... or is the latter implied by the former, even if that specific prefix
is unavailable?  What is the request looks like:

	2001:db8:85a3:7890::/60
	2001:db8:85a3:2345::/64

b) Are there messages *other* than SOLICIT where the hint SHOULD get
included?

c) Whether or not the client SHOULD be encouraged to transmit a hint if
it has a *wider* prefix assigned than it needs?

[My feeling is that we want to encourage the client to send the hint for
the preferred prefix length, longer or shorer, in SOLICIT, RENEW and
REBIND messages unless servers in the field are known to malfuction that
way.]

d) If the client MUST/SHOULD to forcibly do aggregation or not, in the
case that it is OK for the client side to deal with multiple disjoint
prefixes.

[I suspect that current servers will not deal well with client
nonaggregation.]

e) If the client SHOULD or SHOULD NOT to respond to a narrower prefix
than requested by issuing a new request for multiple prefixes (via
multiple IA_PD options).

f) If there is ever a reason to NOT send a prefix hint?  Would that
implicitly mean ::/64, and if so, should that be documented?

	-hpa

---

From: tianxiang li <[email-masked]>
Date: Thu, 19 May 2016 22:42:41 +0800

Hi,

Thank you for providing your valuable comments regarding the prefix-length
hint issues draft. Please see my response inline below(TX>).  Please
correct me where I'm wrong, and whether I left out anything.

Best regards,
Tianxiang

2016-05-19 16:28 GMT+08:00 H. Peter Anvin <[email-masked]>:

> TX>The draft mainly covers issues discussed in the previous IETF meetings
and the mailing list, it might not be complete, so we appreciate any
suggestions on what problems or solutions we haven't covered regarding the
prefix-length hint.

> TX>Currently in the draft, we recommend the requesting router to use one
IA_PD option, to contain two IA_PREFIX options. One IA_PREFIX option
containing the current delegated prefix, the other containing the
prefix-length hint. So even if the delegating router is able to assign a
new prefix to the client, it would be in the same IA_PD option with the
same IAID.

> TX>Aggregation is indeed a problem regarding multiple IA_PDs, although the
draft right now does not cover the that scenario. This is one of the
complexities we tried to avoid.

> include the ::/n hint for the desired prefix length.

TX>This is one of the intended uses for the prefix-length hint in the
Solicit message, we will add some text to explain it clearer in the draft.

> TX>I think case b) is a bit more complicated as the client's preference
for the prefix-length could have changed since its last prefix delegation,
so the previous prefix might not be suitable anymore. We could add a
sentence saying "If the requesting router's configuration did not change
during this period..."

> TX>I think the latter is implied by the former.  Currently in the draft,
if the client requests for a specific prefix (e.g.
2001:db8:85a3:7890::/60), the server will first try to return the requested
prefix, if it is not available,  the server will try to assign a prefix
with the same length (/60). So I don't think the ::/n prefix-length hint
still needs to be included in this case.

> TX>We don't yet cover the use case of the client requesting more than one
specific prefix, does there exist such a use case?

> included?
>
> TX>The client could also include the prefix-length hint in the
Renew/Rebind message. For example, if the client's hint was not honored
during Solicit, the client could include the prefix-length hint in the
Renew/Rebind message, to see if the server has the prefix available at that
time. This is covered in section 3.4 and 3.5 of the draft.

> REBIND messages unless servers in the field are known to malfuction that
TX>The ideal case would be that the client gets exactly what it needs.
Thus, saving the wider prefix for clients that could not function without
it. However, this would cause a lot of complexities in the protocol, as
both clients with a "wider" and "shorter" prefix would continue to request
for the preferred prefix-length, which would also cause a lot of burden on
the server. I don't know whether it is worth the cost. Especially, if this
is going to be a Standards Track document, then it has to be the desired
behavior for all clients.

> TX>Right now in the draft, if the client received a narrower prefix than
it requested, it is encouraged to include the prefix-length hint in the
Renew/Rebind messages(in one IA_PD option, using two IA_PREFIX options),
and do a graceful switch over if the server is able to grant the desired
prefix (section 3.4 and 3.5 of the draft).

> TX>If the client does not send a prefix-length hint, then how the server
act would depend on the server default policy. The servers might return
what the client got the last time, or it could return a prefix of default
length (Which could be a /64).

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 May 2016 18:28:55 +0000

Some additional comments below (BV>).

-          Bernie

From: tianxiang li [mailto:[email-masked]]
Sent: Thursday, May 19, 2016 10:43 AM
To: H. Peter Anvin <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; 神明達哉 <[email-masked]>; dhcwg <[email-masked]>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

Hi,

Thank you for providing your valuable comments regarding the prefix-length hint issues draft. Please see my response inline below(TX>).  Please correct me where I'm wrong, and whether I left out anything.

Best regards,
Tianxiang

2016-05-19 16:28 GMT+08:00 H. Peter Anvin <[email-masked]<mailto:[email-masked]>>:
Funny enough, I just went to this list with the explicit intent to ask
some of the questions that I believe this document ought to answer, but
quite frankly it doesn't look from my reading that it does.
TX>The draft mainly covers issues discussed in the previous IETF meetings and the mailing list, it might not be complete, so we appreciate any suggestions on what problems or solutions we haven't covered regarding the prefix-length hint.

TX>Currently in the draft, we recommend the requesting router to use one IA_PD option, to contain two IA_PREFIX options. One IA_PREFIX option containing the current delegated prefix, the other containing the prefix-length hint. So even if the delegating router is able to assign a new prefix to the client, it would be in the same IA_PD option with the same IAID.

TX>Aggregation is indeed a problem regarding multiple IA_PDs, although the draft right now does not cover the that scenario. This is one of the complexities we tried to avoid.

TX>This is one of the intended uses for the prefix-length hint in the Solicit message, we will add some text to explain it clearer in the draft.

        2001:db8:85a3:2345::/64
        ::/60

meaning "please give me a /60 if you can, otherwise please give me
2001:db8:85a3:2345::/64 [again]".
TX>I think case b) is a bit more complicated as the client's preference for the prefix-length could have changed since its last prefix delegation, so the previous prefix might not be suitable anymore. We could add a sentence saying "If the requesting router's configuration did not change during this period..."

BV> My personal opinion is what value is there here in the client including the /64. Sure, it could, but why should it if it really isn’t what it wants? Again, if the client does want to include /64, it should send both. But in this case, I see little reason for it to send the /64.

BV> I also think not including the /64 is better because it is more clear that client wants a /60.

        2001:db8:85a3:7890::/60
        ::/60
TX>I think the latter is implied by the former.  Currently in the draft, if the client requests for a specific prefix (e.g. 2001:db8:85a3:7890::/60), the server will first try to return the requested prefix, if it is not available,  the server will try to assign a prefix with the same length (/60). So I don't think the ::/n prefix-length hint still needs to be included in this case.

BV> That is a very good question. It really depends on what each type of hint means. I think we’re all clear that ::/60 means “Client wants a /60”. But does “2001::/60” means “give client that prefix or, if server can’t, /60 is the hint” (assuming no other explicit hint is included). I think we could definitely decide that if a client sends <prefix>/<length> and not ::/<length>, then length should be treated as the hint if the explicitly requested prefix isn’t available. But I don’t think the current 3633 (or the bis document) reads like that.

        2001:db8:85a3:7890::/60
        2001:db8:85a3:2345::/64
TX>We don't yet cover the use case of the client requesting more than one specific prefix, does there exist such a use case?

BV> This one does make the previous issue more complex as is the /60 or /64 the hint if the server can’t grant the requested value. That is why the ::/<length> might be best to be explicit always as to the hint.

b) Are there messages *other* than SOLICIT where the hint SHOULD get
included?
TX>The client could also include the prefix-length hint in the Renew/Rebind message. For example, if the client's hint was not honored during Solicit, the client could include the prefix-length hint in the Renew/Rebind message, to see if the server has the prefix available at that time. This is covered in section 3.4 and 3.5 of the draft.

BV> Correct, This all applies to Renew and Rebind!!!

[My feeling is that we want to encourage the client to send the hint for
the preferred prefix length, longer or shorer, in SOLICIT, RENEW and
REBIND messages unless servers in the field are known to malfuction that
way.]
TX>The ideal case would be that the client gets exactly what it needs. Thus, saving the wider prefix for clients that could not function without it. However, this would cause a lot of complexities in the protocol, as both clients with a "wider" and "shorter" prefix would continue to request for the preferred prefix-length, which would also cause a lot of burden on the server. I don't know whether it is worth the cost. Especially, if this is going to be a Standards Track document, then it has to be the desired behavior for all clients.

BV> I don’t think there is any harm. It may cost the server some processing to ‘see’ if there is a better prefix available.

BV> One issue here that is important to consider is that a wider prefix (shorter prefix length) might be best to retain as it avoids renumbering (either if server was able to grant less wide (longer length) or if something changes on the requesting router – more interfaces added). I could see a client doing this on a Solicit but less likely to do it on a Renew/Rebind to avoid renumbering.

e) If the client SHOULD or SHOULD NOT to respond to a narrower prefix
than requested by issuing a new request for multiple prefixes (via
multiple IA_PD options).
TX>Right now in the draft, if the client received a narrower prefix than it requested, it is encouraged to include the prefix-length hint in the Renew/Rebind messages(in one IA_PD option, using two IA_PREFIX options), and do a graceful switch over if the server is able to grant the desired prefix (section 3.4 and 3.5 of the draft).

BV> This is what we want.

f) If there is ever a reason to NOT send a prefix hint?  Would that
implicitly mean ::/64, and if so, should that be documented?
TX>If the client does not send a prefix-length hint, then how the server act would depend on the server default policy. The servers might return what the client got the last time, or it could return a prefix of default length (Which could be a /64).

BV> That is why I think sending the hint is good – if the server must grant a new prefix (old cannot be extended for whatever reason), it knows what prefix length to use in providing a new one. (Note: Of course, if we make it clear that a 2001::/<length> IAPREFIX means the hint is <length> unless another explicit hint (::/<length>) is provided, then we can relax the need to send an explicit hint when the lengths are equal.)

        -hpa

---

From: "H. Peter Anvin" <[email-masked]>
Date: Mon, 23 May 2016 11:52:20 -0700

> new prefix to the client, it would be in the same IA_PD option with the

Yes, this is consistent with the idea that one IA_PD corresponds to one
set of overlapping identifiers.

> TX>Aggregation is indeed a problem regarding multiple IA_PDs, although
> the draft right now does not cover the that scenario. This is one of the

Avoid, how?  By ignoring the problem?  If this is out of scope it would
probably be wise to consider it in a future document before everything
gets set in stone by de facto implementation quirks, if that hasn't
happened already.

This is actually a major deal, as it is the natural consequence of
automatic cascaded prefix delegation, and in many ways aggregation is
more for upstream convenience, which means it would be better
implemented as a matter of server policy.  It is also more efficient in
terms of address space assignment, since the client would be more likely
to ask for specific number of prefixes.

That being said, there is clearly a point where the packet size becomes
ridiculous, and aggregation *really* needs to be performed in the client.

> for the prefix-length could have changed since its last prefix
> delegation, so the previous prefix might not be suitable anymore. We
> could add a sentence saying "If the requesting router's configuration
> did not change during this period..." 
> 
> BV> My personal opinion is what value is there here in the client
> including the /64. Sure, it could, but why should it if it really isn’t
> what it wants? Again, if the client does want to include /64, it should
> send both. But in this case, I see little reason for it to send the /64.
> 

Why include the existing /64 here?  Because the worst-case situation for
the client is getting *another* /64, which means prefix fandango for no
benefit.  This is actually a highly likely scenario if the upstream
routers only provides /64s, and doesn't *itself* manage the current set
of allocations (in which case why would we bother sending it back to
them under any circumstances.)  If nothing else, the client cannot trust
the latter.

> 2001:db8:85a3:7890::/60), the server will first try to return the
> requested prefix, if it is not available,  the server will try to assign
> a prefix with the same length (/60). So I don't think the ::/n
> prefix-length hint still needs to be included in this case.
> 
> BV> That is a very good question. It really depends on what each type of
> hint means. I think we’re all clear that ::/60 means “Client wants a
> /60”. But does “2001::/60” means “give client that prefix or, if server
> can’t, /60 is the hint” (assuming no other explicit hint is included). I
> think we could definitely decide that if a client sends
> <prefix>/<length> and not ::/<length>, then length should be treated as
> the hint if the explicitly requested prefix isn’t available. But I don’t
> think the current 3633 (or the bis document) reads like that.
> 
> TX>We don't yet cover the use case of the client requesting more than
> one specific prefix, does there exist such a use case?
> 
> BV> This one does make the previous issue more complex as is the /60 or
> /64 the hint if the server can’t grant the requested value. That is why
> the ::/<length> might be best to be explicit always as to the hint.
> 

That definitely seems like the preferred client behavior.

> Renew/Rebind message, to see if the server has the prefix available at
> that time. This is covered in section 3.4 and 3.5 of the draft.
> 
>  
> 
> Thus, saving the wider prefix for clients that could not function
> without it. However, this would cause a lot of complexities in the
> protocol, as both clients with a "wider" and "shorter" prefix would
> continue to request for the preferred prefix-length, which would also
> cause a lot of burden on the server. I don't know whether it is worth
> the cost. Especially, if this is going to be a Standards Track document,
> then it has to be the desired behavior for all clients.
> 
> BV> I don’t think there is any harm. It may cost the server some
> processing to ‘see’ if there is a better prefix available.
> 
> BV> One issue here that is important to consider is that a wider prefix
> (shorter prefix length) might be best to retain as it avoids renumbering
> (either if server was able to grant less wide (longer length) or if
> something changes on the requesting router – more interfaces added). I
> could see a client doing this on a Solicit but less likely to do it on a
> Renew/Rebind to avoid renumbering.
> 
> 
> what the client got the last time, or it could return a prefix of
> default length (Which could be a /64).
> 
> BV> That is why I think sending the hint is good – if the server must
> grant a new prefix (old cannot be extended for whatever reason), it
> knows what prefix length to use in providing a new one. (Note: Of
> course, if we make it clear that a 2001::/<length> IAPREFIX means the
> hint is <length> unless another explicit hint (::/<length>) is provided,
> then we can relax the need to send an explicit hint when the lengths are
> equal.)
> 

I think the only possible answer here has to do with the effect on the
client on renumbering.  If the client has gotten 2001:db8:85a3:1200::/56
assigned and it only needs /60, sending the ::/60 hint could encourage
the server to renumber.  On the other hand, including the ::/60 hint
count prevent reassignment to a /64 if the existing prefix is unavailable.

My gut feel at this point is that if the client wants to prevent being
renumbered, but still wants to really assure it doesn't get an
inadequate prefix, it SHOULD NOT include the hint in a RENEW message,
but probably SHOULD include the hint in a SOLICIT or REBIND message.
What do think?

	-hpa

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2016 15:13:06 -0400

What is automatic cascaded prefix delegation?

On Mon, May 23, 2016 at 2:52 PM, H. Peter Anvin <[email-masked]> wrote:

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 May 2016 19:19:03 +0000

See below (BV2>).

- Bernie

-----Original Message-----
From: H. Peter Anvin [mailto:[email-masked]] 
Sent: Monday, May 23, 2016 2:52 PM
To: Bernie Volz (volz) <[email-masked]>; tianxiang li <[email-masked]>
Cc: 神明達哉 <[email-masked]>; dhcwg <[email-masked]>
Subject: Re: [dhcwg] Follow up from IETF-95 - draft-ietf-dhc-dhcpv6-prefix-length-hint-issue

On 05/23/16 11:28, Bernie Volz (volz) wrote:
> TX>Currently in the draft, we recommend the requesting router to use 
> TX>one
> prefix-length hint. So even if the delegating router is able to assign 
> a new prefix to the client, it would be in the same IA_PD option with 
> the same IAID.
> 

Yes, this is consistent with the idea that one IA_PD corresponds to one set of overlapping identifiers.

> the draft right now does not cover the that scenario. This is one of 
> the complexities we tried to avoid.
> 

Avoid, how?  By ignoring the problem?  If this is out of scope it would probably be wise to consider it in a future document before everything gets set in stone by de facto implementation quirks, if that hasn't happened already.

This is actually a major deal, as it is the natural consequence of automatic cascaded prefix delegation, and in many ways aggregation is more for upstream convenience, which means it would be better implemented as a matter of server policy.  It is also more efficient in terms of address space assignment, since the client would be more likely to ask for specific number of prefixes.

That being said, there is clearly a point where the packet size becomes ridiculous, and aggregation *really* needs to be performed in the client.

BV2> I'm not exactly sure what the issue here is, but I think the way to assure aggregation is for the request router to ask for a short prefix?

> TX>I think case b) is a bit more complicated as the client's 
> TX>preference
> including the /64. Sure, it could, but why should it if it really 
> isn’t what it wants? Again, if the client does want to include /64, it 
> should send both. But in this case, I see little reason for it to send the /64.
> 

Why include the existing /64 here?  Because the worst-case situation for the client is getting *another* /64, which means prefix fandango for no benefit.  This is actually a highly likely scenario if the upstream routers only provides /64s, and doesn't *itself* manage the current set of allocations (in which case why would we bother sending it back to them under any circumstances.)  If nothing else, the client cannot trust the latter.

BV> For a Solicit, If the "lease" hasn't expired on the server, why would the server provide a different /64? If it has expired, it is hit or miss anyway since it may easily have been allocated to another client? Again, I don't see that it is a big deal but on a Solicit I think deferring to the "initial" state is best. Also, providing the /64 may go against the Anonymity Profile -- but in some networks that is probably meaningless. 

BV> There's work in progress in 6man to move to PD for many more clients (instead of assigning just addresses even on Wifi and similar networks), so privacy may become more important.

> TX>I think the latter is implied by the former.  Currently in the 
> TX>draft,
> requested prefix, if it is not available,  the server will try to 
> assign a prefix with the same length (/60). So I don't think the ::/n 
> BV> That is a very good question. It really depends on what each type 
> BV> of
> /60”. But does “2001::/60” means “give client that prefix or, if 
> server can’t, /60 is the hint” (assuming no other explicit hint is 
> included). I think we could definitely decide that if a client sends 
> <prefix>/<length> and not ::/<length>, then length should be treated 
> as the hint if the explicitly requested prefix isn’t available. But I 
> don’t think the current 3633 (or the bis document) reads like that.
> 
> BV> This one does make the previous issue more complex as is the /60 
> BV> or
> /64 the hint if the server can’t grant the requested value. That is 
> why the ::/<length> might be best to be explicit always as to the hint.
> 

> Renew/Rebind message. For example, if the client's hint was not 
> honored during Solicit, the client could include the prefix-length 
> hint in the Renew/Rebind message, to see if the server has the prefix 
> available at that time. This is covered in section 3.4 and 3.5 of the draft.
> 
>  
> 
> the cost. Especially, if this is going to be a Standards Track 
> document, then it has to be the desired behavior for all clients.
> 
> BV> One issue here that is important to consider is that a wider 
> BV> prefix
> (shorter prefix length) might be best to retain as it avoids 
> renumbering (either if server was able to grant less wide (longer 
> length) or if something changes on the requesting router – more 
> interfaces added). I could see a client doing this on a Solicit but 
> less likely to do it on a Renew/Rebind to avoid renumbering.
> 
> 
> TX>Right now in the draft, if the client received a narrower prefix 
> TX>than
> it requested, it is encouraged to include the prefix-length hint in 
> the Renew/Rebind messages(in one IA_PD option, using two IA_PREFIX 
> options), and do a graceful switch over if the server is able to grant 
> the desired prefix (section 3.4 and 3.5 of the draft).
> 
> TX>If the client does not send a prefix-length hint, then how the 
> TX>server
> act would depend on the server default policy. The servers might 
> return what the client got the last time, or it could return a prefix 
> of default length (Which could be a /64).
> 
> hint is <length> unless another explicit hint (::/<length>) is 
> provided, then we can relax the need to send an explicit hint when the 
> lengths are
> equal.)
> 

I think the only possible answer here has to do with the effect on the client on renumbering.  If the client has gotten 2001:db8:85a3:1200::/56 assigned and it only needs /60, sending the ::/60 hint could encourage the server to renumber.  On the other hand, including the ::/60 hint count prevent reassignment to a /64 if the existing prefix is unavailable.

My gut feel at this point is that if the client wants to prevent being renumbered, but still wants to really assure it doesn't get an inadequate prefix, it SHOULD NOT include the hint in a RENEW message, but probably SHOULD include the hint in a SOLICIT or REBIND message.
What do think?

BV> This is a more difficult situation. Perhaps if the hint length is longer than the delegated prefix, the server should avoid trying for the longer prefix unless it has no choice (i.e., original prefix can't be renewed/granted)? Or leave it as a matter of server policy (when it has a choice)?

I would think that a server should avoid renumbering except when necessary - which means simply that "a shorter prefix than the current is available and has been hinted for by the client". Otherwise, the client should keep what it got? Servers might use other policies - such as preferring to renumber if the client got something "more" than it requested because PD space is tight (in which case renumbering the client to the longer length might be preferred).

- Bernie

	-hpa