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

["Bernie Volz (volz)" <[e-mail]>]

See below (BV2>).

- Bernie

-----Original Message-----
From: H. Peter Anvin [mailto:[e-mail]] 
Sent: Monday, May 23, 2016 2:52 PM
To: Bernie Volz (volz) <[e-mail]>; tianxiang li <[e-mail]>
Cc: 神明達哉 <[e-mail]>; dhcwg <[e-mail]>
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:
> 
>     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.
> 
> TX>Currently in the draft, we recommend the requesting router to use 
> TX>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.
> 

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

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

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?

> 
>     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]".
> 
> TX>I think case b) is a bit more complicated as the client's 
> TX>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.
> 

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.

> 
>     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
> 
> TX>I think the latter is implied by the former.  Currently in the 
> TX>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 
> BV> 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.
> 
>     ... 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
> 
> 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 
> 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.
> 

That definitely seems like the preferred client behavior.

>  
> 
>     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!!!
> 
>  
> 
>     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.]
> 
> 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 
> 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.
> 
> 
>     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).
> 
> 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).
> 
> 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 
> 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).
> 
> 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?

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