Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 10:25:08 +0900

At the end of Sec. 4, it reads:

"After the UE/subscriber received the RA, and the associated flags, it
   will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the UE/subscriber device itself, it will need
   to verify that the address is unique on the shared network.  The UE/
   subscriber will for that purpose, perform Duplicate Address Detection
   algorithm.  This will occur for each address the UE attempts to
   utilize on the shared provider managed network.”

Now the each device has a unique prefix, there’d be no chance that 128 bit addresses generated by different devices should collide. Do we need DAD here?

---
DY

> On 31 Jul 2017, at 16:00, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
> 
>        Title           : Unique IPv6 Prefix Per Host
>        Authors         : John Jason Brzozowski
>                          Gunter Van De Velde
> 	Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
> 	Pages           : 8
> 	Date            : 2017-07-31
> 
> Abstract:
>   In some IPv6 environments, the need has arisen for hosts to be able
>   to utilize a unique IPv6 prefix, even though the link or media may be
>   shared.  Typically hosts (subscribers) on a shared network, either
>   wired or wireless, such as Ethernet, WiFi, etc., will acquire unique
>   IPv6 addresses from a common IPv6 prefix that is allocated or
>   assigned for use on a specific link.
> 
>   In most deployments today, IPv6 address assignment from a single IPv6
>   prefix on a shared network is done by either using IPv6 stateless
>   address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
>   this is still viable and operates as designed, there are some large
>   scale environments where this concept introduces significant
>   performance challenges and implications, specifically related to IPv6
>   router and neighbor discovery.
> 
>   This document outlines an approach utilising existing IPv6 protocols
>   to allow hosts to be assigned a unique IPv6 prefix (instead of a
>   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
>   IPv6 prefix over a unique IPv6 address from the service provider
>   include improved subscriber isolation and enhanced subscriber
>   management.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-07
> 
> 
> 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/
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 10:39:21 +0900

In the 2nd para of Sec. 4, it reads:

"The Unique IPv6 prefix can be derived from a locally managed
   pool or aggregate IPv6 block assigned to the First Hop Provider
   Router or from a centrally allocated pool.”

In the case the prefix is assigned from a centrally allocated pool, does this scenario include the following cases?:

	o all prefixes assigned to devices on the same shared network may not be aggregatable into a single shorter prefix.
	o /64 prefixes may be assigned randomly to different devices on different share network.

---
DY

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
> Date: 31 July 2017 at 16:00:57 GMT+9
> To: <[email-masked]>
> Cc: [email-masked]
> 
>

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 10:53:18 +0900

“… a Unique IPv6 prefix (currently a /64 prefix)…”

Assuming that there’d be at some place upwards where a /48 prefix would be present, which prefix length is up to a common practice for ISPs in assigning a prefix to a site, does the above spec means:

	o the maximum number of devices that the proposed scenario can accommodate is 64K (2**16; 64 - 48 = 16)?

---
DY

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Aug 2017 12:39:40 +1000

On 4 August 2017 at 11:53, DY Kim <[email-masked]> wrote:
> Assuming that there’d be at some place upwards where a /48 prefix would be
> present, which prefix length is up to a common practice for ISPs in
> assigning a prefix to a site, does the above spec means:
>

(Not speaking on the authors behalf)

If you only received a /48 for your site, then yes, that would be the
upper limit on how many devices this method supported.

However, the scenario being described is one of a service provider,
and they will get at least a /32 from their RIR, meaning in theory the
maximum number of hosts they can support is 4 billion (!). They could
get larger than /32 if they needed to if it became too small.

In this scenario a "site" is really the individual host, rather than a
boundary of a group of subnets at a site. /48 or /56 are common
aggregation boundaries for a multi-subnet site, so they don't really
apply here. The service provider could internally aggregate the /64s
at any where they need to between e.g. /32 and /63 to suit their
routing protocol scaling.

So in short, /48 is not constraining this solution because /48 doesn't apply.

Regards,
Mark.

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 11:47:09 +0900

Taken. 

A follow-on question:

Assume the site under my management purview is assigned a /48 prefix from an upstream provider. Can I apply this BCP to the devices in my site?

I think that’s at least technically possible. And I don’t see a text in the doc which prevents me from doing that on my own autonomous decision and responsibility. Right?

---
DY

> On 4 Aug 2017, at 11:39, Mark Smith <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 05:12:59 +0200 (CEST)

> Now the each device has a unique prefix, there’d be no chance that 128 bit addresses generated by different devices should collide. Do we need DAD here?

No, we don't.

That is what 
https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 is 
about.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Aug 2017 13:48:22 +1000

> Assume the site under my management purview is assigned a /48 prefix from an upstream provider. Can I apply this BCP to the devices in my site?

No reason you couldn't, how you use those 64k /64s is up you and would
be hidden from the provider.

I can imagine some sites might have a mix of per-host /64s as well as
a number of /64s with multiple hosts (that is, today's model), perhaps
where some of the devices are unlikely to benefit from having their
own /64 e.g., low powered IoT/sensor devices perhaps. A residential
network might have a mix.

> I think that’s at least technically possible. And I don’t see a text in the doc which prevents me from doing that on my own autonomous decision and responsibility. Right?

Even if there was text in the document that stated it was prohibited,
I don't see how it could be policed, or be worth paying the cost of
developing a system to try to police it.

Regards,
Mark.

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 15:57:52 +0900

Thanks.

Regards,
DY

> On 4 Aug 2017, at 12:12, Mikael Abrahamsson <[email-masked]> wrote:
> 
> That is what https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02 is about.
> 
> --

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 16:01:19 +0900

Thanks.

Then… is the number ‘/64’ of this document a MUST or MAY?

For example, I might like to assign to each nodes in my site /96 prefix instead of /64.

Is this prohibited by this document? Or is ‘/64’ mentioned in the document only an example?

Regards,
DY

> On 4 Aug 2017, at 12:48, Mark Smith <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 16:08:28 +0900

Is this I-D compliant with RFC 4291bis stating..?:

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+————————————————————————---------+

The prefix under discussion in the I-D should be a node prefix, whereas all RFC 4291 comments on is the subnet prefix.

Or.. is it that the subnet prefix mentioned in RFC 4291bis is just an example, and you can assign prefixes to any network entities including node, subnet, or whatever?

Regards,
DY

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 16:15:15 +0900

So, you need neither ND nor DAD with the proposed BCP…?

--------
Regards,
DY

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 09:28:29 +0200 (CEST)

> So, you need neither ND nor DAD with the proposed BCP…?

If you're talking about PIO-X, then correct.

It's not BCP, it's currently intended to be experimental.

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 16:32:59 +0900

4291bis further states:

> Except for the knowledge of the subnet boundary discussed in the
>    previous paragraphs, nodes should not make any assumptions about the
>    structure of an IPv6 address.

This sounds to me “no structure other than subnet should be assumed.” … which could mean (local, not global) prefixes may not be assigned to network entities other than subnets.

Isn’t the I-D in conflict with this parent (to-be-)standard RFC 4291bis?

----------
Regards,
DY

> On 4 Aug 2017, at 16:08, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 16:34:59 +0900

Oh… I meant the I-D in cited in the subject field of this thread; unique-ipv6-prefix-per-host.

The I-D says it’s intended status is BCP.

----------
Regards,
DY

> On 4 Aug 2017, at 16:28, Mikael Abrahamsson <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 10:15:33 +0200 (CEST)

> The I-D says it’s intended status is BCP.

As far as I know, unique-ipv6-prefix-per-host doesn't suggest any changes 
to the host ipv6 stack. That's why it's a v6ops document and not a 6man 
document.

So it doesn't change any standards, it tries to describe a deployment 
scenario, working within currently deployed standards.

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Aug 2017 18:18:13 +1000

> For example, I might like to assign to each nodes in my site /96 prefix instead of /64.

Why specifically might you like to assign /96s? What benefit do you get?

If you don't have enough /64s for one for each host, then somebody
upstream is being unnecessarily miserly with IPv6 address space.

> Is this prohibited by this document? Or is ‘/64’ mentioned in the document only an example?

No. /64s as the subnet size as been the common edge subnet/IID
boundary for almost 20 years since RFC2373.

Variable length subnetmasking and CIDR in IPv4 was a work around to
not having enough addressing bits (as were address classes and
subnets) for how the Internet Protocols ended up being used -
initially it was a research project protocol that became an
unmitigated success.

Analysis of the 64-bit Boundary in IPv6 Addressing
https://tools.ietf.org/rfc/rfc7421.txt

Regards,
Mark.

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 17:42:04 +0900

in line...

--------
Regards,
DY

> On 4 Aug 2017, at 17:18, Mark Smith <[email-masked]> wrote:
> 

Now that a device (can I say ‘node’?) trackable by its (/64) unique prefix, the privacy of the node might be compromised.

To combat this, you might want to regularly randomize/refresh the prefix for a given node to secure privacy from eavesdroppers, except that the privacy is not secured to the entity distributing the prefixes.

For enough randomization in that case, I might like to have enough (say 48) additional bits for the node prefix, rendering 48+48=96; 48 is shorter than 64, but should be large enough for randomization for privacy.

> boundary for almost 20 years since RFC2373.

In this I-D, /64s are not assigned to ‘subnets' but to ‘nodes' in a shared network.

Or do you mean what RFC 4291bis really wanted say was the boundary for 'any prefix'/IID is at 64th bit?

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 17:43:30 +0900

All mentioned in 4291bis is the subnet prefix, not the node prefix.

--------
Regards,
DY

> On 4 Aug 2017, at 17:15, Mikael Abrahamsson <[email-masked]> wrote:
> 
> So it doesn't change any standards, it tries to describe a deployment scenario, working within currently deployed standards.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Aug 2017 10:52:55 +0200 (CEST)

> All mentioned in 4291bis is the subnet prefix, not the node prefix.

It's impossible for me to follow your comments when you're changing what 
document you're talking about all the time.

draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose any change in 
standards. Agreed?

So your above comment, what is that about? How does it relate to 
draft-ietf-v6ops-unique-ipv6-prefix-per-host ?

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 17:56:48 +0900

OK, I’ll try again.

  o No concept of ‘node prefix’ is mentioned in 4291bis.

  o 'draft-ietf-v6ops-unique-ipv6-prefix-per-host’ talks about ‘node prefix’.

Although 'draft-ietf-v6ops-unique-ipv6-prefix-per-host’ is not meant to change the standard 4291bis, isn’t that in conflict with 4291bis in that the draft uses a notion not defined in the parent standard.

--------
Regards,
DY

> On 4 Aug 2017, at 17:52, Mikael Abrahamsson <[email-masked]> wrote:
> 
> It's impossible for me to follow your comments when you're changing what document you're talking about all the time.
> 
> draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn't propose any change in standards. Agreed?
> 
> So your above comment, what is that about? How does it relate to draft-ietf-v6ops-unique-ipv6-prefix-per-host ?
> 
> --

---

From: Tim Chown <[email-masked]>
Date: Fri, 4 Aug 2017 10:03:42 +0000

> On 4 Aug 2017, at 09:42, DY Kim <[email-masked]> wrote:
> 

That would be a reasonable issue to discuss in the security considerations of draft-ietf-v6ops-unique-ipv6-prefix-per-host.

> For enough randomization in that case, I might like to have enough (say 48) additional bits for the node prefix, rendering 48+48=96; 48 is shorter than 64, but should be large enough for randomizat…

That’s off piste for this draft. And a discussion already thrashed out in other threads, and also discussed in RFC7421.

Tim

---

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 4 Aug 2017 10:25:56 +0000

As long as the router facing the end points is able to transmit a unique prefix per host in the RA then both of the cases below will work.

John
+1-484-962-0060

From: v6ops <[email-masked]> on behalf of DY Kim <[email-masked]>
Date: Thursday, August 3, 2017 at 21:39
To: v6ops <[email-masked]>
Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

---
DY

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Date: 31 July 2017 at 16:00:57 GMT+9
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Aug 2017 20:45:21 +1000

On 4 Aug. 2017 8:03 pm, "Tim Chown" <[email-masked]> wrote:

> Now that a device (can I say ‘node’?) trackable by its (/64) unique
prefix, the privacy of the node might be compromised.
>
> To combat this, you might want to regularly randomize/refresh the prefix
for a given node to secure privacy from eavesdroppers, except that the
privacy is not secured to the entity distributing the prefixes.

That would be a reasonable issue to discuss in the security considerations
of draft-ietf-v6ops-unique-ipv6-prefix-per-host.

I think Fred Baker wrote a draft a while back  that suggested randomising
subnets with a site level /48 to mitigate that, so a reference to that
could be useful.

Relatedly, I've thought that those using /127s should be randomising some
or all of the bits between /127 and the likely single /64 they're assigning
the /127s out of.

Regards,
Mark.

> For enough randomization in that case, I might like to have enough (say
48) additional bits for the node prefix, rendering 48+48=96; 48 is shorter
than 64, but should be large enough for randomization for privacy.

That’s off piste for this draft. And a discussion already thrashed out in
other threads, and also discussed in RFC7421.

Tim

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 19:49:32 +0900

OK.

--------
Regards,
DY

> On 4 Aug 2017, at 19:03, Tim Chown <[email-masked]> wrote:
> 
>>

---

From: DY Kim <[email-masked]>
Date: Fri, 4 Aug 2017 19:51:37 +0900

Thanks.

--------
Regards,
DY

> On 4 Aug 2017, at 19:25, Brzozowski, John <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Aug 2017 08:58:47 -0500

I don't see how whole subnet or prefix assigned to just a single host is
incompatible with with RFC4291 or RFC4291bis in any way.

That said there was some discussion of adding a reference to RFC7934 - Host
Address Availability Recommendations, which introduces the concept of
assigning a whole /64 to an individual host.  I think its still think that
is a good idea, and maybe adding a reference to this would be a good idea
too. It does represent a bit of an evolution in the subnet model.

But, again I don't see how it is incompatible with ether RFC4291 or
RFC4291bis

On Fri, Aug 4, 2017 at 3:56 AM, DY Kim <[email-masked]> wrote:

> Although 'draft-ietf-v6ops-unique-ipv6-prefix-per-host’ is not meant to
> change the standard 4291bis, isn’t that in conflict with 4291bis in that
> the draft uses a notion not defined in the parent standard.
>
> --------
> Regards,
> DY
>
>
>
>
>
>
>
>

-- 
===============================================
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: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 02:49:21 +0900

in line...

—-
DY

> On 4 Aug 2017, at 22:58, David Farmer <[email-masked]> wrote:
> 
> I don't see how whole subnet or prefix assigned to just a single host is incompatible with with RFC4291 or RFC4291bis in any way.

Subnet, to my understanding, is a shared network comprising of a collection of hosts managed (bordered) by one or more routers. A subnet prefix is one assigned to the whole subnet wherein all hosts share the same prefix.

When each host in such a share network (subnet) is assigned a unique prefix (and hosts don’t share the same prefix), that prefix is not a subnet prefix and should be name differently, say, ‘host prefix’ or ‘node prefix’.

RFC4291bis defines (comments) only the subnet prefix. The draft of this thread title deals with a prefix type not defined (commented) in the RFC4291bis (to-be-)standard. In that, the draft under discussion in this thread could be said ‘not in compliance with’ the RFC4291bis.

This is my logic. Odd yet?

> That said there was some discussion of adding a reference to RFC7934 - Host Address Availability Recommendations, which introduces the concept of assigning a whole /64 to an individual host.  I think its still think that is a good idea, and maybe adding a reference to this would be a good idea too. It does represent a bit of an evolution in the subnet model.

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 02:57:46 +0900

Konglish…

>> consisting of

---
DY

> On 5 Aug 2017, at 02:49, DY Kim <[email-masked]> wrote:
> 
> comprising of

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Aug 2017 13:15:12 -0500

On Fri, Aug 4, 2017 at 12:49 PM, DY Kim <[email-masked]> wrote:

> Subnet, to my understanding, is a shared network comprising of a
> collection of hosts managed (bordered) by one or more routers. A subnet
> prefix is one assigned to the whole subnet wherein all hosts share the same
> prefix.
>
> When each host in such a share network (subnet) is assigned a unique
> prefix (and hosts don’t share the same prefix), that prefix is not a subnet
> prefix and should be name differently, say, ‘host prefix’ or ‘node prefix’.
>
> RFC4291bis defines (comments) only the subnet prefix. The draft of this
> thread title deals with a prefix type not defined (commented) in the
> RFC4291bis (to-be-)standard. In that, the draft under discussion in this
> thread could be said ‘not in compliance with’ the RFC4291bis.
>

Well, RFC4291 is quite clear there can be more than one subnet per link,
there might be practical limits on how may subnet you can have on a link
but there is no theoretical limit that I'm aware of.  Furthermore, Wifi or
other link technology will probably reach congestion collapse before you
reach such limits on a modern router.  While it is common for a router to
have an address in the subnet this is not required, the host can just use
the router's link-local address, and if the router is learned form RAs
using the link-local address is the normal mode of operation anyway. Also,
it's common for subnets to have more than one host again nothing requires
this either.

So, this isn't what most people will think of when they read RFC4291, but
your only running afoul of people's assumptions not the specification
itself. Therefore, bring this up might be a good idea for RFC4291bis,
principle of least astonishment and all, but not absolutely necessary.

---

From: Gert Doering <[email-masked]>
Date: Fri, 4 Aug 2017 22:38:21 +0200

Hi,

> boundary for almost 20 years since RFC2373.

Is "a host having many IPv6 addresses" a *subnet* in the usual sense
here?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 05:43:33 +0900

inline...

---
DY

> On 5 Aug 2017, at 03:15, David Farmer <[email-masked]> wrote:
> 
> Well, RFC4291 is quite clear there can be more than one subnet per link

Clear? Where?

Let’s assume what you say is correct and hence ‘link’ and ‘subnet’ are totally different things.

Hosts on a subnet acquire the subnet prefix from RA. All hosts on the same subnet gets the same common prefix; well eligible to be called ’subnet prefix’. Hosts generate interface addresses through SLAAC, by generating IID independently. That’s why we need DAD for no collision of the interface addresses, or equivalently, of the IIDs on the same subnet.

With the draft under discussion, however, each host gets a unique prefix, different from those of others. And hence, there’s no worry of address collision, so that DAD is not necessary in this case. What do we call then the prefix unique to each host in this case? Should we continue call that 'subnet prefix', with the consequence that we should then be dealing with multiple subnet prefixes for the same subnet?

I’d think that’s an odd naming, and the prefix unique to each host should best be called ‘host prefix’ or ‘node prefix’.

Now that neither ‘host prefix’ nor ‘node prefix’ is defined in rfc4291bis, wherein only the subnet prefix is defined, the current draft is using an address-related terminology not defined in the address architecture standard.

In this sense, the current draft could be said not to be compliant with the address architecture standard.

I’m not sure of the IETF culture, but terminology/nomenclature is ultimately important in dealing with standards.

I’m not at all against the draft under discussion. On the contrary, I like this draft very much.

To resolve the conflict, if any change has to take place, I’d think it should be with rfc 4291bis, very unfortunately. That is, this text in rfc4291bis

   |          n bits               |           128-n bits            |

might better be changed to

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |          prefix               |           interface ID          |
   +-------------------------------+————————————————-----------------+

> , there might be practical limits on how may subnet you can have on a link but there is no theoretical limit that I'm aware of.  Furthermore, Wifi or other link technology will probably reach congestion collapse before you reach such limits on a modern router.  While it is common for a router to have an address in the subnet this is not required, the host can just use the router's link-local address, and if the router is learned form RAs using the link-local address is the normal mode of operation anyway. Also, it's common for subnets to have more than one host again nothing requires this either.
> 
> So, this isn't what most people will think of when they read RFC4291, but your only running afoul of people's assumptions not the specification itself. Therefore, bring this up might be a good idea for RFC4291bis, principle of least astonishment and all, but not absolutely necessary.

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Aug 2017 16:02:44 -0500

> > Well, RFC4291 is quite clear there can be more than one subnet per link

Read Section 2.1 of RFC4291, multiple subnets per link in in the last
paragraph of that section.

> Hosts on a subnet acquire the subnet prefix from RA. All hosts on the same
> subnet gets the same common prefix; well eligible to be called ’subnet
> prefix’. Hosts generate interface addresses through SLAAC, by generating
> IID independently. That’s why we need DAD for no collision of the interface
> addresses, or equivalently, of the IIDs on the same subnet.
>
> With the draft under discussion, however, each host gets a unique prefix,
> different from those of others. And hence, there’s no worry of address
> collision, so that DAD is not necessary in this case. What do we call then
> the prefix unique to each host in this case? Should we continue call that
> 'subnet prefix', with the consequence that we should then be dealing with
> multiple subnet prefixes for the same subnet?
>
> I’d think that’s an odd naming, and the prefix unique to each host should
> best be called ‘host prefix’ or ‘node prefix’.
>

There are lots of links with only one hosts, at least at some point in its
life cycle, are you saying that a subnet prefix isn't a subnet until the
second host shows up?

Now that neither ‘host prefix’ nor ‘node prefix’ is defined in rfc4291bis,
> wherein only the subnet prefix is defined, the current draft is using an
> address-related terminology not defined in the address architecture
> standard.
>
> I’m not sure of the IETF culture, but terminology/nomenclature is
> ultimately important in dealing with standards.
>
> To resolve the conflict, if any change has to take place, I’d think it
> should be with rfc 4291bis, very unfortunately. That is, this text in
> rfc4291bis
>
>    |          n bits               |           128-n bits            |

For a whole bunch of other reasons I'd be just fine with that suggestion, I
think the term subnet brings a who bunch of IPv4 baggage that is really
complicating other part of the RFC4291bis conversations. I'm all for
banishing the term subnet from RFC4291bis, except when comparing to an IPv4
subnet.

> > , there might be practical limits on how may subnet you can have on a
> link but there is no theoretical limit that I'm aware of.  Furthermore,
> Wifi or other link technology will probably reach congestion collapse
> before you reach such limits on a modern router.  While it is common for a
> router to have an address in the subnet this is not required, the host can
> just use the router's link-local address, and if the router is learned form
> RAs using the link-local address is the normal mode of operation anyway.
> Also, it's common for subnets to have more than one host again nothing
> requires this either.
> >
> > So, this isn't what most people will think of when they read RFC4291,
> but your only running afoul of people's assumptions not the specification

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 06:08:19 +0900

It’s not ‘multiple subnets per link’, but ‘multiple subnet prefixes per link’.

  "Multiple subnet prefixes may be assigned to the same link.”

---
DY

> On 5 Aug 2017, at 06:02, David Farmer <[email-masked]> wrote:
> 
> Read Section 2.1 of RFC4291, multiple subnets per link in in the last paragraph of that section.

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 06:09:51 +0900

You seem to be mixed up between subnet and subnet prefix.

---
DY

> There are lots of links with only one hosts, at least at some point in its life cycle, are you saying that a subnet prefix isn't a subnet until the second host shows up?

---

From: DY Kim <[email-masked]>
Date: Sat, 5 Aug 2017 06:10:53 +0900

We agree at least on one point.. :-).

---
DY

> I think the term subnet brings a who bunch of IPv4 baggage that is really complicating other part of the RFC4291bis conversations. I'm all for banishing the term subnet from RFC4291bis, except when comparing to an IPv4 subnet.

---

From: David Farmer <[email-masked]>
Date: Fri, 4 Aug 2017 16:14:26 -0500

I might have be talking a little loosely, but you seem to see more
significance in the difference than I do.

On Fri, Aug 4, 2017 at 4:09 PM, DY Kim <[email-masked]> wrote:

> > There are lots of links with only one hosts, at least at some point in
> its life cycle, are you saying that a subnet prefix isn't a subnet until
> the second host shows up?
>
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 5 Aug 2017 01:48:30 +0000

I host on a VLAN can have multiple addresses which does not indicate that the host has the entire subnet or prefix.

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of Gert Doering <[email-masked]>
Date: Friday, August 4, 2017 at 16:38
To: Mark Smith <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

    Hi,

    
    Gert Doering
            -- NetMaster

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 5 Aug 2017 01:49:41 +0000

A host, not I host, on a VLAN…

John
+1-484-962-0060

-----Original Message-----
From: v6ops <[email-masked]> on behalf of "Brzozowski, John" <[email-masked]>
Date: Friday, August 4, 2017 at 21:48
To: Gert Doering <[email-masked]>, Mark Smith <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

    John
    +1-484-962-0060
    
    -----Original Message-----
    From: v6ops <[email-masked]> on behalf of Gert Doering <[email-masked]>
    Date: Friday, August 4, 2017 at 16:38
    To: Mark Smith <[email-masked]>
    Cc: v6ops <[email-masked]>
    Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
    
        Hi,

        
        Gert Doering
                -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 5 Aug 2017 09:20:40 +0200

Hi,

> I host on a VLAN can have multiple addresses which does not indicate that the host has the entire subnet or prefix.

I was talking about "we route a full /96 to a host, and the host can make
use of all of the addresses in that subnet" case, where Mark argued that
"a subnet must be a /64!".

Gert Doering
        -- NetMaster

---

From: Simon Hobson <[email-masked]>
Date: Sat, 5 Aug 2017 10:58:37 +0100

> https://tools.ietf.org/rfc/rfc7421.txt

I'll make an observation that one of the primary reasons given is the now deprecated EUI64 addressing model for SLAAC.
Also there is mention of "but there sooooo many addresses, we can't possibly run out". I don't have a crystal ball, in much the same way that all those decades ago, those designing IPv4 didn't have a crystal ball.

So it appears to me that the basis of a fixed /64 comes down to :

1) A now deprecated addressing method requires it
2) Based on what we know now we can't see things ever running out
3) If any but /64 is used, then some things (implementations) may break.

So isn't the logical route to say that all implementations must support arbitrary prefix lengths - that avoids breakage when (and I suspect in the real world it will be when, rather than if) they meet something other than /64 ?
Something that handles arbitrary prefix lengths can handle 64+64, the reverse isn't true if it expects 64+64 and is thrown something else.

That and removing references to fixed 64 bit boundaries where they aren't necessary. Noting that allowing plenty of space for randomisation for security by obscurity isn't a technical limitation as such - it's merely a best practice.

And finally. There has been mention in here in the past about not preventing flexibility in the future with things no-one has yet thought of. Yes the numbers are huge, but as I said, I don't have a crystal ball.

And the argument about not having to work out prefixes/masks/etc is only partly true - and assumes that no-one would ever have to work with anything but /64. It could well lead to people who CANNOT work with anything else, in the same way that many people cannot work with anything but /24 in the IPv4 world.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Aug 2017 08:16:42 +1200

>> https://tools.ietf.org/rfc/rfc7421.txt

Which says:
"The first purpose of this document is to explain the
advantages of the fixed IID length.  Its second purpose is to
analyze, in some detail, the effects of hypothetically varying the
IID length."

I suggest that everybody reads the whole RFC, which does indeed
cover those points. The historical reasons why we chose 64 are
somewhat irrelevant today.

    Brian

---

From: DY Kim <[email-masked]>
Date: Sun, 6 Aug 2017 08:40:01 +0900

The firm reference pole

	RFC7421

along with a number of docs prescribing 64 bits for the IID length

	RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072
	(thanks to Tatuya Jinmei for the list)

would be enough to ensure that

	SLAAC will accept only 64-bit long prefixes
		and produce 64-bit long IIDs.

not to disturb the wide deployment of SLAAC implementation as such.

RFC4291bis doesn’t need (or even ought not to, for it's about ‘architecture’) mention or mandate the length of IID, leaving such implementation specific details to companion docs like those listed above.

---
DY

> On 6 Aug 2017, at 05:16, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Aug 2017 12:19:03 +1000

I give up. Do what you like, treat sand like diamonds.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Aug 2017 15:21:53 +1200

> I give up. Do what you like, treat sand like diamonds.

I thought "Mark's exaggerating", but no, he isn't. There's a reasonable
estimate of 5.6x10^21 grains of sand on the Earth's beaches:

http://www.quickanddirtytips.com/education/math/how-many-grains-of-sand-are-on-earth%E2%80%99s-beaches

In the address space already available to IANA, we have 35x10^12 /48s (in 2000::/3)**.

That allows for 2.3x10^18 /64s (in 2000::/3).

To count the available /128s, multiply again by 18x10^18.

Or to put it another way, with only about 2430 addresses per /64 subnet,
and 2.3x10^18 subnets, we could address every grain of sand. With that
degree of sparseness, DAD will hardly blink and the grains of sand can
feel sure of their privacy, if they care to use RFC4941.

If there's a problem, it's not in the area of a shortfall of /128s.
If there's a shortfall of /64s, it's human error.

   Brian

** Powers of 2 are at https://en.wikipedia.org/wiki/Power_of_two#The_0th_through_95th_powers_of_two

---

From: Simon Hobson <[email-masked]>
Date: Sun, 6 Aug 2017 15:53:24 +0100

> estimate of 5.6x10^21 grains of sand on the Earth's beaches:

Ah, that's what that's about.

> That allows for 2.3x10^18 /64s (in 2000::/3).

Which is all fascinating given that ISPs generally hand out /48 or smaller - and we hear of some providing only a small number of /64s.
By the same reasoning, there's trillions of money around - so I should have no problem having a Ferrari on the drive ;-) It's not any help that there are so many addresses around if they aren't available to me.

In reality, if the ISP hands out a /48 then there are 2^80 addresses there. Now we go and constrain that (by continued insistence on "there shalt be no other allocation than /64") such that there are now only 2^16 available prefixes - but that assumes the entire /48 is available for such allocation. As I pointed out, by the time you have allowed for multiple sites, multiple networks, you might only have 2^8 prefixes - thus making the address space for tracking hosts quite small.

Now if you can make a case for a single host to have 2^64 addresses available to it then there's validity in not relaxing the /64 requirement - but I can't help thinking that that would be a hard case to make.

> If there's a shortfall of /64s, it's human error.

In theory yes, but meanwhile, back in the real world ...

---

From: Sander Steffann <[email-masked]>
Date: Sun, 6 Aug 2017 20:24:34 +0200

Hi Simon,

> In reality, if the ISP hands out a /48 then there are 2^80 addresses there. Now we go and constrain that (by continued insistence on "there shalt be no other allocation than /64") such that there are now only 2^16 available prefixes - but that assumes the entire /48 is available for such allocation. As I pointed out, by the time you have allowed for multiple sites, multiple networks, you might only have 2^8 prefixes

Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 to a customer and then divide it over the connections ("sites") that that customer has. It far more convenient for everybody to just give each connection/site a separate /48. And business-ISP really shouldn't give any customer any less.

Cheers,
Sander

---

From: Simon Hobson <[email-masked]>
Date: Sun, 6 Aug 2017 21:42:32 +0100

> Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 to a customer and then divide it over the connections ("sites") that that customer has. It far more convenient for everybody…

What about businesses with multiple sites (or even, just multiple buildings on a large site), connected by leased lines or whatever, and one central internet connection ? It's not that uncommon. Some time ago (different job) I managed a network with 45 sites and only one internet connection - 40 of them were retail outlets, using dial on demand ISDN, and the ONLY networking they had was back to head office for PoS systems. OK, not typical, but as I say, not all that rare either.
These days it would be mostly done with DSL lines and VPNs - but we'd still not be allowing local use of the internet connection at each store.

As I've been pointing out - there are comments along the lines of "we must not block future innovation". Yet at the same time there are limitation being hardcoded in that do exactly that. Just think about it, even if the entire /48 is used on one network, then that only gives 16 bits for host selection - with 60+ bits "wasted". While at the same time there are those saying that anything less than 64 bits to pick an address from is inadequate.

---

From: David Farmer <[email-masked]>
Date: Mon, 7 Aug 2017 01:08:41 -0500

On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson <[email-masked]> wrote:

> > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48
> to a customer and then divide it over the connections ("sites") that that
> customer has. It far more convenient for everybody to just give each
> connection/site a separate /48. And business-ISP really shouldn't give any
> customer any less.
>
> What about businesses with multiple sites (or even, just multiple
> buildings on a large site), connected by leased lines or whatever, and one
> central internet connection ? It's not that uncommon. Some time ago
> (different job) I managed a network with 45 sites and only one internet
> connection - 40 of them were retail outlets, using dial on demand ISDN, and
> the ONLY networking they had was back to head office for PoS systems. OK,
> not typical, but as I say, not all that rare either.
> These days it would be mostly done with DSL lines and VPNs - but we'd
> still not be allowing local use of the internet connection at each store.
>
> As I've been pointing out - there are comments along the lines of "we must
> not block future innovation". Yet at the same time there are limitation
> being hardcoded in that do exactly that. Just think about it, even if the
> entire /48 is used on one network, then that only gives 16 bits for host
> selection - with 60+ bits "wasted". While at the same time there are those
> saying that anything less than 64 bits to pick an address from is
> inadequate.
>

This discussion seem to be rapidly spinning out of the IETF's preview, but
it is still important. I think the RIR assignment and allocation policies
aren't as stingy as some might think.  Organizations with multiple sites
should not be limited to only a /48, in fact /48 is really just the staring
point, at least in the ARIN region /44s and /40s are not that difficult to
justify for most organizations.

ARIN's policy explicitly allows the assignment of a /48 for each site of a
multi-site end-user, either by an ISP or directly by ARIN (if one of
several qualifications is meet by the end-user), further additional /48s
per site can be assigned if 16,384 /64 subnets are used in an single
x-large site.  However, the policy is really a ceiling for ISPs, and ISPs
are free to assign less if they see fit. Also, it could very well be the
case that if an end-user has multiple sites behind a single connection to
an ISP, the ISP might not realize the end-user has multiple site unless the
end-user requests a block larger than /48. It seems quit logical for an ISP
to assume a connection is just one site, unless the customer informs them
otherwise.

ARIN's IPv6 end-user policy;
https://www.arin.net/policy/nrpm.html#six58

The follow allow ISPs or LIRs to make IPv6 assignment based on the above
end-user policy;
https://www.arin.net/policy/nrpm.html#six54

On the other hand as I have been listening to this discussion, and I've
become a little concerned that some may think this new model of a /64 per
host should replace or obsolete the more traditional subnet model of
multiple hosts within a subnet for any and all use cases. However, it
should be noted that the primary use case for this model is public internet
access, or public WiFi. There are several arguments that the traditional
subnet model has always been a bad fit for this use case, in that you end
up mixing totally unrelated users and hosts on the same subnet, there are
several security and privacy issues with that. This isn't necessarily true
of other use cases.

So, the /64 prefix per host model solves some important problems for this,
and maybe other use cases too. But, that doesn't mean it should be viewed
as a universal replacement for the traditional multiple host per subnet
model for all use cases we have. There are plenty of use cases left where
traditional multiple host per subnet model still works just fine.

Thanks.

---

From: Tim Chown <[email-masked]>
Date: Mon, 7 Aug 2017 10:05:23 +0000

Hi,

> On 7 Aug 2017, at 07:08, David Farmer <[email-masked]> wrote:
> 
> This discussion seem to be rapidly spinning out of the IETF's preview, but it is still important. I think the RIR assignment and allocation policies aren't as stingy as some might think.  Organizations with multiple sites should not be limited to only a /48, in fact /48 is really just the staring point, at least in the ARIN region /44s and /40s are not that difficult to justify for most organizations. 

Two UK universities have a /44 due to their internal organisation.

> ARIN's policy explicitly allows the assignment of a /48 for each site of a multi-site end-user, either by an ISP or directly by ARIN (if one of several qualifications is meet by the end-user), further additional /48s per site can be assigned if 16,384 /64 subnets are used in an single x-large site.  However, the policy is really a ceiling for ISPs, and ISPs are free to assign less if they see fit. Also, it could very well be the case that if an end-user has multiple sites behind a single connection to an ISP, the ISP might not realize the end-user has multiple site unless the end-user requests a block larger than /48. It seems quit logical for an ISP to assume a connection is just one site, unless the customer informs them otherwise.
> 
> The follow allow ISPs or LIRs to make IPv6 assignment based on the above end-user policy;
> On the other hand as I have been listening to this discussion, and I've become a little concerned that some may think this new model of a /64 per host should replace or obsolete the more traditional subnet model of multiple hosts within a subnet for any and all use cases. However, it should be noted that the primary use case for this model is public internet access, or public WiFi. There are several arguments that the traditional subnet model has always been a bad fit for this use case, in that you end up mixing totally unrelated users and hosts on the same subnet, there are several security and privacy issues with that. This isn't necessarily true of other use cases.
> 
> So, the /64 prefix per host model solves some important problems for this, and maybe other use cases too. But, that doesn't mean it should be viewed as a universal replacement for the traditional multiple host per subnet model for all use cases we have. There are plenty of use cases left where traditional multiple host per subnet model still works just fine.

The question though, as and as you say it’s not one really in the IETF’s scope, more the RIR communities, is if a site has a /48, and uses it up (or 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-per-host, will that be deemed appropriate use to allow a further assignment?

A large university may choose to implement this on its wifi/eduroam, for example.

Tim

---

From: Simon Hobson <[email-masked]>
Date: Mon, 7 Aug 2017 11:26:21 +0100

> A large university may choose to implement this on its wifi/eduroam, for example.

Presumably that means another separate prefix. And when 2003:: is used, 2004:: will get allocated and so on.
At what point will people be suggesting that we could have avoided the routing table bloat by allowing better use of the prefixes ?

AFAICS the insistence that it must be /64 per host, rather than anything else (eg /80/host or /96/host) seems to be more religion than technical requirement.
I can see the security (through obscurity) and privacy reasons why individual addresses should come from a /64 (or at least, large) prefix - but I fail to see much, if any, merit in allocating 2^64 addresses to a single host "because we can".

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Aug 2017 12:34:48 +0200 (CEST)

On Mon, 7 Aug 2017, Tim Chown wrote:

> The question though, as and as you say it’s not one really in the IETF’s 
> scope, more the RIR communities, is if a site has a /48, and uses it up 
> (or 16,384 /64s of it up) implementing 
> draft-ietf-v6ops-unique-ipv6-prefix-per-host, will that be deemed 
> appropriate use to allow a further assignment?

If a RIR deems this not appropriate use, I will personally engage the 
policy development groups of these RIRs, advocating change to the policy.

I don't think I'll be alone.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Aug 2017 12:35:25 +0200

My take on this.

Most of the RIR policies allow a shorter prefix than /48 for a single site if justified. As Tim said, there are already examples of /44 and I’ve seen others (/47).

If you are using a single /64 per host, and furthermore an IETF RFC documents it, a RIR policy can’t block it. In the worst case, a RIR policy can always be modified by the community, and I think this can happen in general in less than 4-6 months in most of the regions, looking at most of the PDP process overall length.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Tim Chown <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 7 de agosto de 2017, 12:05
Para: David Farmer <[email-masked]>
CC: Simon Hobson <[email-masked]>, v6ops list <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

    Hi,

    

    
    Tim

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Aug 2017 12:48:38 +0200 (CEST)

> Presumably that means another separate prefix. And when 2003:: is used, 2004:: will get allocated and so on.

We have 2000::-3fff:: to get this right. If we deem that we're now wasting 
addresses, we'll have to come up with different policy for 4000::-5fff::: 
(the next /3.

> At what point will people be suggesting that we could have avoided the 
> routing table bloat by allowing better use of the prefixes ?

Routing table bloat happens because the allocated prefixes at the higher 
level are too small, not because they're too big.

If someone spends their /29 then next time we should give them a 
significantly larger prefix to avoid routing table bloat.

RIPE at least allocates a 8 times the size of your initial allocation off 
the bat, so anyone going to them saying "I have a million customers and I 
want to give each a /48" should receive a /28 or a /27, with a /25 
reserved for growth for them (in case they did receive a /28). This is to 
avoid routing table bloat.

> I can see the security (through obscurity) and privacy reasons why 
> individual addresses should come from a /64 (or at least, large) prefix 
> - but I fail to see much, if any, merit in allocating 2^64 addresses to 
> a single host "because we can".

It's /64 because we can't agree on a smaller size that makes sense to 
everybody, that at the same time isn't too small. I wouldn't call it 
religion, but I would call it "healthy sceptisism about what might happen 
otherwise".

Today a non-trivial amount of ISPs hand out /64 to residential users, 
probably because they they reason that a site is a single subnet. If we 
allowed /80, what stops them handing out /80? Or /79, because, why not?

I kind of like having this hard limit, it means there is reasonable 
expectation just by looking at the address that "this is a subnet", 
without having to know the remote end addressing policy. Sure there could 
be multiple customers within that /64, but we should drive towards having 
fewer customers sharing the same /64, as opposed to the other way around.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Aug 2017 13:07:46 +0200

Hi,

On Mon, Aug 07, 2017 at 12:35:25PM +0200, JORDI PALET MARTINEZ wrote:
> Most of the RIR policies allow a shorter prefix than /48 for a single site 
> if justified. 

"If justified" has traditionally been along the lines of "number of buildings,
number of subnets, number of aggregation levels", so, number of *networks*.

"Number of hosts" has not been a justification argument in (at least)
RIPE IPv6 policy, so that would be a fairly significant change.

Personally, I would be very careful here - permitting assignments of 
larger address blocks because we *waste* a /64 on a potentially very 
large number of hosts in a network might cause shortage further up.

And yes, I think this is extremely wastive, well over the limits of what
is normal "do not care about wasting addresses!" level of IPv6 normal.

On a subnet, having a "it is big enough for everything, no matter how
many hosts" is a desirable property because it makes network planning much
easier - single size fits all, focus on more interesting work.  A /64
is already excessive here, but given that the number of subnets is
bound by factors like "how many different purposes can you come up
with?", "router config", etc.  I'm willing to accept a /64 here.

A /64 per *host* is much less bound - while far beyond anything you can
configure on that host, so the trade-off "waste vs. useful number of bits"
is not reasonable for me.

Should this topic come up in RIPE policy discussion, I'll chair the
discussion and refrain from having an opinion, but will reserve the right 
for a "told you so" later.

Gert Doering
        -- RIPE APWG chair

---

From: Sander Steffann <[email-masked]>
Date: Mon, 7 Aug 2017 13:21:05 +0200

Hi,

> is not reasonable for me.

I agree. Sticking to /64 for subnets is fine. Delegating prefixes to hosts is also fine, but they don't have to (shouldn't) be /64. A /96 per host sounds about right. When acting as a router (connection sharing, running VMs etc) the need for separate subnets (= /64s) comes back, but for individual host behaviour a /96 should be fine.

> for a "told you so" later.

:-)
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Aug 2017 13:34:49 +0200 (CEST)

On Mon, 7 Aug 2017, Sander Steffann wrote:

> I agree. Sticking to /64 for subnets is fine. Delegating prefixes to 
> hosts is also fine, but they don't have to (shouldn't) be /64. A /96 per 
> host sounds about right. When acting as a router (connection sharing, 
> running VMs etc) the need for separate subnets (= /64s) comes back, but 
> for individual host behaviour a /96 should be fine.

