Subject: Fwd: I-D Action: draft-carpenter-6man-lap-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jun 2018 14:25:54 +1200

Comments, of course, are very welcome. This draft is a very easy read.

    Brian

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-6man-lap-00.txt
Date: Tue, 12 Jun 2018 19:15:53 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : The Longest Acceptable Prefix for IPv6 Links
        Author          : Brian Carpenter
	Filename        : draft-carpenter-6man-lap-00.txt
	Pages           : 4
	Date            : 2018-06-12

Abstract:
   This document introduces the concept of a Longest Acceptable Prefix
   for an IPv6 link.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-lap/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-6man-lap-00
https://datatracker.ietf.org/doc/html/draft-carpenter-6man-lap-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jun 2018 11:53:21 +0900

I don't see much point in pursuing this document, unfortunately. This is
because:

   1. I don't think there is value of this document unless it precisely
   defines what a LAP is.
   2. I suspect the working group will not be able to reach consensus on
   any definition of LAP. This is because there will be participants that
   claim that the prefix length for address assignment is already clearly
   defined in RFC 4291 as being "64 bits long", and there will be participants
   to whom that definition is unacceptable.

The document says the goal of the document is not to rehash those opinions,
but it does look very much like a rehash to me.

On Wed, Jun 13, 2018 at 11:26 AM Brian E Carpenter <
[email-masked]> wrote:

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jun 2018 07:28:35 +0200 (CEST)

> but it does look very much like a rehash to me.

I interpret the document as trying to create a name for what we're 
typically arguing about, and naming it LAP. It doesn't try to define 
anything else or propose any changes.

While I think it helps to have agreed upon terminology when discussing 
things, the LAP might not help. There have been proposal in 5ganip mailing 
list about address mapping systems that would make non-contiguous blocks 
of addresses (prefix) available to the device (for instance a bunch of 
/96:es), which means this LAP concept doesn't apply, since it might now be 
of more interest to discuss the amount of aggregate addresses available to 
the device instead of the prefix length of the single prefix on-link.

I have no idea how to do that though... :)

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Jun 2018 12:15:57 +0100

Lorenzo Colitti wrote on 13/06/2018 03:53:
> This is because there will be participants that claim that the prefix 
> length for address assignment is already clearly defined in RFC 4291 as 
> being "64 bits long",

I can't see this in RFC 4291.  Are you mixing up address assignment and 
interface ID?

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 00:20:50 +0900

> I can't see this in RFC 4291.  Are you mixing up address assignment and

RFC 4291 says that IPv6 addresses are composed of n-bit subnet prefixes and
128-n bit interface IDs. Then it says that for pretty much all unicast
addresses 128-n=64. Thus, n=64.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Jun 2018 16:25:37 +0100

Lorenzo Colitti wrote on 13/06/2018 16:20:
> RFC 4291 says that IPv6 addresses are composed of n-bit subnet prefixes 
> and 128-n bit interface IDs. Then it says that for pretty much all 
> unicast addresses 128-n=64. Thus, n=64.

"pretty much all" != "all"

This may be what Brian is talking about.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 00:38:24 +0900

> This may be what Brian is talking about.

I doubt it. The difference between "pretty much all" and "all" is unicast
addresses that start with binary 000, which aren't routable on the Internet.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Jun 2018 16:39:23 +0100

Lorenzo Colitti wrote on 13/06/2018 16:38:
> I doubt it. The difference between "pretty much all" and "all" is 
> unicast addresses that start with binary 000, which aren't routable on 
> the Internet.

my /127 subnets disagree.

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Jun 2018 11:31:15 -0500

> my /127 subnets disagree.

Nick, while I agree with you, you are basically making Lorenzo's point,
this just degrades into a rehash of RFC4291-bis.

So, would someone from Lorenzo's camp please propose language that
rationalizes RFC6164 with the 64-bit IIDs of RFC4291.

