Subject: RFC4291bis

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 11:39:23 +1200

Hi,

Assuming that we adopt draft-farmer-6man-exceptions-64
for the standards track or BCP, I suggest that we should
also update draft-ietf-6man-rfc4291bis as proposed below,
and plan for the two documents to be published as RFCs
simultaneously:

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

      Note: In the case of manual configuration, the Prefix and
      Interface Identifier can be any length as long as they add up to
      128.

NEW:
   Interface Identifiers for stateless address autoconfiguration
   are 64 bits 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. The relationship between prefix length and Interface Identifier
   length is discussed in [I-D.farmer-6man-exceptions-64].

      Note: In the case of manual configuration, the Prefix and
      Interface Identifier can be any length as long as they add up to
      128. In all cases, routing and forwarding processes must be
      designed to process prefixes of any length up to /128 [BCP198].

Comments:

1. This change makes it clear that the 64-bit IID length is for SLAAC.
2. It specifically send the reader to draft-farmer for details.
3. It underlines that routing must work for any length prefix.

    Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 8 Aug 2018 00:07:25 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

But I think those exceptions are not SLAAC-related at all. So perhaps:

NEWNEW

   Interface Identifiers for stateless address autoconfiguration
   are 64 bits long. Otherwise, IIDs are normally 64 bits 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. ... [Rest same as before.]

I'm not sure if there's any reason to mention that these rules only apply to the 2000 prefix.

Bert

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Aug 2018 20:48:59 -0400

>>>>> ipv6  <<[email-masked]> On Behalf Of Brian E Carpenter> writes:

    > I'm not sure if there's any reason to mention that these rules only apply to the 2000 prefix.

I think that they apply to fe80::, ULAs, 3ffe::, and would be the default for
4000::/8, ... until we wrote something else down.  That's why we are saying, !0000::/8

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 13:31:24 +1200

>    documents. ... [Rest same as before.]

Thanks, that works for me.

> I'm not sure if there's any reason to mention that these rules only apply to the 2000 prefix.

See my response to Michael's message.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 13:31:27 +1200

> 4000::/8, ... until we wrote something else down.  That's why we are saying, !0000::/8

Yes. My main concern about the non-2000/3 prefixes is that
we left them in limbo rather than "reserved". Fortunately
IANA has marked them as reserved anyway.

    Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 7 Aug 2018 22:47:19 -0500

> 3. It underlines that routing must work for any length prefix.

That works for me, but I've been thinking "Standard Interface Identifiers
are 64 bit long..." and when refing to 64-bit IID later on in the documnet
use the term "Standard IIDs"

One of the sources of confusion in all of this is not distingusing between
the generic concept of IIDs used in section 2.4, and the standardised
64-bit IID, it gives the faulse impression that all IIDs are 64 bits in
length.

Something to think about, was the change from RFC1884 to RFC2373 intended
to be backward compatible? Or was there a flag day where we went from
RFC1884 (IPv6.0) and to RFC2373 (IPv6.1)?  As I see it RFC2373 was an
incremental change, adding SLAAC with a standardized IID length of 64 bits,
and the subnet assignment prefix (the PIO with the A flag) and allowing
backward compatibility with manual configuration and DHCPv6 based on
RFC1884. The Standard IIDs are required for SLAAC and recommended for
manual configuration and DHCPv6.

Thanks.

--
===============================================
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: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Aug 2018 17:40:20 +1200

> use the term "Standard IIDs"

That only seems to concern two places:

1. The definition of Link-Local IPv6 Unicast Addresses,
which is explicit about the 64.

2. A rather unnecessary reference to RFC 3587, which IMHO
could simply be dropped at this point in history.
 
> RFC1884 (IPv6.0) and to RFC2373 (IPv6.1)?  

July 1998? From what I recall of the implementation and deployment
status then, backwards compatibility wasn't really an issue. As
long as all hosts on a given link were at the same level, all
would be well. Somebody might remember how AIX managed this, since
it had the first commercial release of IPv6 in 1997. But maybe it
didn't have SLAAC initially.

SLAAC was specified from the beginning (RFC1971) for an arbitrary
length interface ID (called "interface token" in RFC1971). 

> As I see it RFC2373 was an

Sure, but RFC1971 implied 48 bit interface tokens.

   Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 8 Aug 2018 00:56:47 -0500

> Sure, but RFC1971 implied 48 bit interface tokens.

Ok, I guess I got the SLAAC part wrong, but the 48-bit to 64-bit was that a
flag day or intended to be backward compatable?

---

From: Mark Smith <[email-masked]>
Date: Wed, 8 Aug 2018 18:51:16 +1000

On Wed., 8 Aug. 2018, 09:39 Brian E Carpenter, <[email-masked]>
wrote:

