[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: New Version Notification for draft-farmer-6man-routing-64-02.txt
From: David Farmer <farmer () umn ! edu>
Date: 2019-01-11 22:08:31
Message-ID: CAN-Dau2GhztLbcPak-kD2tctNwphPs5ojWKQGmeUdzGNsx9dcg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jan 11, 2019 at 1:56 PM 神明達哉 <jinmei@wide.ad.jp> wrote:
> At Tue, 8 Jan 2019 03:03:40 -0600,
> David Farmer <farmer@umn.edu> 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:farmer@umn.edu
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
===============================================
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><br></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On \
Fri, Jan 11, 2019 at 1:56 PM 神明達哉 <<a \
href="mailto:jinmei@wide.ad.jp">jinmei@wide.ad.jp</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">At Tue, 8 Jan 2019 \
03:03:40 -0600,<br>David Farmer <<a href="mailto:farmer@umn.edu" \
target="_blank">farmer@umn.edu</a>> wrote:<br><br>> The following are the \
changes in this version;<br>> <br>> *Fixed typos, formatting and other \
editorial changes<br>> *Further refined the argument for standard form of \
interface identifiers.<br>> *Added quote of RFC4291, Section 2.5, paragraph \
1 in Section 2.2, CIDR,<br>> etc...<br>> *Further developed the \
conclusion, providing an argument why<br>> a requirement is the incorrect \
relationship.<br>> <br>> Please take a look and provide any \
comments<br><br>I've read draft-farmer-6man-routing-64-02. My high level \
question is:<br>what's the goal of this draft? Is this an attempt of moving \
the<br>controversial part of rfc4291bis to a separate document so we can<br>promote \
rfc4291bis to IS? Is it just for providing some guidance<br>based on the currently \
available standard (i.e. RFC4291)? Or<br>something else? Depending on its goal my \
subsequent feedback can<br>differ substantially, so basically I'll stop \
here.<br></div></div></blockquote><div><br></div><div><div dir="ltr">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.</div></div><div dir="ltr"><br></div><div dir="ltr"><div \
dir="ltr">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.</div></div><div><div dir="ltr"> <br></div></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">One comment for now: \
I don't think it accurately describes the<br>relationship between SLAAC (RFC4862) \
and the "64-bit boundary". The<br>draft generally reads as if RFC4862 \
assumes 64-bit IIDs. For example,<br>Section 1 states:<br><br> [...] \
Autonomous address-configuration and most other aspects of<br> the IPv6 \
specifications assume or depend on these standard forms.<br><br>On the contrary, \
RFC4862 intentionally avoids assuming a particular<br>length of IIDs. Perhaps you \
(the author) didn't misunderstand this<br>point and tried to convey the point by \
using "or depend on", but I<br>think it's still quite misleading. \
It's true that all currently<br>standardized IIDs used for SLAAC are 64 bits, but \
I don't think it<br>catches the subtlety if we just say "RFC4862 depends on \
64-bit IIDs"<br>and is quite likely to give the reader the false impression that \
SLAAC<br>assumes 64-bit IIDs. There are several other places in the doc \
that<br>have IMO the same kind of confusion. Since it's quite subtle we \
need<br>very careful wording (if we decide to work on this doc as a WG \
I'm<br>willing to suggest text).<br></div></div></blockquote><div><br></div>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.<br \
class="gmail-Apple-interchange-newline"><br></div><div class="gmail_quote">Thanks, \
and I look forward to your additional comments.</div><div \
class="gmail_quote"><br></div>-- <br><div dir="ltr" \
class="gmail_signature">===============================================<br>David \
Farmer <a href="mailto:Email%3Afarmer@umn.edu" \
target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication \
Services<br>Office of Information Technology<br>University of Minnesota <br>2218 \
University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 \
Cell: 612-812-9952<br>===============================================</div></div></div></div></div>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic