Subject: Moving RFC4291-bis forward

From: David Farmer <[email-masked]>
Date: Wed, 20 Jun 2018 12:29:48 -0500

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.

EXECPTIONS-TBD would have to be a Standards Track document normatively
referenced by RFC4291-bis, it will need to enumerate and document all the
exceptions to the 64-bit boundary in some detail.  It will not be easy to
come to a consensus on this.  However, at least we will not have to try to
squeeze it into a paragraph or two within the Addressing Architecture.

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.

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: Thu, 21 Jun 2018 09:10:28 +1200

> of the Addressing Architecture. Keeping the Addressing Architecture clean

That's my goal too. However, I'd go a little further by moving the mention
of 64 out of the architecture document too, because it isn't an
architectural choice. The effect would be the same: put the actual
parameter in a separate and quite short Proposed Standard, with
the Internet Standard being invariant as the argument continues for
the next 50 years.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: David Farmer <[email-masked]>
Date: Wed, 20 Jun 2018 16:47:06 -0500

> the Internet Standard being invariant as the argument continues for

I'd fully support the strategy you are proposing. However, I honestly don't
see it gaining consensus, happy to be proven incorrect.

I can live with the strategy I proposed, even though I'd really prefer your
strategy.  We need to find a consensus that lets RFC4291-bis move forward.
I feel my proposal at least tries to meet the other side halfway.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 11:05:12 +1200

> I feel my proposal at least tries to meet the other side halfway.

Sure. I'd be happier with

Interface Identifiers are 64 bits long in the 2000::/3 space...

but see my note just sent on the other thread.

    Brian

---

From: DY Kim <[email-masked]>
Date: Thu, 21 Jun 2018 09:22:50 +0900

I’d fully support this. Only in this way, the doc would be an arch. Otherwise, it would be an arch contaminated by implementation guidelines.

---
DY

> On 21 Jun 2018, at 06:10, Brian E Carpenter <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Jun 2018 10:48:52 -0700

At Wed, 20 Jun 2018 12:29:48 -0500,

> of the Addressing Architecture. Keeping the Addressing Architecture clean
[...]
> 4. Exceptions in IPv6 over FOO documents

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Jun 2018 20:06:49 +0200

> event.  In that sense I support the idea.

On this particular Subject line.

About the EXCEPTIONS-TBD.

In the recent months, there was blocking of at least two IPv6-over-foo 
documents (6lo WG and IPWAVE WG) about fixed 64.

Why would I write an IPv6-over-USB document with a variable length IID?

This is my last message on this Subject line.

Alex

---

From: DY Kim <[email-masked]>
Date: Fri, 22 Jun 2018 08:59:55 +0900

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:

"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, 神明達哉 <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2018 13:21:24 +1200

> 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

---

From: David Farmer <[email-masked]>
Date: Thu, 21 Jun 2018 20:45:13 -0500

On Thu, Jun 21, 2018 at 8:21 PM, Brian E Carpenter <
[email-masked]> 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.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 21 Jun 2018 20:33:09 -0700

At Thu, 21 Jun 2018 20:45:13 -0500,

> other stuff fits in a BCP but we will see.

I believe PS is the safest, and probably only feasible, choice.  If
the main goal is to promote the non-controversial point of addr-arch
to IS avoiding the risk of seeing another round of same arguments
without any actual progress, I believe the key is to not change
anything for the controversial part including the standard level.

I'm afraid changing it to BCP or introducing a keyword of RECOMMENDED
is risky since it would mean the separated document introduces new
ideas that did not exist in the current addr-arch:

- becoming BCP seems to suggest the choice of fixed prefix/IID length
  or its specific value of 64 is more more operational than part of
  "architecture".  I know it's "obviously" not part of the
  architecture for some people, but we should realize that even that
  point has been controversial and contributed to the wasteful
  repeated debates.
- "RECOMMENDED" effectively weakens the level of requirement; by not
  using RFC2119 keywords, in my understanding it currently implicitly
  means a MUST.  I'm afraid changing it to RECOMMENDED (= SHOULD) will
  be risky in terms of making this effort yet another cycle of the
  same debates.

Naturally, those who want the current spec to change won't be very
excited about not changing anything.  But if it's still PS, at least
the situation won't become worse for them, and I can see some slight
hope that this is something acceptable for them and we can make real
progress (= promoting the rest of addr-arch to IS).

Of course, once it's done, those vocal people can resume the
discussion on whether and how to change the separated PS and/or
whether to promote it to IS without substantial changes, including
whether /64 is good or bad, architectural or not, whether it leads to
NAT, and so on.  Hopefully it will end within my lifetime.

(That said, if the WG can magically agree on BCP or the use of
RECOMMENDED, I personally wouldn't oppose to it).

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Jun 2018 16:03:15 +0900

> NAT, and so on.  Hopefully it will end within my lifetime.

I think it will end once we get to 90+% deployment of IPv6, or when the
majority of person-years of experience in the Internet industry shifts from
working with IPv4 to working with IPv6 - whichever occurs later. I think
that will happen sooner than 50 years from now.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Jun 2018 18:11:26 +0300

> as the Best Current Practice, which nobody has so far disputed.

+1

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Jun 2018 14:31:32 -0700

Brian,

> On Jun 20, 2018, at 2:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I don’t think that completely true.  There are architecture issues relating to the length of Interface IDs, and I don’t think these can be ignored in the the address architecture document.

The issues relate to SLAC auto-configuration and allowing for enough randomness for privacy, as well of generating multiple interface identifiers.   I see these as architectural.   We would need to provide some guidance as to sizes that work.

Also, while I am not sure sure about what I think about what is being proposed here (two documents), I am pretty sure if we go that way, the first one that has the specific text about IID length would have to get completely through the process, before the address architecture could be advanced without it.   Otherwise, a great deal of risk if done together when they get further into the process.  That is, they would have to be done sequentially.

Bob

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 22 Jun 2018 21:49:48 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden

> The issues relate to SLAC auto-configuration and allowing for enough
> randomness for privacy, as well of generating multiple interface identifiers.
> I see these as architectural.   We would need to provide some guidance as to
> sizes that work.

Perhaps, but in the spirit of what is being suggested here, we also do not need to assume that "privacy" is automatically an issue that matters, even when using SLAAC. With IoT, any number of use cases wouldn't care about privacy.

We do have an option of DHCP called "client identifiers." As far as I'm concerned, that's proof enough that people do not always find privacy to be an issue.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Jun 2018 11:20:58 +1200

> I don’t think that completely true.  There are architecture issues relating to the length of Interface IDs, and I don’t think these can be ignored in the the address architecture document.

The fact that there's a trade-off between the need for flexibility and
the need for privacy is indeed architectural, but it seems to me that the
actual trade-off point is an engineering decision.

> The issues relate to SLAC auto-configuration and allowing for enough randomness for privacy, as well of generating multiple interface identifiers.   I see these as architectural.   We would need to…

Right, but "guidance" seems much more like a BCP topic to me.
 
> Also, while I am not sure sure about what I think about what is being proposed here (two documents), I am pretty sure if we go that way, the first one that has the specific text about IID length wo…

Well, certainly they'd have to be done in lock-step. Ideally they would
both be announced as RFCs on the same day.

    Brian