Subject: RFC4291bis (new try)

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Aug 2018 15:21:13 +1200

Hi,

Assuming that we adopt draft-farmer-6man-exceptions-64
for the standards track or BCP, and considering recent
comments on my previous attempt, 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 are 64 bits long for any method of
   address assignment that depends on a standardised length,
   except if the first three bits of the address are 000, or if
   defined otherwise 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. Related issues are discussed in [I-D.farmer-6man-exceptions-64].

      Note: In all cases, routing and forwarding processes must be
      designed to process prefixes of any length up to /128 [BCP198].

Comments:

1. This version avoids specific reference to either SLAAC or
   manual assignment.
2. The note about prefix+IID adding up to 128 was redundant.
3. I believe that the first three citations help the reader.
4. The citation of BCP198 is strictly speaking redundant, but
   I believe it prevents any possible misunderstandings.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Aug 2018 11:02:15 -0400

> defined otherwise in standards track documents.

I am reading this as saying that whenever I see an address in 2000::/8
(and a few other places) that I may assume that the IID is 64-bit, and that
the prefix/IID boundary is at 64.  Unless I know it's on a media where
a standards track document has changed things.  I don't know why we want
to encourage anyone to make this assumption, or what value it brings.
But, it seems to provide a classful interpretation of addressing that
isn't really true. (Because an outsider never knows where there are PPP links
in 2000::/8 or where there are specialized media that fall under other
standards track documents)

I would prefer to say:

NEW:
    Interface Identifiers (IIDs) are 64 bits long for any method of
    address assignment that depends on a standardised length.
    IPv6 addresses that start with three bits of 000 (0000::/8)
    use specialized forms of address assignment that does not depend upon
    IIDs at all.
    A standards track document MAY define override this guideline.

    > 3. I believe that the first three citations help the reader.

I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Aug 2018 08:09:45 -0700

At Fri, 10 Aug 2018 15:21:13 +1200,

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

I don't understand how this text could succeed, reviewing how we failed
for draft-ietf-6man-rfc4291bis-09.

>    configured, or by exceptions defined in standards track documents.

One major controversy in rfc4291bis is the "by exceptions defined in
standards track documents" phrase (see my previous response on this

>    defined otherwise in standards track documents.

I-D.farmer-6man-exceptions-64 is still in a state of flux, but based
on discussions about it so far, I don't see how I-D.farmer and
reference to it could magically make it non-controversial.

If something could ever succeed, the only possible approach I can
think of is:
A: delegating all discussions about IID length to
   I-D.farmer-6man-exceptions-64, and
B: keeping "what we have now" including the barrier level of changing the
  constant of 64 as much as possible in I-D.farmer-6man-exceptions-64

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Fri, 10 Aug 2018 09:59:00 -0700

I might like to remind the group of the suggestions made by me and Heard back in June 22 as the followings:

[1; DY] Remove the whole 4th para (copied below):

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

[2; DY] Also remove the following parenthesis in the last para of Sec. 2.4.4:

    "(and therefore having a 64-bit interface ID field)”

[3; Heard] Sec. 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.

[4; implied] Suggestions A & B of Jinmei as below.

Sent from my iPad

> On 10 Aug 2018, at 8:09 AM, 神明達哉 <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Aug 2018 08:52:24 +1200

Michael,

On 11/08/2018 03:02, Michael Richardson wrote:
> the prefix/IID boundary is at 64.  

No! You must never assume anything when you see an address; it is
simply 128 opaque bits. The whole discussion only applies at the
time and place where the address is constructed.

> Unless I know it's on a media where

Exactly. But that applies in all formulations.

>     A standards track document MAY define override this guideline.

No objection, if people find that clearer.

   Brian

---

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

> for draft-ietf-6man-rfc4291bis-09.

Maybe I am just an optimist ;-)

> topic).  The new text essentially has the same phrase:

Well, yes, and it is of course a phrase that we could delete since
it is by definition always true of every standards track document.
So personally I would be happy to delete it, if people agree.

>   constant of 64 as much as possible in I-D.farmer-6man-exceptions-64

I would be happy with that, but last time around people objected
to simply removing the statement about 64 bits from 4291bis.

     Brian

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Aug 2018 17:22:12 -0700

At Sat, 11 Aug 2018 11:54:55 +1200,

> to simply removing the statement about 64 bits from 4291bis.

Right, and this approach actually does that: removing the statement
about 64 bits from 4291bis (by moving it to I-D.farmer).  Perhaps by
"simply removing" you meant removing the statement from the entire
world (including I-D.farmer), not just from 4291bis?  If so, yes, this
approach could still face that objection.  I explained the reason for
my version of optimism regarding this point in the other thread: we
can at least tell them that we don't give "64 bits" a rubber-stamp of
Internet Standard and that if we don't adopt it the result is the same
anyway; the latest standard will still be RFC4291, which has the
statement about 64 bits.

Of course, I may just be an optimist here.  But this is the best and
only approach that I can think of might work anyway.

--
JINMEI, Tatuya

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 11 Aug 2018 11:38:14 +0300

>      A standards track document MAY define override this guideline.

This is a subtle and succinct way of handling the IID specification 
conundrum.  I'd be happy to see this text in RFC4291-bis.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Aug 2018 12:35:24 -0400

> time and place where the address is constructed.

Like I said, this is what I'm reading, and I don't think it's what you mean
to say.  I read:
   one may depend upon IIDs being 64-bits when X, not Y, with
   possible overidding by Z.

---

From: Job Snijders <[email-masked]>
Date: Sat, 11 Aug 2018 20:22:48 +0300

> conundrum.  I'd be happy to see this text in RFC4291-bis.

Agreed.

Kind regards,

Job