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

[tianxiang li <[e-mail]>]

Hi jinmei，

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.

Best regards,
Tianxiang

2016-04-29 2:22 GMT+08:00 神明達哉 <[e-mail]>:

> At Thu, 21 Apr 2016 16:45:17 +0000,
> "Bernie Volz (volz)" <[e-mail]> wrote:
>
> > One item that was raised at the IETF-95 DHC WG session was the
> > recent change (suggested by me before
> > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02 was published) to
> > switch draft-ietf-dhc-dhcpv6-prefix-length-hint-issue to
> > Informational rather than Standards Track. Marcin Siodelski
> > suggested that the document be Standards Track:
>
> [...]
>
> > Please respond with your comments as to whether this document should
> > be Informational or Standards Track by May 5th, 2016. Of course, any
> > other comments are welcome as well!
>
> On re-reading dhc-dhcpv6-prefix-length-hint-issue-00 to answer the
> call (just noticed 01 was submitted today; haven't read it yet), I
> have even more fundamental question than standards track vs
> informational: what's the problem/is it worth addressing/solving in
> the first place?
>
> In general, I always thought hints from a client is literary a hint,
> and the client can't expect anything specific from the server or rely
> on such an expectation by sending a hint.  In my view, if there's such
> a client implementation, it'd simply be a bug of it and should be
> fixed.
>
> Also, it's not clear to me what's special in the case of prefix length
> hint.  The draft shows an example:
>
>    If the requesting router is asking for a /56 and the delegating
>    router returns a /64, the functionality of the requesting router
>    might be limited because it might not be able to split the prefix for
>    all its interfaces.
>
> It might be a "problem", but it doesn't necessarily seem to me to be a
> protocol level problem.  Realistically, the (minimum) size of the
> delegated prefix would be determined by some operational policy of the
> delegating side (such as an ISP) and included in some kind of contract
> between the delegating side and the requesting side.  If the
> requesting side needs to rely on a wider prefix, it should ensure that
> it can at least get the necessary size of prefix at that level, rather
> than hoping that the requirement is met in the protocol level using
> the hint value.
>
> We could also come up with a "problem" for other kind of hints, for
> example:
>
>    If a DHCPv6 client is asking for a specific IPv6 address as a hint
>    in IA_NA because the client used that particular address before and
>    some long-standing application relies on it, and the DHCPv6 server
>    returns a different address than that, then the functionality of
>    the client is limited because this long-standing application might
>    not be able to work correctly.
>
> Still, we are not trying to introduce a new requirement for the server
> so that "it should honor the hint whenever possible", right?  There
> might be a special reason in the case the prefix length hint, but at
> the moment I don't see it in draft-ietf-dhc-dhcpv6-prefix-length-hint-issue
> beyond some imaginary problem.
>
> So, I'd first like to see what's actually the problem and be convinced
> that's certainly a practical operational problem specific to hints for
> the prefix length (but not for other types of hints) that has to be
> solved at the protocol level.  Otherwise, I'd not even see the need
> for publishing this document in the first place, let alone whether
> it's standards track or informational.
>
> --
> jinmei
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>