Subject: Re: Moving RFC4291-bis forward

From: "C. M. Heard" <[email-masked]>
Date: Sun, 24 Jun 2018 12:10:49 -0700

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
<https://tools.ietf.org/html/rfc4862> 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
> ===============================================
>

---

From: DaeYoung KIM <[email-masked]>
Date: Mon, 25 Jun 2018 14:37:58 +0900

+1

Sent from my iPhone

> On 25 Jun 2018, at 04:10, C. M. Heard <[email-masked]> 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:
> 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, Jun 21, 2018 at 8:21 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> 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:
>>> 
>> 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.
>> 
>>> > 
>>> >    The rationale for using 64 bit Interface Identifiers can be found in [
>>> > And also remove the following parenthesis in the last para of Sec. 2.4.4:
>>> > 
>>> >>> I propose the following text for the critical paragraph of contention in
>>> >>> 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.
>>> >> [...]
>>> >>> 1. Address with the first three bits 000 (I think we need to explain this
>>> >>> 2. Statically configured addresses, addresses that are not auto-configured,
>>> >>> sometimes known as manual configuration. (Does this also include DHCPv6
>>> >> forward..  In this case I suspect EXECPTIONS-TBD will have to be as
> [email-masked]