Re: draft-bourbaki-6man-classless-ipv6-00

[Brian E Carpenter <[e-mail]>]

Jinmei-san,

Thanks for those careful comments. Can I just ask one question to be
sure I understand:

> The draft (perhaps unintentionally) conflates
>   "on-link prefixes" and "(SLAAC) subnet prefixes".

Am I correct in thinking that this distinction *only*
applies when SLAAC is in use? If the nodes on a link
(including a point-to-point) are configured without use
of SLAAC, surely there is only a "prefix", without
distinction.

Regards
   Brian Carpenter



On 07/06/2017 07:06, 神明達哉 wrote:
> At Fri, 2 Jun 2017 16:11:12 +0200,
> Job Snijders <[e-mail]> wrote:
> 
>> Please review the below.
> 
> I've read draft-bourbaki-6man-classless-ipv6-00.
> 
> First, I have some high level comments:
> 
> - it's not clear to me exactly what this draft tries to propose.
>   Brian (a coauthor) seems to indicate it just makes the length of
>   interface identifiers dependent only on IPv6-over-foo specifications
>   (and not on the addressing architecture spec).  But, as I commented
>   earlier the draft text reads to me as if it proposes more: the
>   length of IID is now completely variable and subject to operator's
>   choice (whether we have a "default length" or whether such a default
>   is 64 is a different topic).  When the intent of the draft is so
>   unclear, and perhaps the intent even among coauthors is not
>   consistent, it's nearly impossible to even understand the draft
>   accurately, let alone say support or non-support.
> 
> - somewhat related to the first bullet, this draft seems to be
>   confused about the point I tried to clarify in my own individual
>   draft, draft-jinmei-6man-prefix-clarify-00, even if it's referenced
>   from this draft: The draft (perhaps unintentionally) conflates
>   "on-link prefixes" and "(SLAAC) subnet prefixes".  Depending on
>   which kind of prefix it talks about, the draft could actually update
>   an existing standard or be a mere clarification.  For example, in
>   Section 1 it states:
> 
>    [...]  While link prefixes
>    of varied lengths, e.g.  /127, /126, /124, /120, ...  /64 have been
>    successfully deployed for many years, glaring mismatches between a
>    formal specification and long-standing field deployment practices are
>    never wise, [...]
> 
>   This "link prefixes" is more likely to refer to on-link prefixes.
>   But in that sense there's no "mismatch" between the specification
>   and the deployment: on-link prefix length has already, and always
>   been variable (but I know it's confusing, and that's one main reason
>   why I wrote my own draft).  (As a minor note, I realize the concept
>   of on-link prefixes used in my draft exclusively focuses on prefixes
>   in RA PIOs.  But it's straightforward to extend the concept to
>   manual configuration, and I believe even those who prefer keeping
>   the /64 magic number for certain SLAAC subnet prefixes agree that
>   on-link prefix length is already variable and it also applies to
>   manual configuration).
> 
>   On the other hand, the 2nd and 3rd paragraphs of Section 4 clearly
>   mean SLAAC subnet prefixes (by talking about interface identifiers).
>   As I tried to explain in my draft, these two are independent.  It's
>   very confusing to see an introduction to topics about on-link
>   prefixes and then recommendations about SLAAC subnet prefixes.
> 
> So, I'd first like to request this draft be much more clearer on what
> it proposes.  And, if it helps in doing so, be clearer on the
> difference between on-link and SLAAC subnet prefixes.  If the proposal
> is only about one of them, just don't talk about the other, since
> discussing both would just increase confusion and introduce
> unnecessary controversy; if the proposal covers both types of
> prefixes, make sure which type of prefixes is intended in each
> specific context.
> 
> And so it may be premature to talk about specific content of the
> draft, but I'll provide some comments on the current version of text
> anyway.
> 
> - Section 1: the discussion in this section is confusing, misleading,
>   and/or irrelevant.  See the high-level comment above.
> 
> - Section 2
> 
>    [...]  Therefore their length, previously fixed
>    at 64 bits [RFC7136], [...]
> 
>   I don't think RFC7136 fixes "their (= interface IDs') length".  At
>   the very least fixing it doesn't seem to be the main goal of the
>   RFC.  If it intends to refer to a particular part of the RFC that
>   I'm missing, it's better to include a specific section number.
> 
> - Section 2
> 
>    [...]  Therefore their length, [...],
>    is in fact a variably-sized parameter as
>    explicitly acknowledged in Section 5.5.3(d) of [RFC4862]
> 
>   This sentence itself is true, but I suspect it's misleading in the
>   context (i.e., stating this after referring to RFC7217/8064).  What
>   RFC4862 acknowledges is that the length of IID is a parameter of the
>   link, but RFC7217 is actually a technique quite independent from
>   specific link type.  If this paragraph tries to say that now that we
>   have the technique of RFC7217 and recommendation of RFC8064, IID
>   length won't have to be a parameter of link type (and therefore not
>   necessarily be 64 for Ethernet, for example), then I see it's worth
>   discussing.  But that's a new update to existing standards, not what
>   RFC4862 is currently acknowledging.
> 
> - Section 3
> 
>    IPv6 unicast interfaces may use any subnet length up to 128 except
>    for situations where an Internet Standard document may impose a
>    particular length, for example Stateless Address Autoconfiguration
>    (SLAAC) [RFC4862], [...].
> 
>   RFC4862 does not (directly) impose a particular IID length.  It just
>   says the length is a parameter of the link type.  If anything, what
>   imposes a particular length is specific IPv6-over-foo specs, such as
>   RFC2464.
> 
> - Section 4
> 
>    For historical reasons, when a prefix is needed on a link, barring
>    other considerations, a /64 is recommended [RFC7136].
> 
>   This "prefix" is ambiguous.  Please clarify whether it's an on-link
>   prefix or SLAAC subnet prefix.
> 
>   Also, I don't think RFC7136 makes such a recommendation.  At least
>   such a recommendation is not the main topic of the RFC (see another
>   bullet on Section 2 above).
> 
>   And, perhaps related to the second point, it's not clear to me
>   whether this sentence tries to introduce a new recommendation or
>   just intends to refer to an existing recommendation in other RFC(s).
> 
> - Section 4
> 
>    Nonetheless, there is no reason in theory why an IPv6 node should not
>    operate with different interface identfier lengths on different
>    physical interfaces.  Thus, a correct implementation of SLAAC must in
>    fact allow for any prefix length, with the value being a parameter
>    per interface.
> 
>   This reads to me like an update to RFC4862.  In RFC4862, the length
>   of IID (which derives SLAAC subnet prefix length) is a parameter of
>   link type, not of an individual interface.  If this text intends to
>   make an update to RFC4862, that's find as a proposal, but it should
>   more explicitly say so.  Also it should add RFC4862 to the "Update:"
>   field of the draft header.
> 
> - Section 5
> 
>   This section is another place where this draft conflates on-link and
>   SLAAC subnet prefixes: The first paragraph is mainly related to SLAAC
>   subnet prefixes, while the second paragraph is about on-link
>   prefixes.  It's misleading to discuss these this way using the same
>   "subnet" term, or one of them can be totally irrelevant depending on
>   the actual intent of this draft's proposal (see the high level
>   comment above).  I actually see there's a subtle relationship
>   between these two topics, however, since both prefixes are often the
>   same in practice.  But, if the draft really needs to talk about the
>   subtlety it should do so more carefully (if one of the issues is
>   irrelevant it's much simpler and less confusing to just omit it).
> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>