Our problem is that we can't tell which is which.

The laptop I show up at IETF meeting with normally has its own host stack, 
plus at least 2 other VMs running, sometimes more.

How should the network differentiate me from "just a single host" when I 
connect to the IETF wifi?

---

From: Sander Steffann <[email-masked]>
Date: Mon, 7 Aug 2017 13:37:09 +0200

Hi,

> How should the network differentiate me from "just a single host" when I connect to the IETF wifi?

Your laptop should know :-)  It could ask for a /96 or a /64 with DHCPv6-PD.  Or the laptop can ask for a /96 for itself and your virtualisation software can ask for its own /64. It even gives you a nice separation of responsibilities.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 7 Aug 2017 13:40:05 +0200 (CEST)

On Mon, 7 Aug 2017, Sander Steffann wrote:

> Your laptop should know :-)  It could ask for a /96 or a /64 with 
> DHCPv6-PD.  Or the laptop can ask for a /96 for itself and your 
> virtualisation software can ask for its own /64. It even gives you a 
> nice separation of responsibilities.

Please see me posts from thursday regarding G-5 requirement in 7084 where 
I describe why DHCPv6-PD is a bad fit for this use-case.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Aug 2017 13:53:41 +0200

Hi,

> connect to the IETF wifi?

DHCPv6-PD comes to mind...  as the next person to speak up will want
a routed setup with many layers in their VM stack on their laptop, 
"something with routed subnets" is (obviously) needed.

Otherwise, you're back to "your VM stack needs to do bridging", which
they notoriously cannot get right for the generic "bridging to wifi"
case.

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Mon, 7 Aug 2017 12:49:05 +0000

> On 7 Aug 2017, at 12:53, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

The draft describes RA-based provision, with /64 as “current” practice.  There’s more detail in the original non-WG version - draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00

There was pushback on DHCP-PD for hosts in the RFC6434-bis discussion, and DHCP-PD is not mentioned in this draft.

Tim

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 Aug 2017 15:06:54 +0200

Hi,

> There was pushback on DHCP-PD for hosts in the RFC6434-bis discussion, and DHCP-PD is not mentioned in this draft.

I'm aware of that, and of course, DHCPv6 is the worst protocol on earth.

My point could be reworded as "you need some mechanism to tell the network
what your host wants" - because whatever generic mechanism we devices that
will handle all the superspecialcase variants of "I have a complete ISP
with many levels of prefix delegation running as VMs on my routers" will
excercise pressure on the "how many /64 prefixes can we afford to keep around
for a single wifi pool?" side.

To do some reality check.

My laptop usually wants *one* IPv6 address, which better should not change
while it's attached (because it would break my SSH sessions).

If I happen to run VMs, each VM needs one IPv6 address - which didn't work
last time at all because vmware had issues bridging IPv6 to wifi (so I
used NATted IPv4 instead).

Even with all VMs I have on my laptop, I do not expect that I will ever need 
a /64 on it.

A /120 would be perfectly fine today, a /96 would be extremely spacious.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Aug 2017 15:07:18 +0200

I’m not saying that this will apply to “every” site, and I guess that in most of the cases, if they have already a /48, they may want to use part of it the way is described in this document, not necessarily the complete /48. For example, from the /48, you may be using a /56 in a data center which has servers with tons of VMs.

So the difficulty here is to find the way to justify those cases that really need this, if there are cases that need, for example instead of a /48, a /47, /46 or /44, etc.

Regards,
Jordi

-----Mensaje original-----
De: Gert Doering <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 7 de agosto de 2017, 13:07
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: v6ops list <[email-masked]>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

    Hi,

    

    

    
    Gert Doering
            -- RIPE APWG chair

---

From: DY Kim <[email-masked]>
Date: Tue, 8 Aug 2017 01:00:31 +0900

+1.

With a /96, you still have 2^32 addresses to give out to your VMs, virtually the size of the whole Internet IPv4 could accommodate.

A /64 prefix and so 2^64 addresses at your (unsolicited) disposal would be way high and so high even to make yourself guilty of unethical resource consumption.

---
DY

> On 7 Aug 2017, at 22:06, Gert Doering <[email-masked]> wrote:
> 
> a /96 would be extremely spacious.

---

From: David Farmer <[email-masked]>
Date: Mon, 7 Aug 2017 11:21:27 -0500

On Mon, Aug 7, 2017 at 5:05 AM, Tim Chown <[email-masked]> wrote:

