[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Moving RFC4291-bis forward
From: DaeYoung KIM <dykim6 () gmail ! com>
Date: 2018-06-25 5:37:58
Message-ID: F0E1C9AD-5ACA-4AC3-BA20-2AE45EE86ADF () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
+1
Sent from my iPhone
> On 25 Jun 2018, at 04:10, C. M. Heard <heard@pobox.com> wrote:
>
> David,
>
> If you pursue this -- and I hope that you do -- I see at least one other thing \
> (besides the two mentioned by DY Kim) to move from 4291bis to your proposed BCP. \
> Specifically, the length of the prefix for link-local addresses is not constrained \
> by RFC 4862 to be 64 bits; rather, "[t]he length of the interface identifier is \
> defined in a separate link-type-specific document, which should also be consistent \
> with the address architecture." So 4291bis Section 2.4.6 should be changed as \
> follows:
> OLD:
> Link-Local addresses are for use on a single link. Link-Local
> addresses have the following format:
>
> > 10 |
> > bits | 54 bits | 64 bits |
> +----------+-------------------------+----------------------------+
> > 1111111010| 0 | interface ID |
> +----------+-------------------------+----------------------------+
>
> NEW:
> Link-Local addresses are for use on a single link. Link-Local
> addresses have the following format:
>
> > 10 |
> > bits | 118-N bits | N bits |
> +----------+-------------------------+----------------------------+
> > 1111111010| 0 | interface ID |
> +----------+-------------------------+----------------------------+
>
> where N is the length of the interface ID defined in the approppriate
> "IPv6 over <link>" specification.
>
> Your BCP-to-be could then state that N=64 is REQUIRED by current "IPv6 over <link>" \
> specifications and RECOMMENDED is in general.
> Second, note that there is an effort underway to update RFC 6177 (see \
> https://www.ietf.org/mail-archive/web/v6ops/current/msg29485.html); the update to \
> that BCP and your BCP-to-be should, I think, be carefully coordinated.
> Mike Heard
>
> > On Thu, 21 Jun 2018 20:45:13 -0500, David Farmer wrote:
> > > On Thu, Jun 21, 2018 at 8:21 PM, Brian E Carpenter <brian.e.carpenter at \
> > > gmail.com> wrote: On 22/06/2018 11:59, DY Kim wrote:
> > > > I'd also support the idea, but would like further to suggest that the whole \
> > > > 4th para (copied below) of Sec. 2.4.1 be removed and placed in separate ISs:
> > >
> > > Try a BCP instead. Firstly, that is a fine normative reference for
> > > an Internet Standard. Secondly, it (IMHO correctly) fixes the choice
> > > as the Best Current Practice, which nobody has so far disputed.
> > >
> > > Brian
> >
> > I like the idea of at lest part of whole thing as a BCP, because one of the \
> > things I think should done is to RECOMMED the use of 64-bit on-link prefixes and \
> > that fits well as a BCP. Hoever, I'm not sure some of the other stuff fits in a \
> > BCP but we will see.
> > > >
> > > > "Interface Identifiers are 64 bit long except if the first three bits
> > > > of the address are 000, or when the addresses are manually
> > > > configured, or by exceptions defined in standards track documents.
> > > > The rationale for using 64 bit Interface Identifiers can be found in [
> > > > RFC7421]. An example of a standards track exception is [RFC6164
> > > > ] that standardises 127 bit prefixes on inter-router point-to-point
> > > > links."
> > > >
> > > > And also remove the following parenthesis in the last para of Sec. 2.4..4:
> > > >
> > > > "(and therefore having a 64-bit interface ID field)"
> > > >
> > > > ---
> > > > DY
> > > >
> > > > > On 22 Jun 2018, at 02:48, 神明達哉 <jinmei at wide.ad.jp> wrote:
> > > > >
> > > > > At Wed, 20 Jun 2018 12:29:48 -0500,
> > > > > David Farmer <farmer at umn.edu> wrote:
> > > > >
> > > > > > I propose the following text for the critical paragraph of contention in
> > > > > > section 2.4.1 from draft-ietf-6man-rfc4291bis-09;
> > > > > >
> > > > > > Interface Identifiers are 64 bits long, exceptions to this are detailed \
> > > > > > in [EXECPTIONS-TBD]. The rationale for using 64-bit Interface Identifiers \
> > > > > > is in [RFC7421].
> > > > > >
> > > > > > The strategy behind this text is to put the gory details of the \
> > > > > > exceptions themselves in a sperate document, maintaining them over time \
> > > > > > in it instead of the Addressing Architecture. Keeping the Addressing \
> > > > > > Architecture clean and tidy.
> > > > > [...]
> > > > > > I believe the list of exceptions includes;
> > > > > >
> > > > > > 1. Address with the first three bits 000 (I think we need to explain this
> > > > > > better, what was this intended for and how would it be used?)
> > > > > > 2. Statically configured addresses, addresses that are not \
> > > > > > auto-configured, sometimes known as manual configuration. (Does this also \
> > > > > > include DHCPv6 configured addresses if not why not?)
> > > > > > 3. Point to Point Router Links (RFC6164)
> > > > > > 4. Exceptions in IPv6 over FOO documents
> > > > > >
> > > > > > Comments please.
> > > > >
> > > > > If we (WG) agree that it's important to promote at least some part the
> > > > > "addressing architecture" document to IS, I see it's one possible way
> > > > > forward.. In this case I suspect EXECPTIONS-TBD will have to be as
> > > > > close to a verbatim copy of RFC4291 as possible and we'll have to
> > > > > agree that we keep what's already in the PS state as is while
> > > > > promoting the rest to IS. Otherwise I'm afraid we'll simply end up
> > > > > having the same loop of discussion once again just for a differently
> > > > > named document, and as long as it's a normative reference from 4291bis
> > > > > the promotion will get stuck anyway.
> > > > >
> > > > > I'm also afraid this separation won't stop wasting our time on
> > > > > continuing the same arguments from both "camps" for 50 more years,
> > > > > which I think is actually more critical than having another IS doc.
> > > > > But if this approach at least doesn't make the situation worse, the
> > > > > achievement of publishing 4291bis as IS would certainly be a nice
> > > > > event. In that sense I support the idea.
> > > > >
> > > > > --
> > > > > JINMEI, Tatuya
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > IETF IPv6 working group mailing list
> > > > > ipv6 at ietf.org
> > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > > --------------------------------------------------------------------
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6 at ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6 at ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> >
> >
> > --
> > ===============================================
> > David Farmer Email:farmer at 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
> > ===============================================
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
[Attachment #5 (text/html)]
<html><head><meta http-equiv="content-type" content="text/html; \
charset=utf-8"></head><body dir="auto">+1<br><br><div id="AppleMailSignature">Sent \
from my iPhone</div><div><br>On 25 Jun 2018, at 04:10, C. M. Heard <<a \
href="mailto:heard@pobox.com">heard@pobox.com</a>> wrote:<br><br></div><blockquote \
type="cite"><div><div dir="ltr"><div>David,<br></div><div><br></div><div>If you \
pursue this -- and I hope that you do -- I see at least one other thing (besides the \
two mentioned by DY Kim) to move from 4291bis to your proposed BCP. Specifically, the \
length of the prefix for link-local addresses is not constrained by <a \
style="font-size:13.33px" href="https://tools.ietf.org/html/rfc4862" \
target="_blank">RFC 4862</a> to be 64 bits; rather, "[t]he length of the \
interface identifier is defined in a separate link-type-specific document, which \
should also be consistent with the address architecture." So 4291bis Section 2.4.6 \
should be changed as follows:</div><div><br></div><div>OLD:<br></div><div><pre \
class="m_-1816253884621995612m_4480658638922842314gmail-newpage" \
style="color:rgb(0,0,0);font-size:13.33px;margin-top:0px;margin-bottom:0px;page-break-before:always"> \
Link-Local addresses are for use on a single link. Link-Local addresses have the \
following format:
| 10 |
| bits | 54 bits | 64 bits |
+----------+------------------<wbr>-------+----------------------<wbr>------+
|1111111010| 0 | interface ID |
+----------+------------------<wbr>-------+----------------------<wbr>------+</pre></div><div><br></div><div>NEW:<br></div><div><pre \
class="m_-1816253884621995612m_4480658638922842314gmail-newpage" \
style="color:rgb(0,0,0);font-size:13.33px;margin-top:0px;margin-bottom:0px;page-break-before:always"> \
Link-Local addresses are for use on a single link. Link-Local addresses have the \
following format:
| 10 |
| bits | 118-N bits | N bits |
+----------+------------------<wbr>-------+----------------------<wbr>------+
|1111111010| 0 | interface ID |
+----------+------------------<wbr>-------+----------------------<wbr>------+</pre></div><div><pre \
class="m_-1816253884621995612m_4480658638922842314gmail-newpage" \
style="color:rgb(0,0,0);font-size:13.33px;margin-top:0px;margin-bottom:0px;page-break-before:always"><br></pre></div><div><div><pre \
class="m_-1816253884621995612m_4480658638922842314gmail-newpage" \
style="color:rgb(0,0,0);font-size:13.33px;margin-top:0px;margin-bottom:0px;page-break-before:always"> \
where N is the length of the interface ID defined in the \
approppriate</pre></div></div><div><div><pre \
class="m_-1816253884621995612m_4480658638922842314gmail-newpage" \
style="color:rgb(0,0,0);font-size:13.33px;margin-top:0px;margin-bottom:0px;page-break-before:always"> \
<span style="font-family:arial,sans-serif;font-size:13.33px">"IPv6 over <link>" \
specification</span><span \
style="font-family:arial,sans-serif;font-size:13.33px">.</span></pre></div><div><div></div></div></div><div><br></div>Your \
BCP-to-be could then state that N=64 is REQUIRED by current "IPv6 over <link>" \
specifications and RECOMMENDED is in general.<div><br></div><div>Second, note that \
there is an effort underway to update RFC 6177 (see <a \
href="https://www.ietf.org/mail-archive/web/v6ops/current/msg29485.html" \
target="_blank">https://www.ietf.org/mail<wbr>-archive/web/v6ops/current/<wbr>msg29485.html</a>); \
the update to that BCP and your BCP-to-be should, I think, be carefully \
coordinated.</div><div><br></div><div>Mike Heard</div><div><br></div><div><span \
style="color:rgb(0,0,0);font-family:Times;font-size:medium">On Thu, 21 Jun 2018 \
20:45:13 -0500, David Farmer wrote:</span><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div \
dir="ltr"><div class="gmail_quote" \
style="color:rgb(0,0,0);font-family:Times;font-size:medium">On Thu, Jun 21, 2018 at \
8:21 PM, Brian E Carpenter <span dir="ltr"><<a \
href="mailto:brian.e.carpenter+at+gmail.com" target="_blank" \
rel="nofollow">brian.e.carpenter at \
gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">On \
22/06/2018 11:59, DY Kim wrote:<br>> I'd also support the idea, but would like \
further to suggest that the whole 4th para (copied below) of Sec. 2.4.1 be removed \
and placed in separate ISs:<br><br>Try a BCP instead. Firstly, that is a fine \
normative reference for<br>an Internet Standard. Secondly, it (IMHO correctly) fixes \
the choice<br>as the Best Current Practice, which nobody has so far \
disputed.<br><br> Brian<br></blockquote><div><br></div><div><div \
style="font-size:small">I like the idea of at lest part of whole thing as a BCP, \
because one of the things I think should done is to RECOMMED the use \
of 64-bit on-link prefixes and that fits well as a BCP. Hoever, I'm \
not sure some of the other stuff fits in a BCP but we will \
see..</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0..8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">> <br>> \
"Interface Identifiers are 64 bit long except if the first three bits<br>> \
of the address are 000, or when the addresses are manually<br>> \
configured, or by exceptions defined in standards track \
documents.<br>> The rationale for using 64 bit Interface Identifiers \
can be found in [<br>> RFC7421]. An example of a standards track exception \
is [RFC6164<br>> ] that standardises 127 bit prefixes on inter-router \
point-to-point<br>> links."<br>> <br>> And also remove the \
following parenthesis in the last para of Sec. 2.4.4:<br>> <br>> "(and \
therefore having a 64-bit interface ID field)"<br>> <br>> ---<br>> \
DY<br>> <br>>> On 22 Jun 2018, at 02:48, 神明達哉 <<a \
href="mailto:jinmei+at+wide.ad.jp" target="_blank" rel="nofollow">jinmei at \
wide.ad.jp</a>> wrote:<br>>><br>>> At Wed, 20 Jun 2018 12:29:48 \
-0500,<br>>> David Farmer <<a href="mailto:farmer+at+umn.edu" \
target="_blank" rel="nofollow">farmer at umn.edu</a>> \
wrote:<br>>><br>>>> I propose the following text for the critical \
paragraph of contention in<br>>>> section 2.4.1 from \
draft-ietf-6man-rfc4291bis-09;<br>>>><br>>>> Interface Identifiers \
are 64 bits long, exceptions to this are detailed in<br>>>> \
[EXECPTIONS-TBD]. The rationale for using 64-bit Interface Identifiers \
is<br>>>> in [RFC7421].<br>>>><br>>>> The strategy behind \
this text is to put the gory details of the exceptions<br>>>> themselves in \
a sperate document, maintaining them over time in it instead<br>>>> of the \
Addressing Architecture. Keeping the Addressing Architecture clean<br>>>> \
and tidy.<br>>> [...]<br>>>> I believe the list of exceptions \
includes;<br>>>><br>>>> 1. Address with the first three bits 000 (I \
think we need to explain this<br>>>> better, what was this intended for and \
how would it be used?)<br>>>> 2. Statically configured addresses, addresses \
that are not auto-configured,<br>>>> sometimes known as manual \
configuration. (Does this also include DHCPv6<br>>>> configured addresses if \
not why not?)<br>>>> 3. Point to Point Router Links \
(RFC6164)<br>>>> 4. Exceptions in IPv6 over FOO \
documents<br>>>><br>>>> Comments please.<br>>><br>>> If \
we (WG) agree that it's important to promote at least some part the<br>>> \
"addressing architecture" document to IS, I see it's one possible way<br>>> \
forward.. In this case I suspect EXECPTIONS-TBD will have to be as<br>>> \
close to a verbatim copy of RFC4291 as possible and we'll have to<br>>> agree \
that we keep what's already in the PS state as is while<br>>> promoting the \
rest to IS. Otherwise I'm afraid we'll simply end up<br>>> having the \
same loop of discussion once again just for a differently<br>>> named document, \
and as long as it's a normative reference from 4291bis<br>>> the promotion will \
get stuck anyway.<br>>><br>>> I'm also afraid this separation won't stop \
wasting our time on<br>>> continuing the same arguments from both "camps" for \
50 more years,<br>>> which I think is actually more critical than having \
another IS doc.<br>>> But if this approach at least doesn't make the situation \
worse, the<br>>> achievement of publishing 4291bis as IS would certainly be a \
nice<br>>> event. In that sense I support the \
idea.<br>>><br>>> --<br>>> JINMEI, Tatuya<br>>><br>>> \
------------------------------<wbr>------------------------------<wbr>--------<br>>> \
IETF IPv6 working group mailing list<br>>> <a \
href="mailto:ipv6+at+ietf.org" target="_blank" rel="nofollow">ipv6 at \
ietf.org</a><br>>> Administrative Requests: <a \
href="https://www.ietf.org/mailman/listinfo/ipv6" target="_blank" \
rel="nofollow">https://www.ietf.org<wbr>/mailman/listinfo/ipv6</a><br>>> \
------------------------------<wbr>------------------------------<wbr>--------<br>> <br>> \
------------------------------<wbr>------------------------------<wbr>--------<br>> \
IETF IPv6 working group mailing list<br>> <a href="mailto:ipv6+at+ietf.org" \
target="_blank" rel="nofollow">ipv6 at ietf.org</a><br>> Administrative \
Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6" target="_blank" \
rel="nofollow">https://www.ietf.org<wbr>/mailman/listinfo/ipv6</a><br>> \
------------------------------<wbr>------------------------------<wbr>--------<br>> \
<br><br>------------------------------<wbr>------------------------------<wbr>--------<br>IETF \
IPv6 working group mailing list<br><a href="mailto:ipv6+at+ietf.org" target="_blank" \
rel="nofollow">ipv6 at ietf.org</a><br>Administrative Requests: <a \
href="https://www.ietf.org/mailman/listinfo/ipv6" target="_blank" \
rel="nofollow">https://www.ietf.org<wbr>/mailman/listinfo/ipv6</a><br>------------------------------<wbr>------------------------------<wbr>--------<span \
class="m_-1816253884621995612m_4480658638922842314gmail-HOEnZb"><font \
color="#888888"><br></font></span></blockquote></div><span \
class="m_-1816253884621995612m_4480658638922842314gmail-HOEnZb"><font \
color="#888888"><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br \
clear="all" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><div \
style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></div><span \
style="color:rgb(0,0,0);font-family:Times;font-size:medium">-- </span><br \
style="color:rgb(0,0,0);font-family:Times;font-size:medium"><div \
class="m_-1816253884621995612m_4480658638922842314gmail-m_-1431256083163812456gmail_signature" \
style="color:rgb(0,0,0);font-family:Times;font-size:medium">==============================<wbr>=================<br>David \
Farmer <a \
href="mailto:Email%3Afarmer+at+umn.edu" target="_blank" rel="nofollow">Email:farmer \
at 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>==============================<wbr>=================</div></font></span></div></blockquote></div></div>
</div></blockquote><blockquote \
type="cite"><div><span>--------------------------------------------------------------------</span><br><span>IETF \
IPv6 working group mailing list</span><br><span><a \
href="mailto:ipv6@ietf.org">ipv6@ietf.org</a></span><br><span>Administrative \
Requests: <a href="https://www.ietf.org/mailman/listinfo/ipv6">https://www.ietf.org/ma \
ilman/listinfo/ipv6</a></span><br><span>--------------------------------------------------------------------</span><br></div></blockquote></body></html>
--------------------------------------------------------------------
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