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

[Ted Lemon <[e-mail]>]

What is automatic cascaded prefix delegation?

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

> 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 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.
>
> >
> >     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 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.
>
>
> >
> >     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 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.
> >
> >     ... 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 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 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 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.)
> >
>
> 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
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>