> > So, the /64 prefix per host model solves some important problems for
> this, and maybe other use cases too. But, that doesn't mean it should be
> viewed as a universal replacement for the traditional multiple host per
> subnet model for all use cases we have. There are plenty of use cases left
> where traditional multiple host per subnet model still works just fine.
>
> scope, more the RIR communities, is if a site has a /48, and uses it up (or
> 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-per-host,
> will that be deemed appropriate use to allow a further assignment?
>

I don't think dedicating a /48 or even a few /48s for wifi/eduroam at a
large University would be a waste of address space.  I'll use our network
here at UMN Twin Cites as an example, we have almost 65,000 staff,
students, and faculty, with many thousands of visitors on a daily basis,
and many people have multiple devices.

We had almost 80,000 unique devices on WiFi for first day of classes last
year, Fall of 2016, across the the whole day, but only somewhere around
20,000 to 30,0000 devices at any moment. We expect that to be more like
100,000 first day of classes this year, in about a month. So a couple /48s
seems like more than enough, maybe growing to 3 or 4 over the next few
years.  However, reuse of addresses as users come and go creates additional
privacy for individual users, so we don't want too large of a pool either.
Maybe forcing the use of a new prefix overnight for devices that are
continuously on campus.  We currently use a few dozen /64 subnets for WiFi,
and we have some issues with ND scaling in our environment. So we are
eagerly awaiting our WiFi gear and routers supporting this model.

I think we need to be careful, and keep an eye on this over the next few
years, but I think there is still plenty of IPv6 address space available in
2000::/3. This shouldn't be used as excuse to totally eliminate traditional
multiple host per subnet model, but I don't see it as an excuse to
eliminate /64 subnet model either.

Thanks.

---

From: james woodyatt <[email-masked]>
Date: Mon, 7 Aug 2017 11:13:52 -0700

On Aug 5, 2017, at 20:21, Brian E Carpenter <[email-masked]> wrote:
> 
> […] If there's a problem, it's not in the area of a shortfall of /128s.

This is where I point out that diamonds, unlike grains of sand, are just sufficiently uncommon that monopoly power admits the inducement of artificial scarcity to inflate market prices. 

> If there's a shortfall of /64s, it's human error.

There is more to the analogy than meets the eye, i.e. the error may be one of political and economic philosophy, and not a technical one, and moreover, the analogy may break down around the ways that numbers are not the same as stones. After all, if the point of the game is to create an artificial scarcity of numbers, what difference does it make where you put the prefix boundary in the process? You can set it anywhere you like and achieve the same effect.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Aug 2017 08:11:33 +1200

> There is more to the analogy than meets the eye, i.e. the error may be one of political and economic philosophy, and not a technical one, and moreover, the analogy may break down around the ways th…

Exactly correct. As engineers who care about making the Internet work better, we should certainly work to avoid artificial scarcity, having created IPv6 to overcome a real scarcity. But *we* can't actually prevent intentional creation of artificial scarcity - that's an economic and fair trade issue which will play out in RIR policy and beyond.

> traditional multiple host per subnet model still works just fine.

There's nothing wrong with either model and they will both find their place in the market.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Aug 2017 11:52:46 +1000

On 8 August 2017 at 04:13, james woodyatt <[email-masked]> wrote:
> This is where I point out that diamonds, unlike grains of sand, are just
> sufficiently uncommon that monopoly power admits the inducement of
> artificial scarcity to inflate market prices.
>
> There is more to the analogy than meets the eye, i.e. the error may be one
> of political and economic philosophy, and not a technical one, and moreover,
> the analogy may break down around the ways that numbers are not the same as
> stones. After all, if the point of the game is to create an artificial
> scarcity of numbers, what difference does it make where you put the prefix
> boundary in the process? You can set it anywhere you like and achieve the
> same effect.
>

So it was a metaphor. It's demonstrating the contrast between how we
value and handle diamonds (IPv4) verses how we value and handle sand
(IPv6).

I hadn't thought to think of it literally as Brian did, however I'm
not all that surprised for sand it is literal. It is probably fairly
literal for diamonds too.

Diamonds are rare, and therefore the dominant cost is in
finding/discovering them and extracting them. Transport and handling
after that are a trivial cost in comparison. Significantly reducing
the cost of diamonds would involve reducing the discovery and
extraction costs.

Sand is plentiful, so transport and handling becomes the dominant
cost. Reducing the cost of transport and handling directly reduces the
cost of sand.

Similarly, as IPv6 addresses are plentiful (once the infrastructure to
support IPv6 exists), "handling" them far outweighs the cost of
"finding" them. One of the ways to reduce the cost of IPv6 is to
reduce the cost of handling IPv6 addresses.

That's why I think simple universal sizes/boundaries like /48 per site
and /64 for subnets/64 bit IIDs are better. They reduce the cost of
handling - the cost of humans becoming involved to be parsimonious
with addresses and numbers of /64 prefixes increases the handling cost
of IPv6 addresses. They reduce costs in other places too - having a
single, common and generic IID size rather than a per link-specific
IID size means development and implementation of IPv6-over-foo
specifications is cheaper, because there does not have to be any per
link-specific IID size related effort.

The boundaries themselves are arbitrary, as long as they facilitate
all the requirements (in our IPv6 specific case, functionality,
ideally avoidance and tolerance of error (e.g., duplication of
addresses is rare, so DAD succeeds most of the time), security and
privacy). The important priority should be to have the least number of
boundaries.

For IPv6 to be as successful as we here want it to be, we want to make
adopting and using the technology as cheap as it possibly can be. That
will only encourage its use.

Regards,
Mark.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 9 Aug 2017 10:03:30 +0100

> link-specific IID size related effort.

Why do you think there will be any development cost saving - UNLESS you specifically rule out flexibility to handle unforeseen (or even foreseen) usage cases ?

So, lets assume we run with the "there will be no network with other than a /64 prefix" option. Devs can ignore any need to store or handle prefix lengths - very very marginal saving in dev time (lets face it, this code already exists to handle 32 bit numbers).
So what happens when someone does have a need to handle (say) a /65 because of some reason that's out of their control - perhaps all they get from upstream is a single /64 and they need to divide it. Answer - they can't, because for a very small saving up front, that flexibility has been ruled out.

I'm not saying that /64 can't or shouldn't be the default, but given all the comments about "not blocking future innovation" it seems a bit contrary to then insist on causing known problems for a marginal (and questionable) saving on development. AFAICS, there is agreement that there isn't actually any technical reason for HAVING to use a /64 anywhere (other than LL which is a special case anyway), and the only remaining technical reason is the now deprecated method of forming SLAAC addresses.

So is there ANY valid technical reason why implementations should not be required to handle arbitrary prefix lengths, since if you can handle any length, then you can easily handle 64 - but if you hardcode in 64 (probably by coding differently) then handling any other length may become impossible.
Or put another way, do you want to be one of those people who in 10, 20, ... years time are the target of "WTF were they thinking of ?" comments when/if there emerges a good case for a different prefix length and it can't be done because there's too much hardcoded /64 built into the system ?

BTW - the sand analogy breaks down once you consider that it too is limited. There may be more grains of sand on the beaches than we can count, but I can't just pop down to the beach and dig up a trailer load to build my new garage with without getting into trouble with the law ! The price soon starts adding up once you are buying it from the builders merchant.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Aug 2017 09:53:18 +1000

"Analysis of the 64-bit Boundary in IPv6 Addressing"

On 7 Aug. 2017 8:26 pm, "Simon Hobson" <[email-masked]> wrote:

> AFAICS the insistence that it must be /64 per host, rather than anything
> else (eg /80/host or /96/host) seems to be more religion than technical
> requirement.
> individual addresses should come from a /64 (or at least, large) prefix -
> but I fail to see much, if any, merit in allocating 2^64 addresses to a
> single host "because we can".
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Aug 2017 11:24:48 +1000

> is normal "do not care about wasting addresses!" level of IPv6 normal.

So it's worth considering what the word "waste" means. It means
getting no value at all from some quantity of a resource. That
quantity of resource isn't being used for anything of value to the
resource's user.

What we get from /64s/64 bit IIDs is simplicity (in planning and
operation), robustness (because if there is only one valid value for
something, every other value is an error and easy to see), and the
ability to give a addresses useful privacy and security properties.
They are all of use and value to the end-users users of the Internet,
so /64s/64 bit IIDs are not wasteful.

Of course, it would be possible to be reckless with resource
consumption such that you encounter unexpected and unnecessary
resource scarcity. The induced scarcity will then cause people to have
to start to make choices and trade-offs as to which beneficial uses
and values they get from the resource to give up.

So there needs to be a balance. Consumption must not be reckless,
however it also should not be so intentionally and artificially
constrained that trade-offs between beneficial uses and values have to
be made.

Brian's beach sand maths shows that there isn't a scarcity of /64s, in
particular as his calculations were within the 1/8th of the IPv6
address space we are currently using for global addresses (i.e.,
2000::/3). Leaving 1/8th for ULAs, Loopback etc., would still have
enough /64s in the other 6/8ths of the IPv6 address space to give one
to each grain of beach sand on 6 other Earth like planets.

> is not reasonable for me.

I don't think anybody is suggesting that a "host shared /64" model is
to be universally replaced with a universal "per-host /64 prefix"
model. It is an alternative option that has benefits in some
situations.

Sticking with a /64 boundary in this prefix per host model is for
simplicity and compatibility with existing specifications and
implementations. We should only give it up (and pay the costs of
giving it up) if it can be shown it can't work.

> for a "told you so" later.

I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion
/64s? If an ISP isn't giving out at least /56s to customers, the
problem isn't with the /64 boundary, it is the ISP carrying IPv4
address scarcity management practices over to IPv6 where they aren't
needed.

We are wasting our time (getting no value from it) trying to
accommodate unneeded IPv4 practices carried over to IPv6. We end up
trying to make things accommodate more and more perverse and
unnecessarily conservative IPv4 carried over practices. If we
accommodate them, we're also tacitly endorsing them.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Thu, 10 Aug 2017 07:58:19 +0200

Hi,

> quantity of resource isn't being used for anything of value to the

Waste can also mean "I have used up something without actually needing
it, and now it's missing somewhere *else*".

[..]
> address scarcity management practices over to IPv6 where they aren't

So how useful is a /56 to a customer if the customer wants to do
/64-per-host?

If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it's
all of a sudden becoming tight for slightly larger customer sites.

> accommodate them, we're also tacitly endorsing them.

I could point out that "a /64 everyhwere" is repeating the "Class A, B, C"
mistakes from IPv4.

Your turn.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Aug 2017 19:21:23 +1000

On 10 Aug. 2017 15:58, "Gert Doering" <[email-masked]> wrote:

Hi,

Do we have to purposely make something hard and costly to use before we can
make it easy and cheap to use? Do we have to treat IPv6 addresses like
diamonds, before eventually accepting the *maths* that shows they're at
least as common as grains of sand.

[..]

/56 entirely inappropriate for slightly larger sites. Give them a /48. If
an ISP thinks they can't get bigger than a /32 from their RIR, or that they
have to squeeze everything into a /32 "because it is so large and therefore
that's all I'll ever be able to justify getting", they need to be corrected.

Classes weren't a really a mistake. They were a workaround for not having
enough address bits and not being able to easily change the number of
address bits.

IP addresses went through many format and size changes between 1974 ("A
Protocol for Packet Network Intercommunication") and 1978 before 32 bits
was chosen as the fixed address size in September of 1978 (IEN54), with a
format of 8 bit network number and 24 bit hosts i.e. N.H.H.H. (There were
two different attempts at having variable length addresses that were
abandoned, RFC675 and IEN21.)

That persisted until RFC791, in September of 1981, where Class A, B, C, D
and E address types were introduced. Also at that time, show in RFC790,
there were already 42 what would now become "Class A" network numbers
assigned. So there was at least 3 years of happy and successful operation
with a simple N.H.H.H address format (i.e., no complexity due to classes,
subnets, subnet masks or prefix lengths) between IEN54 and RFC791.

I've called classes, subnets, CIDR etc. a series of neat hacks to get
around the 32 bit address space limit. At the time I asked Vint Cerf for
some more context.

https://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

"Date: Sat, 3 Apr 2010 08:17:28 -0400
From: Vint Cerf <vint at google.com>
To: Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Cc: Andrew
Gray <3356 at blargh.com>, NANOG List <nanog at nanog.org> Subject: Re:
legacy /8

When the Internet design work began, there were only a few fairly large
networks around. ARPANET was one. The Packet Radio and Packet Satellite
networks were still largely nascent. Ethernet had been implemented in
one place: Xerox PARC. We had no way to know whether the Internet idea
was going to work. We knew that the NCP protocol was inadequate for
lossy network operation (think: PRNET and Ethernet in particular). This
was a RESEARCH project. We assumed that national scale networks were
expensive so there would not be too many of them.  And we certainly did
not think there would be many built for a proof of concept. So 8 bits
seemed reasonable. Later, with local networks becoming popular, we
shifted to the class A-D address structure and when class B was near
exhaustion, the NSFNET team (I think specifically Hans-Werner Braun but
perhaps others also) came up with CIDR and the use of masks to indicate
the size of the "network" part of the 32 bit address structure. By 1990
(7 years after the operational start of the Internet and 17 years since
its basic design), it seemed clear that the 32 bit space would be
exhausted and the long debate about IPng that became IPv6 began. CIDR
slowed the rate of consumption through more efficient allocation of
network addresses but now, in 2010, we face imminent exhaustion of the
32 bit structure and must move to IPv6.

Part of the reason for not changing to a larger address space sooner
had to do with the fact that there were a fairly large number of
operating systems in use and every one of them would have had to be
modified to run a new TCP and IP protocol. So the "hacks" seemed the
more convenient alternative. There had been debates during the 1976
year about address size and proposals ranged from 32 to 128 bit to
variable length address structures. No convergence appeared and, as the
program manager at DARPA, I felt it necessary to simply declare a
choice. At the time (1977), it seemed to me wasteful to select 128 bits
and variable length address structures led to a lot of processing
overhead per packet to find the various fields of the IP packet format.
So I chose 32 bits.

vint"

People who believe IPv4 addressing that we have today is an ideal that we
should be aiming for in IPv6 are probably unlikely to be aware of IPv4
history of addressing evolution, or the research or proof-of-concept
network context it was originally designed and chosen for. IPv6 is really
the first true Internet protocol, and should not be artificially inhibited
by the legacy of IPv4's design context, practices, constraints and
workarounds.

Regards,
Mark.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 16 Aug 2017 11:40:00 +0100

Mark Smith <[email-masked]> wrote:

> Do we have to purposely make something hard and costly to use before we can make it easy and cheap to use?

Turning that around, do we have to hard-code limitations in that we cannot know the consequences of ?
Even hard-coding /64 doesn't remove the need to be able to work with variable length prefixes in all but the most trivial of systems, and given modern hardware capabilities, the processing cost can hardly be called expensive (even on the most basic of processors). Bear in mind that it's now hard to buy a processor that isn't orders of magnitude more powerful (and resource endowed) than the computers that first put men on the moon.

EVERY router must possess the ability to work with variable length prefixes. Every protocol stack in any OS/firmware that "might" ever be used for routing mist therefore support variable prefix lengths. So in the general case, there will be very little (if any) saving in software costs. In fact, having a /64 hard coded MAY allow a different code structure - but this is likely to be in addition to the variable prefix length code, and thus increase the amount of code to be written and maintained.

All this is supposed to be transparent to the end user - so it shouldn't matter to them. And anyone working with networks will need to understand variable length prefixes (48 =/= 56 =/= 60 =/= 64) so unless no-one gets anything but a /64 from their ISP then the argument about not having to learn about variable prefix lengths goes out the window as well. So now we have a default of a single /64/customer - and needing customer involvement if all those nice things (Homenet ?) that want multiple /64s are to work for them.

> Do we have to treat IPv6 addresses like diamonds, before eventually accepting the *maths* that shows they're at least as common as grains of sand.

Just this week, over on the ISC DHCP users list, there was a question regarding changing PD sizes which turned out to be a bug in the server package. However, this ISP defaults to offering a single /64 with the option to switch to a /56.
I did ask why not to default to /56 - the answer being that they've hit a small number of CPE routers that couldn't handle anything but a /64 PD. Given the choice between something that "works for most people out of the box" and having to take support calls and explain why their cheap-n-nasty router didn't work - they chose the option of a single /64 by default.

I'd suggest that this is a side effect of the "/64 everywhere" mantra. Someone inexperienced has picked up a spec, seen that "everything is /64", so they've (incorrectly) assumed all they need to deal with is a /64.
You can argue that the person/group responsible for this pile of rubbish didn't read the specs correctly. That may well be the case. But when so many documents all read as though /64 is set in stone, it's not hard to see why someone reading them quickly (as in manager has told them they have a short bit of time to learn the subject and bash out some code) might miss the subtlety.

I can see the argument for "make it simple", but that is a recipe for hardcoding in constraints in the future. Some kit (or bits of software) goes on and on for a long time. I recall getting bitten a long time ago when (many years after classless addressing was history) I came across a bit of kit that enforced class rules - specifically wouldn't allow a 192.168.nn.nn/23 address to be configured. As a result, I had to renumber the network into the 172.16/12 block to accommodate this bit of code. The unit itself wasn't very old (in manufacturing terms), but the design and the code in it was.

> People who believe IPv4 addressing that we have today is an ideal that we should be aiming for in IPv6 are probably unlikely to be aware of IPv4 history of addressing evolution, or the research or proof-of-concept network context it was originally designed and chosen for. IPv6 is really the first true Internet protocol, and should not be artificially inhibited by the legacy of IPv4's design context, practices, constraints and workarounds.

I think you are disingenuous labelling the argument in such terms.

I'm not arguing against having /64 as the default - but I am arguing against hardcoding in assumption that may well turn out to be incorrect, and hard to correct due to having been hardcoded into various implementations (that might not even be supported by the vendor any more).

I'm sure many developers (or at least, their managers) once thought that their code would never be used into the year 2000 - that turned out to be an incorrect assumption. The history of computing is littered with similar examples where people went for the 'easy" option, only to hardcode in something which later turned around to bite their backside. I keep seeing an argument for the easy option of "/64 everywhere" which is ALREADY causing problems.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Aug 2017 23:00:43 +0900

On Wed, Aug 16, 2017 at 7:40 PM, Simon Hobson <[email-masked]>
wrote:

> Even hard-coding /64 doesn't remove the need to be able to work with
> variable length prefixes in all but the most trivial of systems, and given
> modern hardware capabilities, the processing cost can hardly be called
> expensive (even on the most basic of processors). Bear in mind that it's
> now hard to buy a processor that isn't orders of magnitude more powerful
> (and resource endowed) than the computers that first put men on the moon.
>

/64 gives you something that no longer prefix does: the ability to run
SLAAC and connect unlimited devices behind the host.

I'd suggest that this is a side effect of the "/64 everywhere" mantra.
> Someone inexperienced has picked up a spec, seen that "everything is /64",
> so they've (incorrectly) assumed all they need to deal with is a /64.
>

No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly
announces it in an RA. That doesn't work because SLAAC only works with
64-bit IIDs, and for good reason.

I'm sure many developers (or at least, their managers) once thought that
> their code would never be used into the year 2000 - that turned out to be
> an incorrect assumption. The history of computing is littered with similar
> examples where people went for the 'easy" option, only to hardcode in
> something which later turned around to bite their backside. I keep seeing
> an argument for the easy option of "/64 everywhere" which is ALREADY
> causing problems.

Already? 64 everywhere has been the standard for 20 almost years now. It
predates pretty much every IPv6 network and every IPv6 implementation out
there today.

---

From: Simon Hobson <[email-masked]>
Date: Wed, 16 Aug 2017 20:47:02 +0100

Lorenzo Colitti <[email-masked]> wrote:

> /64 gives you something that no longer prefix does: the ability to run SLAAC and connect unlimited devices behind the host. 

From previous discussions, I am led to believe that SLAAC will work with other (longer or shorter) prefixes. It is only the deprecated EUI64 method that *needs* 64 bits.

> No. Someone wrote code that gets a prefix via DHCPv6 PD, and blindly announces it in an RA.

Are you suggesting that someone who realises that not everything is a /64 would do that ? You've not really done anything to counter this being a case of "everything is /64" thinking and thus ignoring the potential for anything else. It may be a simple case of blindly re-announcing the prefix you got delegated - but it still comes down to not understanding that the prefix may be other than /64.

> That doesn't work because SLAAC only works with 64-bit IIDs, and for good reason.

As above, I've seen comments here stating that this isn't the case.

> Already? 64 everywhere has been the standard for 20 almost years now. It predates pretty much every IPv6 network and every IPv6 implementation out there today.

And that hardcodes in a restriction which IN THE REAL WORLD is known to cause issues. For example, you (incorrectly) only get a single /64 from upstream, but want to something other than a single host or very simple network. I agree that it shouldn't happen, but in the real world it does - you either stick with a simple basic network, or you run prefixes smaller than a /64.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Aug 2017 08:21:22 +1200

>>From previous discussions, I am led to believe that SLAAC will work with other (longer or shorter) prefixes. It is only the deprecated EUI64 method that *needs* 64 bits.

Properly coded SLAAC will work with any reasonable length, but standards-compliant
IPv6-over-foo drivers will *all* inform SLAAC that the length is 64, because that is
the parameter set by the addressing architecture.

What we are discussing here is not SLAAC, or the fact that each driver has to inform
SLAAC about the IID length, but whether the addressing architecture should continue
to define a universal constant for that parameter.

And we are certainly not discussing whether IPv6 supports variable length subnet masks.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 09:12:52 +0900

On Thu, Aug 17, 2017 at 4:47 AM, Simon Hobson <[email-masked]>
wrote:

> From previous discussions, I am led to believe that SLAAC will work with
> other (longer or shorter) prefixes. It is only the deprecated EUI64 method
> that *needs* 64 bits.
>

In practice it does not because every link layer specifies 64-bit IIDs.

> announces it in an RA.
> Are you suggesting that someone who realises that not everything is a /64
> would do that ? You've not really done anything to counter this being a
> case of "everything is /64" thinking and thus ignoring the potential for
> anything else. It may be a simple case of blindly re-announcing the prefix
> you got delegated - but it still comes down to not understanding that the
> prefix may be other than /64.
>

You could just as well answer that if someone thought that everything was
/64 they'd just reject non-/64 prefixes.

> And that hardcodes in a restriction which IN THE REAL WORLD is known to
> cause issues. For example, you (incorrectly) only get a single /64 from
> upstream, but want to something other than a single host or very simple
> network. I agree that it shouldn't happen, but in the real world it does -
> you either stick with a simple basic network, or you run prefixes smaller
> than a /64.

If the ISP is well-intentioned, it will give you a /64. If the ISP not
well-intentioned, they will give you an allocation that is the minimum size
that clients are prepared to accept. So you will never be able to subnet
anyway - as soon as your device is willing to do SLAAC on a /80, that's
what your ISP will hand you. There's no point starting that arms race.

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 09:24:00 +0900

Does this ‘unlimited devices behind the host’ include the following case?

  - A host gets a /64 prefix.

  - The host runs for itself an internal ‘Unique-IPv6-Prefix-per-Host’ so that it hands out a /96 prefix to each internal device.

  - In effect, this comes down to /96 prefixes and 32-bit IIDs.

Technically, there’s no reason why this cannot be done, I’d assume. However, would this be forbidden in the sense of the current and related std track documents?

---
DY

> On 16 Aug 2017, at 23:00, Lorenzo Colitti <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Aug 2017 13:32:01 +1200

> Technically, there’s no reason why this cannot be done, I’d assume. However, would this be forbidden in the sense of the current and related std track documents?

It's forbidden by the fact that RFC4291 states that the IID length is 64. Clearly that applies to SLAAC; it's a bit less clear whether it applies to DHCPv6. But the privacy related RFCs make it pretty clear that 32 bits is too small.

     Brian

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 02:33:39 +0000

In 'Unique-IPv6-Prefix-per-Host', IIDs given by a host are given to its own
interfaces. Should there be any privacy concern about the IIDs which are
confined to a single host?

As I think, privacy concerns might be more related to /64 prefixes rather
than IIDs. Therefore, the IID length might not bear much implication in
regard to privacy.

SLAAC by itself does not put any restrictions on the IID length. Unless the
SLAAC software is hard-coded to 64-bit IIDs, it should be able to process
configure 32-bit IIDs.

If the available SLAAC is really hard-coded to 64-bit, then I mght write
and enforce, onto the internal devices (behind my host), a simple code to
assign 32-bit (or whatever bits shorter than 64) IIDs, since the devices
might be under my control.

Would this be policed not ever to happen?

On Thu, 17 Aug 2017 at 10:32 Brian E Carpenter <[email-masked]>
wrote:

> >   - The host runs for itself an internal ‘Unique-IPv6-Prefix-per-Host’
> so that it hands out a /96 prefix to each internal device.
> >
> > Technically, there’s no reason why this cannot be done, I’d assume.
> However, would this be forbidden in the sense of the current and related
> std track documents?
>
> It's forbidden by the fact that RFC4291 states that the IID length is 64.
> Clearly that applies to SLAAC; it's a bit less clear whether it applies to
> DHCPv6. But the privacy related RFCs make it pretty clear that 32 bits is
> too small.
>
>      Brian
>
> --
----
DY

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Aug 2017 12:48:06 +1000

On 17 August 2017 at 12:33, DY Kim <[email-masked]> wrote:
> than IIDs.

Externally, it is not possible to determine whether a /64 is assigned
to a link or a host - consequently, it isn't possible to know if
source addresses from with a /64 represent a single device's traffic
(the /64 is assigned to a single device) or traffic from a range of
devices (a /64 is shared by many devices attached to a link.)

>Therefore, the IID length might not bear much implication in
> regard to privacy.
>

Individual source addresses however always represent traffic from a
single device.

"Security and Privacy Considerations for IPv6 Address Generation Mechanisms"
https://tools.ietf.org/html/rfc7721

> If the available SLAAC is really hard-coded to 64-bit, then I mght write and
> enforce, onto the internal devices (behind my host), a simple code to assign
> 32-bit (or whatever bits shorter than 64) IIDs, since the devices might be
> under my control.
>
>> > However, would this be forbidden in the sense of the current and related std
>> > track documents?
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 11:50:13 +0900

No, that doesn't work for two reasons:

   1. The "internal" hosts now have sub-par network connectivity that they
   cannot share any further with hosts behind them.
   2. As soon as enough hosts accept a /96 prefix length, a network
   operator that wants to limit address space can simply assign a /96 to the
   main host. That makes it impossible for these internal hosts to share their
   own connectivity without NAT.

On Thu, Aug 17, 2017 at 9:24 AM, DY Kim <[email-masked]> wrote:

>   - The host runs for itself an internal ‘Unique-IPv6-Prefix-per-Host’ so
> that it hands out a /96 prefix to each internal device.
>

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 13:54:59 +0900

Sent from my iPhone

> On 17 Aug 2017, at 11:48, Mark Smith <[email-masked]> wrote:
> 

Exactly.

So, why would it bother you

   - if a host given a /64 prefix assigns a 64-bit IID to each of its interfaces, or 

   - if the same host subdivides the /64 prefix into multiple /96 prefixes each of which be given to internal devices behind, wherein each device then assigns 32-bit IIDs to its own interfaces.

Such domestic behaviors are not observable from outside, so why would you enforce 64 bits for whatever is classified as an IID?

> Individual source addresses however always represent traffic from a

Of course.  

The original question was about the feasibility of 32-bit length of IIDs for internal devices behind a /64 host, in regards to privacy.

In a legacy IPv6 networking, the pool of 64-bit IIDs would be shared by hosts inside a subnet which may contain arbitrarily many hosts,

whereas in my scenario of internal /96 devices behind a /64 host, the pool of 32-bit IIDs would be shared by interfaces of a single device.

If obfuscation should be a measure of merit, the obfuscation of 32-bit IIDs across interfaces of a /96 device should not be terribly inferior to that of 64-bit IIDs across all interfaces of all hosts inside a /64 subnet.

My question then goes back to

   - What's the point of mandating 64 bits for IIDs when behaviors internal to or behind a /64 are not observable from outside anyhow?

   - Are there any practical ways to police them and return penalties to ill-behaving hosts?

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Aug 2017 15:07:00 +1000

>> Individual source addresses however always represent traffic from a

That is exactly why IID values matter. There is no hiding what they
are referring to. They're always referring to a individual end point,
there is no ambiguity.

Externally you cannot really tell if /64s are being used. If you
assume they are, you still cannot tell whether the /64 is assigned to
a link shared between a set of hosts, or assigned to an individual
host.

There is no such ambiguity with a single 128 bit IPv6 address. It's an
end-point identifier.

> If obfuscation should be a measure of merit, the obfuscation of 32-bit IIDs across interfaces of a /96 device should not be terribly inferior to that of 64-bit IIDs across all interfaces of all hos…

Have you read

?

>    - What's the point of mandating 64 bits for IIDs when behaviors internal to or behind a /64 are not observable from outside anyhow?

Urm, are you assuming NAT? Source addresses are visible to the
outside, because there isn't

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 14:08:15 +0900

I'm afraid I don't get you exactly here, but I'll try inline...

Sent from my iPhone

> On 17 Aug 2017, at 11:50, Lorenzo Colitti <[email-masked]> wrote:
> 
> The "internal" hosts now have sub-par network connectivity that they cannot share any further with hosts behind them.
The /64 host in my scenario in fact now behaves as a router and distributes /96 prefixes to internal devices. E2E connections don't terminate at the /64 node but at /96 devices.

No NAT at the /64 node for e2e connections for /96 devices.
> As soon as enough hosts accept a /96 prefix length, a network operator that wants to limit address space can simply assign a /96 to the main host.
Confused.

/96 prefixes are handed out by a /64 host, not by a network operator.
> That makes it impossible for these internal hosts to share their own connectivity without NAT.
No NAT necessary as I described above.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 14:17:46 +0900

On 17 Aug 2017 14:08, "DaeYoung KIM" <[email-masked]> wrote:

The /64 host in my scenario in fact now behaves as a router and distributes
/96 prefixes to internal devices. E2E connections don't terminate at the
/64 node but at /96 devices.

You said that, yes. the host gets a /64. The hosts behind it get a /96
each. Which means that the hosts behind it have worse connectivity than it
does, because they can't further extend the network (without NAT).

   1. As soon as enough hosts accept a /96 prefix length, a network
   operator that wants to limit address space can simply assign a /96 to the
   main host.

Confused.

This requires that hosts will accept a /96 if the network gives them one.
Thus, a network operator that wants to limit address space can simply
assign a /96 to a host. Then the host will not be able to give other hosts
behind it any /96 prefixes. So if the host wants to extend the network to
other hosts it has to use NAT.

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 14:31:19 +0900

Yes, I did. What do I miss?

Sent from my iPhone

> On 17 Aug 2017, at 14:07, Mark Smith <[email-masked]> wrote:
>

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 14:37:19 +0900

Sent from my iPhone

> are referring to. They're always referring to a individual end point,

Yes,

> a link shared between a set of hosts, or assigned to an individual

No, I cannot,

> There is no such ambiguity with a single 128 bit IPv6 address. It's an

Yes.

> https://tools.ietf.org/html/rfc7721

Yes. What do I miss?

> Urm, are you assuming NAT?

No, I'm not.

> Source addresses are visible to the

??

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Aug 2017 16:02:44 +1000

Hi,

> Yes, I did. What do I miss?

It seemed that you might have missed that there are security issues
IIDs with low entropy e.g., the MAC address derived ones, e.g., being
vulnerable to address scanning.

Regards,
Mark.

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 15:17:06 +0900

Sent from my iPhone

> On 17 Aug 2017, at 14:17, Lorenzo Colitti <[email-masked]> wrote:

> You said that, yes. the host gets a /64. The hosts behind it get a /96 each. Which means that the hosts behind it have worse connectivity than it does, because they can't further extend the network (without NAT).

I would' mind that. I'm not a manager of s whole site (of /48 typically), and that's neither my interest nor purview.

All I'm interested would be whether I could recursively apply the same mechanism of 'Unique-IPv6-Prefix-per-Host' internally to my node (perhaps a sophisticated robot or a small IoT island).

(At this point, I'd like to see the draft read '-per-Node' rather than '-per-Host'. If the node terminates connections, then it's a host whereas it's a router if it doesn't only to relay packets to connection-teminating internal devices.)

So, I'm not interested in network connectivity the size of a whole (typically /48) site up to theoretically as many as 2^80 (= 128 - 48) nodes. The application area I'd be interested with my scenario would be in an internal network of tens or hundreds nodes if not thousands. Within my /64 prefix, I can in fact give birth to theoretically as many as 2^32 internal devices (each of a /96 prefix), effectively the size of the whole IPv4 Internet which would be way way more than I'd need.

> This requires that hosts will accept a /96 if the network gives them one. Thus, a network operator that wants to limit address space can simply assign a /96 to a host. Then the host will not be able to give other hosts behind it any /96 prefixes. So if the host wants to extend the network to other hosts it has to use NAT.

Let's make this clear before going any further: I'm not at all against principally distributing /64 prefixes to hosts up to this draft. That far, fine.

All I'm asking is whether I could recursively apply the same (or equivalent) mechanism to my /64 host to incarnate a child network behind my host. My internal devices don't get prefixes directly from a network operator upstream to me, but exclusively from my /64 host. No worry about malicious upstream network operators.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 15:26:57 +0900

On Thu, Aug 17, 2017 at 3:17 PM, DaeYoung KIM <[email-masked]> wrote:

> The /64 host in my scenario in fact now behaves as a router and
> distributes /96 prefixes to internal devices. E2E connections don't
> terminate at the /64 node but at /96 devices.
>
>
> I would' mind that. I'm not a manager of s whole site (of /48 typically),
> and that's neither my interest nor purview.
>
> All I'm interested would be whether I could recursively apply the same
> mechanism of 'Unique-IPv6-Prefix-per-Host' internally to my node (perhaps a
> sophisticated robot or a small IoT island).
>

Ah, I see. If you're asking whether you can use this technique to hand out
a /96 per host, then the answer is no. You can't use this technique because
this technique presumes the use of SLAAC, and SLAAC only works with 64-bit
prefixes (except for addresses in ::/3, which aren't routable on the
Internet).

If you're suggesting that SLAAC be changed to support non-64 bit prefixes,
that topic is out of scope for this document and this working group.

If you're willing to use something other than SLAAC, such as DHCPv6, then
all you need is one /64 for your whole network and you can number as many
devices as you want.

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 15:36:42 +0900

Sent from my iPhone

> On 17 Aug 2017, at 15:02, Mark Smith <[email-masked]> wrote:
> 
> Hi,
> 

Discussions in that privacy doc are mainly based on a typical legacy network of /64 subsets of an arbitrary size whereas mine example is with a single /96 device.

On the other hand, I'd be more concerned about the entropy of /64 hosts in a /48 site. Scanning would be over 2^32 /64 hosts.

Back to 32 bits for my device IIDs, if there be insists, I could switch to 48 bit IIDs with /56 prefixes for my internal devices. I remember I read somewhere that bits around 40 would secure enough entropy for privacy (or was it for collision avoidance?).

---

From: DaeYoung KIM <[email-masked]>
Date: Thu, 17 Aug 2017 15:49:53 +0900

Sent from my iPhone

> Ah, I see. If you're asking whether you can use this technique to hand out a /96 per host, then the answer is no. You can't use this technique because this technique presumes the use of SLAAC, and SLAAC only works with 64-bit prefixes (except for addresses in ::/3, which aren't routable on the Internet).
> 
> If you're suggesting that SLAAC be changed to support non-64 bit prefixes, that topic is out of scope for this document and this working group

As I know, SLAAC by itself doesn't impose restrictions on the IID length. It's Addr Arch (4291bis) that imposes it.

Then, are all deployed SLLAC software hard-coded to 64 bits? If properly implemented, the IID length should remain a parameter that can be set by an admin.

Should the latter be the case, my life would get easiest.

> If you're willing to use something other than SLAAC, such as DHCPv6, then all you need is one /64 for your whole network and you can number as many devices as you want.

If not for SLAAC, this would certainly be my last option.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 15:59:38 +0900

On Thu, Aug 17, 2017 at 3:49 PM, DaeYoung KIM <[email-masked]> wrote:

> > Ah, I see. If you're asking whether you can use this technique to hand
> out a /96 per host, then the answer is no. You can't use this technique
> because this technique presumes the use of SLAAC, and SLAAC only works with
> 64-bit prefixes (except for addresses in ::/3, which aren't routable on the
> Internet).
> >
> > If you're suggesting that SLAAC be changed to support non-64 bit
> prefixes, that topic is out of scope for this document and this working
> group
>
> As I know, SLAAC by itself doesn't impose restrictions on the IID length.
> It's Addr Arch (4291bis) that imposes it.
>
> Then, are all deployed SLLAC software hard-coded to 64 bits? If properly
> implemented, the IID length should remain a parameter that can be set by an
> admin.
>

Again, that topic is out of scope for this document and this working group.

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 07:04:53 +0000

On Thu, 17 Aug 2017 at 16:00 Lorenzo Colitti <[email-masked]> wrote:

Suffices to know at this moment that I could recursively apply the
mechanism to my /64 node, albeit perhaps not with SLAAC.
-- 
----
DY

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Aug 2017 09:36:43 +0200

Simson,

> From previous discussions, I am led to believe that SLAAC will work with other (longer or shorter) prefixes. It is only the deprecated EUI64 method that *needs* 64 bits.

That's not quite correct, at least not in a historical context.
While the term "Modified EUI-64" was most commonly derived from a MAC address it was also used for interface identifiers derived by any other means. Be it serial numbers, random tokens or manually configured. By that definition an interface-id generated with the method in 7217 is still a Modified EUI-64.

With regards to your "will work" comment. Sure, it is just software, we can make anything work.
I am not aware of any implementation supporting that though. Certainly the ones I am involved with do not.

Someone pointed me at this paper which is quite relevant for this discussion.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/State-the-Problem-Before-Describing-the-Solution.pdf

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Aug 2017 09:37:49 +0200

> Simson,

Stumbling fingers, apologies, that should of course be "Simon".

/ot

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 17:53:56 +0900

I’d hope I’m not bothering busy people too much, but let me recall the history as I remember:

 o 128 bits decided for the IPv6 address length, part of which being prefix, part IID.

 o The next question arose about how to configure the addresses.

 o People noticed that 128 bits are large enough to hold the whole 802 MAC addresses.

 o Soon, they also realized the length of the 802 MAC addresses are going to be extended to 64 bits.

 o Each host interface would be associated with, typically, a 802 MAC, so it should be the most convenient choice to identify an interface.

 o This then led to the possibility that the address can be auto-configured once the hosts are given subnet prefixes, i.e., 64-bit subnet prefix and 64-bit IID.

 o The practice has been over 20 years.

 o By now, IIDs are not to be configured with MAC addresses anymore, but with (hashed) random numbers to provide privacy.

 o Hence, the historical link of the IID to the MAC address is now broken, and so its link to 64 bits. Apparently, IID is now free from 64 bits.

 o And yet, people would now pick the fallen broken branch of 64 bits, and try to graft it back to the trunk IID.

 o As the history started out 20 years ago, the IID would be the master and the 64-bit would be the slave. Now, the history is about to go upside down so that the roles are overturned; the 64-bit is now the master and the IID would be the slave.

This flow of history looks a bit funny to me, I’m afraid.

---
DY

> On 17 Aug 2017, at 16:36, Ole Troan <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Aug 2017 10:58:40 +0200

Have you read RFC7421?
What problem are you trying to solve?

Ole

> On 17 Aug 2017, at 10:53, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 18:05:37 +0900

---
DY

> On 17 Aug 2017, at 17:58, Ole Troan <[email-masked]> wrote:
> 
> Have you read RFC7421?

Yes, I did. With my own bias, the doc looks quite in the interest of defending one school of thoughts.

> What problem are you trying to solve?

Not really. I find it a bit amusing that sometimes logics seem to be overridden under the name of ‘rough consensus’. 

And ‘recommend’ is one thing, and ‘mandate’ is another.

---

From: Ole Troan <[email-masked]>
Date: Thu, 17 Aug 2017 11:14:01 +0200

> And ‘recommend’ is one thing, and ‘mandate’ is another.

We're here to do engineering. We solve problems. Until we have real problems to solve I think time would be better spent elsewhere...

Ole

---

From: DY Kim <[email-masked]>
Date: Thu, 17 Aug 2017 18:28:54 +0900

While you don’t see ‘the broken logic’ as a problem while I do, all is fine with me what’s been proceeding here.

---
DY

> On 17 Aug 2017, at 18:14, Ole Troan <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Aug 2017 19:42:59 +1000

We have an installed base that numbers in the billions (i.e., at least the
Android and iPhone implementations). Whether or not 64 bit IIDs really need
to be 64 bits to suit all the requirements isn't really the question
anymore. It is what are the consequences and costs of changing it now?
They'd be high costs because of the installed base that assume 64 bits.

The criticism of "tradition" or "religion" would be more valid if it was
criticising something arbitrary that hadn't made it into production
implementations for many years. Those changes could have easily been made
in the mid 1990s, but not now when every IPhone, Android, Windows and
probably all other IPv6 implementations in the hands of end-users that
assume 64 bits.

I started experimenting with the Linux implementation of IPv6 in 1998. 64
bit IIDs, SLAAC and RA PIOs from then are still the same today, so a 1998
implementation of IPv6 would still work today, nearly 20 years later.
That's how long (at least) these working conventions have been in place.

Change isn't cheap in IPv6. It's much cheaper to propose significant change
for the next version of IP (IPv10 going by IANA).

Regards,
Mark.

On 17 Aug. 2017 7:05 pm, "DY Kim" <[email-masked]> wrote:

---
DY

> On 17 Aug 2017, at 17:58, Ole Troan <[email-masked]> wrote:

Yes, I did. With my own bias, the doc looks quite in the interest of
defending one school of thoughts.

> What problem are you trying to solve?

Not really. I find it a bit amusing that sometimes logics seem to be
overridden under the name of ‘rough consensus’.

---

From: Lee Howard <[email-masked]>
Date: Thu, 17 Aug 2017 11:48:12 -0400

On 8/17/17, 2:49 AM, "v6ops on behalf of DaeYoung KIM"
<[email-masked] on behalf of [email-masked]> wrote:

>>because this technique presumes the use of SLAAC, and SLAAC only works
>>with 64-bit prefixes (except for addresses in ::/3, which aren't
>>routable on the Internet).
>> 
>implemented, the IID length should remain a parameter that can be set by
>an admin.
>

If you control the software and configuration on the network nodes and on
the host devices, you can run your network however you want to.
Interoperability with other networks is what matters, and I don’t think
it’s affected here.

>
>> If you're willing to use something other than SLAAC, such as DHCPv6,
>>then all you need is one /64 for your whole network and you can number
>>as many devices as you want.
>

You can assign addresses on your network using whatever mechanism you
want. It sounds like other network operators and software engineers don’t
want to modify their systems to accommodate your requirement, but if you
don’t need their accommodation, you can build what you want.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Aug 2017 08:36:52 +1200

> Back to 32 bits for my device IIDs, if there be insists, I could switch to 48 bit IIDs with /56 prefixes for my internal devices. I remember I read somewhere that bits around 40 would secure enough…

That's mentioned in a hand-waving way in https://tools.ietf.org/html/rfc7421#section-4.5

2**40 is roughly equal to 10**12, which makes brute-force guessing quite hard. 

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Aug 2017 08:48:57 +1200

> Yes, I did. With my own bias, the doc looks quite in the interest of defending one school of thoughts.

I am puzzled by that remark. The authors included a range of opinions and we worked
hard to presents facts (both facts about the published specifications and facts
about observed behaviour of implementations). And the opening paragraph states
"IPv6 routing is entirely based on variable length prefixes (also known as variable
length subnet masks), there is no basic architectural assumption that
n has any particular fixed value."

So I'm afraid that the document is actually stating something about reality,
whether we like it or not.

    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 17 Aug 2017 18:01:33 -0500

> whether we like it or not.

I think RFC7421 fairly represents the facts as they are, in section 4.3.2
"Other Observations", it even says;

   Also, DHCPv6 is in widespread use without any dependency on the /64
   boundary.  Reportedly, there are deployments of /120 subnets
   configured using DHCPv6.

I just wish we could get RFC4291bis to represent the facts as fairly as
RFC7421. No, that doesn't mean that SLAAC with anything other than /64 and
64 bit IIDs should be allowed by RFC4291bis. However, it seems clear that
other than for SLAAC, /64 is just a recommendation, an important
recommendation all be it, but a recommendation and not a requirement. /64
is a requirement for SLAAC, changing that is out of scope for RFC4291bis as
I see it.

Personally, I'm just looking for RFC4291bis to represent the reality of
IPv6 today.

My personal version of that reality is; at work and at home my iPhone,
iPad, and MacBook Pro all get IPv6 addresses with SLAAC from a /64 subnet,
and I'm happy with that.  I wish Comcast would give me more than one /64 at
home. Maybe they do now, I haven't had time to screw around with my home
network in 12 to 18 months.  However, I've had native IPv6 at home from
them for 3.5 years now, so I'm doing better than a lot of the world. My
iPhone and iPad haver several IPv6 addresses from my carrier AT&T, but I
don't seem to use them for Internet access.

At work we are #89 and at 63% of our hosts doing IPv6 for July on
http://www.worldipv6launch.org/measurements/ and we do SLAAC for most
things.

However, my MacBook Pro does allow for manual configuration of an IPv6
address and an on-link prefix of any length, and while I haven't tested I
suspect the DHCP client will work for with other than /64 too.  Also, most
laptops and desktops, and all our routes at work allow manual configuration
of any length subnets and work with DHCP with any length subnets as well.

So can we please get past arguing about letting SLAAC use subnets other
than /64, and update RFC4291bis to reflect the reality of IPv6 fully
discussed in RFC7421. Once we've done that, then maybe we can look at
retooling SLAAC, but that is not simply changing a few words in RFC4291bis,
that is a major redevelopment effort, with new running code, and testing
like crazy. That will be a lot of work, it may or may not be worth it, but
that should come after we get RFC4291bis updated to the real world
described in RFC7421 out the door.

Thanks.

---

From: DY Kim <[email-masked]>
Date: Fri, 18 Aug 2017 08:27:01 +0900

---
DY

> On 18 Aug 2017, at 05:48, Brian E Carpenter <[email-masked]> wrote:
> 
> about observed behaviour of implementations).

My apology to the authors if my comments fell personal to them.

> And the opening paragraph states
> n has any particular fixed value.”

… and the conclusion is to stick to the ‘fixed' value of 64 bits.

> whether we like it or not.

So, done is done…?

SLAAC implementations faithful to the spec should have left the prefix length open, to be configurable/settable by the admin. If not, the implementations should have been declared non-conformant with the spec.

The rationale for rfc7421 might be that the deployment base is so huge (counting to billions…?) that we’d better live with the ‘reality’. The rational might be by looking into the past of 20 years.

How many more years do we expect/wish IPv6 is going to prevail? Another 20 years? Or 100 years?

One question to ourselves could be whether to make decision in the interest of the past 20 years or far more years to come. The count now might be billions but it is just about to explode by the several orders of magnitude, with emerging IoT and disruptive applications. Shall we confine the future births in a cage or shall we set them open to explore their wild dreams not imaginable by us at this point in the networking history.

Is it a compelling reason to keep those uncountable implementations interoperable with those of the 90s? How many computer systems, OSs, programs are interoperable with those of 90s?

My loved Macintosh, first-generation MacBook, and the HyperCard don’t work/interoperate with my new machines, but that’s OK. Old guys fade away… that’s about life.

If any implementations are not in conformance with the spec, that’s them who should fade away, not the ones in conformance. Bad guys should die, not the other way around.

Nothing is too late to change or bring back to right.

That would be a school of thoughts I might join.

Unfortunately, the IETF ‘rough consensus’ seems to be the other way. Then, someone as me as a minority should just step back and keep silent since it’s the rule of the game that the majority prevails. Fine. That’s also about life…

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Aug 2017 16:43:07 -0700

At Fri, 18 Aug 2017 08:27:01 +0900,
DY Kim <[email-masked]> wrote:

> SLAAC implementations faithful to the spec should have left the
> prefix length open, to be configurable/settable by the admin. If
> not, the implementations should have been declared non-conformant
> with the spec.

This is not correct.  SLAAC implementations faithful to the spec
should leave the IID length (and therefore its prefix length) open to
the underlying link-type specification (such as RFC2464).  It's not
open to be configurable/settable by the admin.

If an implementation unconditionally hardcodes a particular value such
as 64, then technically, it's non-compliant.  But as of today it's not
distinguishable from truly compliant implementations based on
externally visible behavior, since all known (at least as far as I
know) such link-type specifications use the same single constant, 64.

--
JINMEI, Tatuya

---

From: DY Kim <[email-masked]>
Date: Fri, 18 Aug 2017 09:44:18 +0900

Now, it’s said the IID should not be derived from the link-layer address, for privacy. If anything, the link-layer address shall be conveyed in an option field of a related packet.

Now, what still mandates the IID length be 64 bits?

---
DY

> On 18 Aug 2017, at 08:43, 神明達哉 <[email-masked]> wrote:
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 17 Aug 2017 18:08:17 -0700

At Fri, 18 Aug 2017 09:44:18 +0900,
DY Kim <[email-masked]> wrote:

> Now, it’s said the IID should not be derived from the link-layer
> address, for privacy. If anything, the link-layer address shall be
> conveyed in an option field of a related packet.
>

There can be several answers, but I don't think such a discussion
helps.  Some people would point to the existing deployment base; some
others might say it just must be sufficiently large and we shouldn't
change the current constant without a reason to avoid confusion.  One
can easily find a counter argument to those, but it will simply lead
to the circle of arguments we've seen.  It's already pretty clear that
neither side can persuade the other just through these email threads.

If the purpose of the question is to change the current standard
value, I'd suggest you write your own draft that updates these RFCs.
Just mumbling in this mailing list won't help change it.  It's just a
waste of our time.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Aug 2017 10:16:52 +0900

> open to be configurable/settable by the admin.

Actually, even more than that. For everything except ::/3 (which it is
unlikely that any implementation will encounter), IIDs are 64 bits long
because of RFC 4291.

Personally, I think this is why there is such a lack of consensus on
4291bis. The lack of consensus is about the future, not the
present.Currently, any new link layer that is defined has to either use
64-bit IIDs or update 4291. And any new address assignment mechanism that
is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow
non-64-bit IIDs, that all goes out of the window.

For example: if we remove the 64-bit boundary in 4291, does it instantly
become valid to create RFC7217 addresses with 5-bit IIDs?

---

From: DY Kim <[email-masked]>
Date: Fri, 18 Aug 2017 10:18:28 +0900

---
DY

> On 18 Aug 2017, at 10:08, 神明達哉 <[email-masked]> wrote:
> 

Most probably, it’s going to be just a wast of my time; little chance to be adopted.

> Just mumbling in this mailing list won't help change it.  It's just a

OK. Case closed.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Aug 2017 10:46:27 -0700

At Fri, 18 Aug 2017 10:16:52 +0900,

> unlikely that any implementation will encounter), IIDs are 64 bits long