I'm tired of attempt after attemp being put forth and being told nope
that's not it, it is time for you guys to put language on the table.

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, 14 Jun 2018 09:27:49 +1200

> that's not it, it is time for you guys to put language on the table.

Exactly why I'm trying to put a new term on the table that allows
us to think a little bit outside the box. Longest *Acceptable* Prefix
is intended to underline that the builder or operator of a network
has a choice to make. If the choice is to allow SLAAC to work properly,
LAP==64 today. If not, some other longest prefix length might be
acceptable.

Yes, it's playing with words, but that's what we do in this RFC factory
of ours.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Jun 2018 09:04:53 +1000

Hi Brian,

I'd say there is also a complimentary term - Shortest Acceptable Interface
Identifier.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2018 13:47:46 +1200

> I'd say there is also a complimentary term - Shortest Acceptable Interface

Yes, that makes a lot of sense. Then of course LAP+SAID <= 128.

I think we can discuss the "race to the bottom" and privacy arguments
rationally with this terminology.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 11:00:05 +0900

> rationally with this terminology.

If the problem here is that some people think that changing the acceptable
prefix length will cause a race to the bottom, then how does creating a
name help? Just so that have a name to use to track progress in the race?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 11:08:40 +0900

> that's not it, it is time for you guys to put language on the table.

Several proposals were made. Off the top of my head, I believe those
included at least a) an exception for statically configured addresses b) an
exception to allow IPv6-over-foo documents to specify a different length
for the link type, and c) changing the "except for unicast addresses that
start with 000" to "except where otherwise stated by an IETF standard". My
recollection is that none of these went far enough to satisfy the other
camp so they weren't pursued.

The conclusion I took home from that is that the drive behind the proposals
to modify 4291bis actually has to do with people wanting to assign less
address space to users on existing link types, which if you ask me is just
going to create a race to the bottom.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Jun 2018 19:17:04 -0700

Brian,

I like the idea of defining the terminology for discussion, howevere I
think that the meaning of "acceptable" should be clarified. I believe
that the implication of the draft is that a LAP is local to a site and
is in no way a global concept or requirement. Also, I think it should
be clarified that prefix length does itself not correlate to user
privacy privacy, there are many other factors at play such that in
some cases a longer prefix could offer better privacy properties than
a shorter one (for instance I am concerned about the privacy
properties of the prefix itself especially in cases where single end
devices are assigned their own prefix).

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2018 15:22:03 +1200

Tom,

Yes. This was very much a first cut.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2018 15:36:27 +1200

> name help? Just so that have a name to use to track progress in the race?

Two names, adding Mark Smith's SAID suggestion. And yes, having a name or
names that express that there's a decision involved (is this acceptable?)
is IMHO a way to track progress in the discussion as well as in deployment.
It's a very mild form of a thinking tool (as per Daniel Kahneman).

If somebody wants to deploy subnets with a maximum of (say) 256 IoT
nodes, and doesn't care about entropy in the IIDs because of privacy
aspects of the specific scenario, why should we care if they choose
a SAID of 8 bits?

(Why might that be a good thing? Because it would allow you to express
addresses within the subnet in 8 bits. For a constrained IoT node that might
be very important.)

That's the kind of discussion we can have with such terminology.
If we can't have that discussion, we're throwing away valuable
flexibility for the universal deployment of IPv6.

I don't think anybody is arguing against LAP=64, SAID=64 as the
general default.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Jun 2018 10:35:40 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Two names, adding Mark Smith's SAID suggestion. And yes, having a name
    > or names that express that there's a decision involved (is this
    > acceptable?)  is IMHO a way to track progress in the discussion as well
    > as in deployment.  It's a very mild form of a thinking tool (as per
    > Daniel Kahneman).

I'm always in favour of having names to talk about things.

    > aspects of the specific scenario, why should we care if they choose a
    > SAID of 8 bits?

    > addresses within the subnet in 8 bits. For a constrained IoT node that
    > might be very important.)

Just to add, that this is real, not just "might", but that it's 16-bits.