>    of the address are 000,

or when the addresses are manually
>    configured,

So this reads as though manually configured addresses will never have 64
bit IIDs, as it is stating it is an exception to the 64 bit IID part of the
sentence.

Actually, reference to manually configured addresses doesn't seem relevant
at all, because presumably "stateless address autoconfiguration" is
referring to SLAAC, and SLAAC is an automated address configuration method,
not a manual one.

There seems to be a bit of conflating address configuration methods and
address properties.

In some cases the address properties are specified by the address
configuration method so that an automated address configuration method has
default address properties it can assume out of the box, and will work for
common and ideally all cases without requiring a network operator to
bootstrap the network i.e. SLAAC.

(With a large enough IID space, the constraint on the number if nodes that
can be attached to a link is shifted from being the available and
affordable layer 3 addresses to the underlying link layer constraints.)

In the case of stateful DHCPv6, an assumed default prefix size/IID size is
also useful to minimise the operator effort to configure it. The operator
however has decided to accept the expense of setting up a stateful DHCPv6
infrastructure. The cost of overriding defaults is incremental.

Manual addresses are totally manual, so the operator is required to decide
an address structure. There is no opportunity to reduce operator effort
through reasonable defaults, and going without the benefits of reasonable
defaults is the choice the operator has made by going with manual
configuration.

Regards,
Mark.

or by exceptions defined in standards track documents.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: David Farmer <[email-masked]>
Date: Wed, 8 Aug 2018 08:54:34 -0500

>    length is discussed in [I-D.farmer-6man-exceptions-64].

Sleeping on this, I don't think you are summarizing
draft-farmer-exception-64 correctly. The relationship of prefix length and
Interface Identifier length is only touched on, in my mind it is more about
the relationship of the two parameters that define subnets in IPv6, the
subnet assignment prefix and the on-link prefix. The relationship of prefix
length and Interface Identifier length is really defined in section 2.4 of
RFC4291bis itself. In fact, when my draft talks about the relationship of
prefix length and Interface Identifier length it references RFC4291, which
seems to make it a circular reference.

Also as I wrote it I was thinking of something more like this;

NEW:

Standard Interface Identifiers are 64 bits long, exceptions to this are
detailed in [I-D.farmer-6man-exceptions-64].  The rationale for using
64-bit Interface Identifiers can be found in [RFC7421].

These are complicated issues trying to say anything about the details in a
single paragraph will undoubtedly oversimplify something, giving someone
something to object too.

Thanks

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Aug 2018 11:43:32 -0700

At Wed, 8 Aug 2018 11:39:23 +1200,

> and plan for the two documents to be published as RFCs

I don't see how we can suddenly agree on publishing rfc4291bis as an
IS with keeping the most controversial text just with some new wording
tweak and a reference to draft-farmer-6man-exceptions.  In fact, if it
were possible, I suspect we could even do that without a new document
(i.e., 6man-exceptions).

To this end I wondered how we failed with
draft-ietf-6man-rfc4291bis-09 and have skimmed the discussion at that
time starting from:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27919.html
and found the following controversial points:

- the word "by exceptions defined in standards track documents" (see
  also my recent message to the draft-farmer-6man-exceptions thread)
- referring to a specific way of configuring addresses (in particular
  SLAAC) from the Addressing *Architecture* document.

The proposed new text still has these two points.  I'd be pessimistic
about the odds for "this time is different" just because of this fact.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Aug 2018 09:06:28 +1200

> were possible, I suspect we could even do that without a new document

I don't think it's "suddenly". If we can reach agreement on the
way draft-farmer describes things, then we can simultaneously use that
to reach rough consensus on 4291bis. The two things go together.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Aug 2018 09:09:02 +1200

Comment at the very end:

> flag day or intended to be backward compatable?

I'm pretty sure we expected it to be a flag-day on any individual
link.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Aug 2018 10:55:54 +1200

> referring to SLAAC, and SLAAC is an automated address configuration method,

But there are potentially many automated methods, such as DHCPv6,
where the concept of a fixed IID length is unnecessary. However,
people previously objected to wording in which the standard length
was formally only applicable to SLAAC.
 
> There seems to be a bit of conflating address configuration methods and

Yes.

> bootstrap the network i.e. SLAAC.

Yes. 

> also useful to minimise the operator effort to configure it.

Useful, but not required.

> The operator

Sure. But if you ask: "Could we invent a method of autonomously assigning
addresses that does not depend on a standardised IID length?" of
course we could. So maybe the correct formulation is:

 Interface Identifiers are 64 bits long for any method of
 address assignment that depends upon a standardised length.

I'll stop there, because in my mind that is a significant
change that might just allow us to stop digging this hole.

    Brian