I knew that, and I actually considered to note that, too.  But I chose
the most straightforward explanation to point out that the prefix/IID
len is NOT "open to be configurable/settable by the admin" according
to the protocol specification, in order to avoid unnecessary
distraction.

> non-64-bit IIDs, that all goes out of the window.

I agree that it's one major source of confusion that both addrarch and
link-type specs define the IID length (and the former defines it per
address space basis and the latter defines it for a particular link
type, and therefore these two could easily be inconsistent).  Although
I don't know if that's why we don't have consensus for 4291bis.

Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07?
I'm not sure why we are talking about our favorite topic of 64-bit (or
not) IIDs here:-)  This thread is even more inappropriate for that
topic than 4291bis (even where it's out of scope as it's not feasible
to change that as part of promoting it to IS).  People who want to
discuss the endless IID length debate should really aware of the scope
of the topic.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Aug 2017 20:24:50 +0200

> Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07?

Is  draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 free to use non-64 
prefixes per host?  Or must it use 64bit prefix per host?

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Aug 2017 11:46:59 -0700

At Fri, 18 Aug 2017 20:24:50 +0200,

> prefixes per host?  Or must it use 64bit prefix per host?

As long as it uses SLAAC, the IID (and therefore the prefix for it)
must be 64 bit today, since there's no standard that specifies a
different value.  But I don't think that's the inherent limitation of
this practice; it's just a result of the limitation of the current
standard specs (in fact, it says '"currently" a /64 prefix in Section
4).