802.15.4 networks support 64-bit EUIs for layer-2, as well as having a 2-byte
version.   Assigning the IIDs to match the L2 ID results in significant
compression savings.    The 64-bit EUIs can be manufacturer assigned, or
could be randomly generated.  The 2-byte addresses can be assigned via
a variety of ways, DHCPv6 and draft-ietf-6tisch-minimal-security come to
mind.

Today, IoT devices do not visit Starbucks or Airports and worry about being
tracked.  In the future when we have actual PANs of devices on one's person,
it is my contention that they won't talk to the Airport WIFI either.
(Likely they will be ULAs, with VPNs back to places that care about them)
However, even when encrypted, 802.15.4 networks leak L2-addresses just like
wifi networks do, but 16-bit layer-2 addresses are likely meaningless.

In 6tisch/6lo 802.15.4 networks, the network is still /64, there are just lot
of zeroes.

    > That's the kind of discussion we can have with such terminology.  If we
    > can't have that discussion, we're throwing away valuable flexibility
    > for the universal deployment of IPv6.

    > I don't think anybody is arguing against LAP=64, SAID=64 as the general
    > default.

+1.

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Jun 2018 10:38:42 -0400

Maybe, instead of Longest Acceptable Prefix, we should speak about
Longest Operational Prefix, or some word that implies: "that will work"

---

From: Fernando Gont <[email-masked]>
Date: Thu, 14 Jun 2018 18:50:20 +0300

On 06/13/2018 07:31 PM, David Farmer wrote:
> 
> 
> On Wed, Jun 13, 2018 at 10:39 AM, Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         I doubt it. The difference between "pretty much all" and "all"
>         is unicast addresses that start with binary 000, which aren't
>         routable on the Internet.
> 
> 
> this just degrades into a rehash of RFC4291-bis.>

Rationale: Folks realized that there are reasons for which you might do
LAP != 64. -- which is not a surprise, since the rationale for the
specific "64" value is simply "historical reasons".

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 14 Jun 2018 18:54:30 +0300

> aspects of the specific scenario, why should we care if they choose

In fact, long addresses seem to be so bad for constrained devices than
one has to resort to a kludge such as "header compression".

Header compression itself relies on an historical fact (MAC addresses in
IIDs), which we have moved away from (RFC8064). Meaning that if IoT
devices cannot handle long addresses, they'd be better off using lnger
prefixes rather than relying on kludges such as header compression.

---

From: Mark Smith <[email-masked]>
Date: Fri, 15 Jun 2018 05:24:16 +1000

> specific "64" value is simply "historical reasons".

And proven simplicity, proven by other protocols developed in the 1980s,
and deployed in the 1990s.

IPv4 was a terrible protocol to understand and deploy compared to IPX and
AppleTalk. They just worked. (My first protocol was IPX, when leaning IPv4
the fundamental question I wondered was "Why is this so hard and
complicated?" Then I taught it. That took 5 attempts before I fully felt
happy with how I'd taught and explained IPv4 addressing - and that didn't
even cover CIDR.)

For IPX, all you had to get right was give each link a unique 32 bit
network number. You set no other parameters. No complicated classes,
subnets, subnet masks, bit level maths etc. No worries about running out of
addresses on a link because the link host address space was 48 bits. Most
of the time you didn't even see IPX addresses, as they were hidden behind
service names.

The only reason that people put up with deploying IPv4 in the 1990s was
because it was the protocol needed to access the Internet. That made the
price worth paying, however it doesn't make IPv4 a superior protocol over
these later 1980s protocols, in terms of usability, supportability and
deployability.

IPv4's complexity makes sense, it was designed in the early to mid 1970s
for an experimental research project, and then had to be extended a number
of times for a use case it was never designed for - a global internetwork
connecting billions of devices.

By the 1980s, PCs and LANs had come along, and it was probably obvious that
networks were now going to become far more common. "Plug-and-play"
protocols like Ethernet, IPX and AppleTalk were the result.

