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

[tianxiang li <[e-mail]>]

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 <[e-mail]>:

> On 05/02/16 10:57, Bernie Volz (volz) wrote:
> > 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.
> >
>
> 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.


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

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.


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

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.


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


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


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

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.


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


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


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


>         -hpa
>
>