In any event, my point below was that as long as this draft talks
about a live practice using today's standards, it doesn't make sense
to discuss whether the choice in those standards (i.e., 64-bit IID) is
good/bad in that context.  If we want to have that discussion that
should take place somewhere else (and not even appropriate for v6ops
in general, since changing that would be most likely to involve a
protocol change).  Especially so when such a discussion always leads
to a non-productive repetition of stating different opinions.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Aug 2017 21:46:18 +0200

Le 18/08/2017 à 20:46, 神明達哉 a écrit :
> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu 
> <[email-masked]> wrote:
[...]
>  to discuss whether the choice in those standards (i.e., 64-bit IID) 
> is good/bad in that context.

I agree.

Maybe the 64bit IID is not a matter of this draft, since this draft is
about prefixes.

The IID length should be discussed in the other WG.

Here, still it makes sense to allow for prefixes shorter than 64 (i.e.
unique /63 prefix per Host, such that it can further grow the network by
becoming a Router).

The draft says:
> a Unique IPv6 prefix (currently a /64 prefix) and some flags.

That "currently a /64" sounds as a hardcoded value.

It should be something like: "a variable length whose value could be /56 
for example; it could also be /64".

Alex

> If we want to have that discussion that should take place somewhere 
> else (and not even appropriate for v6ops in general, since changing 
> that would be most likely to involve a protocol change).  Especially 
> so when such a discussion always leads to a non-productive
> repetition of stating different opinions.
> 
>>> I'm not sure why we are talking about our favorite topic of 
>>> 64-bit (or not) IIDs here:-)  This thread is even more 
>>> inappropriate for that topic than 4291bis (even where it's out
>>> of scope as it's not feasible to change that as part of promoting
>>> it to IS).  People who want to discuss the endless IID length
>>> debate should really aware of the scope of the topic.
> 
> -- JINMEI, Tatuya
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Aug 2017 13:05:34 -0700