Those 1980s protocols' usability, supportability and deployability levels
are the ones I expect IPv6 to meet and exceed, not IPv4's.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Jun 2018 14:25:45 -0500

I think we need to discuss prefixes from both an Operational use and an
Allocation context.

On the Operational of side things, discussing issues like SLAAC needing a
/64 prefix, a static assignment can be any length, and /127s for point to
point links seem appropriate.  I think we also need to define Static
Assignment. I chose Static Assignment, over Manual Assignment, because with
the creation of servers and networks via scripts with Puppet and Chef,
manual doesn't satisfactorily describe that situation in my opinion.

On the Allocation side of things, discussing issues like Nibble Alignment,
Sparse Allocation, End Site Assignments, and addressing plans are in order.

Based on the issues around ITU-T SG20 discussion, it seems to me that the
IETF should probably say more about what makes a good addressing plan.

Thanks.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 14 Jun 2018 23:21:30 +0300

On 06/14/2018 10:24 PM, Mark Smith wrote:
> IPv4 was a terrible protocol to understand and deploy compared to IPX
> and AppleTalk. They just worked. (My first protocol was IPX, when
> leaning IPv4 the fundamental question I wondered was "Why is this so
> hard and complicated?" Then I taught it. That took 5 attempts before I
> fully felt happy with how I'd taught and explained IPv4 addressing - and
> that didn't even cover CIDR.)

People usually ask the same question about IPv6. Example: compare ARP +
DHCP with ND + combo(SLAAC/DHCPv6)

Besides, you don't *need* to use subnet sizes != 64. If you lie /64,
nobody will force you to do something else.

> Those 1980s protocols' usability, supportability and deployability
> levels are the ones I expect IPv6 to meet and exceed, not IPv4's.

With fixed length IID's, host willing to extend the network further and
further will be forced to do NAT.

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Jun 2018 09:07:15 +1000

> DHCP with ND + combo(SLAAC/DHCPv6)
No where near as complicated as IPv4 Classful / subnet/ variable length
subnet / CIDR addressing.

People could ask the same reason why there are 7 layers in the OSI
reference model, rather than just one. The answer is the same.

> nobody will force you to do something else.
There's a lot of things we don't need.

We didn't "need" ARP, we could have manually loaded each host with static
MAC address to IP address mapping tables.

We didn't need DHCPv4 or BOOTP/RARP either. All those settings were
possible to set manually on each host too.

We don't "need" dishwashers or washing machines, we could have continued to
manually wash our dishes and clothes.

Many of our technologies are fundamentally optional, however they make our
life simpler and cheaper and that is why we design, build and use them.

In IPv4 we needed variable length edge subnets/prefixes (and Classes and
all the other things that preceded CIDR) to continue to be able to use IPv4
within its fundamental constraint of 32 bit addresses. We don't need them
in IPv6.

> further will be forced to do NAT.
If any host can't get an IPv6 address from the network (and more than one
per BCP204), then the IPv6 deployment and IPv6 network is broken, because
the fundamental reason for IPv6 - many many more addresses than IPv4 -
isn't being achieved. Continue to use IPv4(+NAT), or give up and tell the
user the network is broken.

We need to stop trying to reduce IPv6's functionality to IPv4's to suit
those who don't really want to learn to think in IPv6 (by recreating
address scarcity when it isn't necessary, that is creating artificial
address scarcity).

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2018 12:06:40 +1200

> within its fundamental constraint of 32 bit addresses. We don't need them

Not as far as we know, today, which is why nobody has suggested changing
the default from /64. Not having a very good crystal ball, I don't
know what people might need 50 years from now. 
 
> per BCP204), then the IPv6 deployment and IPv6 network is broken,

That isn't something the IETF can control, unfortunately.

> because
> We need to stop trying to reduce IPv6's functionality to IPv4's 

That's caricaturing the idea of increasing IPv6's flexibility.

> to suit

If ISPs do that, they'll suffer the consequences.

   Brian