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

From: David Farmer <[email-masked]>
Date: Tue, 8 Jan 2019 03:03:40 -0600

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

Thanks

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Jan 6, 2019 at 3:37 PM
Subject: New Version Notification for draft-farmer-6man-routing-64-02.txt
To: David Farmer <[email-masked]>

A new version of I-D, draft-farmer-6man-routing-64-02.txt
has been successfully submitted by David Farmer and posted to the
IETF repository.

Name:           draft-farmer-6man-routing-64
Revision:       02
Title:          IPv6 Routing and its Relationship to the 64-bit Boundary in
the IPv6 Addressing Architecture
Document date:  2019-01-06
Group:          Individual Submission
Pages:          16
URL:
https://www.ietf.org/internet-drafts/draft-farmer-6man-routing-64-02.txt
Status:
https://datatracker.ietf.org/doc/draft-farmer-6man-routing-64/
Htmlized:       https://tools.ietf.org/html/draft-farmer-6man-routing-64-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-farmer-6man-routing-64
Diff:
https://www.ietf.org/rfcdiff?url2=draft-farmer-6man-routing-64-02

Abstract:
   There is a common misconception that the IPv6 Addressing Architecture
   requires the use of only /64 subnet prefixes for subnet routing.
   This document clarifies the characterization of the relationship
   between IPv6 routing and the 64 bit boundary, which is that of a
   recommendation for the use of /64 subnet prefixes for subnet routing
   in most circumstances, not a requirement for such.  To further
   clarify this relationship, the document also provides operational
   guidance for the configuration of subnet prefixes and updates
   RFC 4291 accordingly.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Jan 2019 11:56:32 -0800

At Tue, 8 Jan 2019 03:03:40 -0600,

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

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

--
JINMEI, Tatuya

---

From: David Farmer <[email-masked]>
Date: Fri, 11 Jan 2019 16:08:31 -0600

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

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