Hat off...

Why not simply say "a prefix"? We are perpetually wrapped around an axle with the prefix length, but reading this 20 years from now (which is the perspective one should take in writing an RFC - what will it mean when it's history?) I don't see why they would worry about the exact length someone wanted to assign within their own boundaries.

> On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu <[email-masked]> wrote:
> [...]
>> In any event, my point below was that as long as this draft talks about a live practice using today's standards, it doesn't make sense
>> to discuss whether the choice in those standards (i.e., 64-bit IID) is good/bad in that context.
> 
> I agree.
> 
> It should be something like: "a variable length whose value could be /56 for example; it could also be /64".
> 
> Alex
> 
>> If we want to have that discussion that should take place somewhere else (and not even appropriate for v6ops in general, since changing that would be most likely to involve a protocol change).  Especially so when such a discussion always leads to a non-productive
>>>> I'm not sure why we are talking about our favorite topic of 64-bit (or not) IIDs here:-)  This thread is even more inappropriate for that topic than 4291bis (even where it's out

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 19 Aug 2017 00:12:11 +0200

Le 18/08/2017 à 22:05, Fred Baker a écrit :
> Hat off...
> 
> Why not simply say "a prefix"?

I tend to agree.

Alex

> We are perpetually wrapped around an axle with the prefix length, but
> reading this 20 years from now (which is the perspective one should
> take in writing an RFC - what will it mean when it's history?) I
> don't see why they would worry about the exact length someone wanted
> to assign within their own boundaries.

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Aug 2017 11:05:45 +1000

> Why not simply say "a prefix"? We are perpetually wrapped around an axle with the prefix length, but reading this 20 years from now (which is the perspective one should take in writing an RFC - wha…

I think it matters because prefix length is the compliment of IID
size, and we know that the size and value of an IID has privacy and
security implications.

RFC7421, "Analysis of the 64-bit Boundary in IPv6 Addressing",
suggests that an IID of at least 40 bits is necessary for privacy.

If this draft does not take a position on the size of a prefix given
to a host, it should at least highlight that prefix lengths longer
than /88 can have corresponding IID size related privacy implications,
and may want to reference RFC6973, "Privacy Considerations for
Internet Protocols" and RFC7721, "Security and Privacy Considerations
for IPv6 Address Generation Mechanisms" for more specific IPv6
addressing discussion.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Aug 2017 10:17:01 +0900

If the prefix length changes away from 64 bits it will be a major change
that will affect this document in many ways.

I'd leave as is. It's definitely useful for the uninitiated reader to know
that currently the only prefix size that is valid and accepted by
implementations is 64.

On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker <[email-masked]>
wrote:

> Hat off...
>
> Why not simply say "a prefix"? We are perpetually wrapped around an axle
> with the prefix length, but reading this 20 years from now (which is the
> perspective one should take in writing an RFC - what will it mean when it's
> history?) I don't see why they would worry about the exact length someone
> wanted to assign within their own boundaries.
>
> >> In any event, my point below was that as long as this draft talks about
> a live practice using today's standards, it doesn't make sense
> good/bad in that context.
> >
> > I agree.
> >
> else (and not even appropriate for v6ops in general, since changing that
> would be most likely to involve a protocol change).  Especially so when
> such a discussion always leads to a non-productive
> >>>> I'm not sure why we are talking about our favorite topic of 64-bit
> (or not) IIDs here:-)  This thread is even more inappropriate for that
> topic than 4291bis (even where it's out

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 19 Aug 2017 05:07:01 +0200

> that will affect this document in many ways.

Change? there is no current spec currently requiring the prefix len to 
be 64Ș 4291 and 2464 talk IID len, not prefix len, right?

> I'd leave as is. It's definitely useful for the uninitiated reader to 
> know that currently the only prefix size that is valid and accepted by 
> implementations is 64.

64 could be a footnote(?)

SLAAC/Ethernet's also works with /48 delivered by ISP and filled-up to 
64 by subnetting.

"currently /64" - does it mean it is what this deployment does it now? 
In that case is it maybe INFORMATIONAL rather than BCP?

Alex

> 
> On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hat off...
> 
>     Why not simply say "a prefix"? We are perpetually wrapped around an
>     axle with the prefix length, but reading this 20 years from now
>     (which is the perspective one should take in writing an RFC - what
>     will it mean when it's history?) I don't see why they would worry
>     about the exact length someone wanted to assign within their own
>     boundaries.
> 
>      > On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >
>      >
>      >
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      > [...]
>      >> In any event, my point below was that as long as this draft
>     talks about a live practice using today's standards, it doesn't make
>     sense
>      > It should be something like: "a variable length whose value could
>     be /56 for example; it could also be /64".
>      >
>      > Alex
>      >
>      >> If we want to have that discussion that should take place
>     somewhere else (and not even appropriate for v6ops in general, since
>     changing that would be most likely to involve a protocol change). 
>     Especially so when such a discussion always leads to a non-productive
>     64-bit (or not) IIDs here:-)  This thread is even more inappropriate
>     for that topic than 4291bis (even where it's out
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Aug 2017 12:13:03 +0900

On Sat, Aug 19, 2017 at 12:07 PM, Alexandre Petrescu <
[email-masked]> wrote:

> Change? there is no current spec currently requiring the prefix len to be
> 64Ș 4291 and 2464 talk IID len, not prefix len, right?

Yes, change is the right word. This is because:

   1. This document presumes the use of SLAAC.
   2. The prefix length has to be 128-IID length for SLAAC to work.
   3. RFC 4291 says that IIDs are 64 bits (except for ::/3, which cannot
   currently be assigned to any real deployment).

Therefore if the prefix length was not /64, no hosts would get any
addresses.

"currently /64" - does it mean it is what this deployment does it now? In
> that case is it maybe INFORMATIONAL rather than BCP?
>

/64 is what the deployment must do in order to operate. If it doesn't work,
then we don't document it in an operational working group.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 21 Aug 2017 11:08:48 -0700

At Fri, 18 Aug 2017 21:46:18 +0200,

> for example; it could also be /64".

Today you can't use a prefix for SLAAC unless its length is 64 due to
the facts that
- All today's defined IIDs have 64 bits in length
- Hosts reject the prefix unless the sum of the prefix's length and
  the IID length equals to 128 (which means the prefix length must be
  64) according to RFC4862

You may not like it or might want to say "it doesn't have to be that
way"), but that's the fact today.  As long as
draft-ietf-v6ops-unique-ipv6-prefix-per-host talks about today's
practice, I don't think anything that doesn't work today is in the
scope of this document.

We may or may not choose to include the specific number of 64 in the
doc, on which I don't have a strong opinion.  But ""a variable length
whose value could be /56 for example" is very misleading since /56 for
SLAAC doesn't work today (perhaps "could" tries to express the subtle
nuance, but that would be quite misleading).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 22 Aug 2017 16:15:37 +0200

> nuance, but that would be quite misleading).

Because I agree with you, I will reformulate:

Leaving 64 there comforts operators and equipment manufacturers in ==64 
barriers preventing the network to grow at the edges.

HTTP parallel:  it would be unconceivable to write an I-D with 
'currently' HTTP traffic is in clear, requesting the WG to make it a 
BCP.  Rather suggest HTTPS be BCP.

IPv4 parallel: write an "IPv4-prefix-per-Host" I-D, because 'currently'.

Alex