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

[神明達哉 <[e-mail]>]

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