Re: New Version Notification for draft-farmer-6man-routing-64-02.txt

[David Farmer <[e-mail]>]

On Fri, Jan 11, 2019 at 1:56 PM 神明達哉 <[e-mail]> wrote:

> At Tue, 8 Jan 2019 03:03:40 -0600,
> David Farmer <[e-mail]> wrote:
>
> > The following are the changes in this version;
> >
> >    *Fixed typos, formatting and other editorial changes
> >    *Further refined the argument for standard form of interface
> identifiers.
> >    *Added quote of RFC4291, Section 2.5, paragraph 1 in Section 2.2,
> CIDR,
> > etc...
> >    *Further developed the conclusion, providing an argument why
> > a requirement is the incorrect relationship.
> >
> > Please take a look and provide any comments
>
> I've read draft-farmer-6man-routing-64-02.  My high level question is:
> what's the goal of this draft?  Is this an attempt of moving the
> controversial part of rfc4291bis to a separate document so we can
> promote rfc4291bis to IS?  Is it just for providing some guidance
> based on the currently available standard (i.e. RFC4291)?  Or
> something else?  Depending on its goal my subsequent feedback can
> differ substantially, so basically I'll stop here.
>

My goal is to clarify that IPv6 routing, and particularly subnet
routing and on-link determination, is independen of the IPv6 Addressing
Architecture's requirement to use 64-bit interface identifires, it
doesn't directly apply to IPv6 routing. Nevertheless, it does
indirectly apply, therefore the 64-bit boundary does imply 64-bit subnet
prefixes are RECOMMENDED, just not required, for subnet routing and on-link
determination.

Further, the lack of definitive operational guidance compounds the
confusion created by the IPv6 Addressing Architecture. Allowing its
emphasis on the length of the subnet prefixes to dilute the importance of
other configuration information needed by hosts in most circumstances.
Mainly the fact that PIOs with the A flag set are required by SLAAC and
hosts that don't support other configuration mechanisms, and further that
several mechanisms important to the security and privacy of users are
dependant on SLAAC and require the same configuration information to be
provided.


> One comment for now: I don't think it accurately describes the
> relationship between SLAAC (RFC4862) and the "64-bit boundary".  The
> draft generally reads as if RFC4862 assumes 64-bit IIDs.  For example,
> Section 1 states:
>
>    [...]  Autonomous address-configuration and most other aspects of
>    the IPv6 specifications assume or depend on these standard forms.
>
> On the contrary, RFC4862 intentionally avoids assuming a particular
> length of IIDs.  Perhaps you (the author) didn't misunderstand this
> point and tried to convey the point by using "or depend on", but I
> think it's still quite misleading.  It's true that all currently
> standardized IIDs used for SLAAC are 64 bits, but I don't think it
> catches the subtlety if we just say "RFC4862 depends on 64-bit IIDs"
> and is quite likely to give the reader the false impression that SLAAC
> assumes 64-bit IIDs.  There are several other places in the doc that
> have IMO the same kind of confusion.  Since it's quite subtle we need
> very careful wording (if we decide to work on this doc as a WG I'm
> willing to suggest text).
>

Later in the document, Section 2.2, 4th paragraph specifically, it says
"SLAAC effectively requires standard form interface identifiers that are 64
bits in length", I should have included that qualifier in the above
sentence as well.  I'll add "effectively" as a qualifier to that sentence
and several other places I can think of, unless you have better language to
suggest.

Thanks, and I look forward to your additional comments.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================