Subject: SLAAC on non-/64 networks

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Mar 2018 18:06:13 -0300

Folks,

FYI, OpenBSD now ships with RFC7217 support, and in the process, they
have removed the artificial /64 limit, and can do SLAAC on prefixes
shorter and longer than /64 (say, /60, /32, etc.).

Quite cool. -- but even if you disagree, I guess the "FYI" is still
valuable. :-)

P.S.: The reader might enjoy the commit message at:
<https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/slaacd/engine.c#rev1.22>
 :-)

Thanks!

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

---

From: 神明達哉 <[email-masked]>
Date: Sat, 17 Mar 2018 14:21:59 -0700

At Sat, 17 Mar 2018 18:06:13 -0300,

> shorter and longer than /64 (say, /60, /32, etc.).

This doesn't make sense to me - SLAAC as defined in RFC4862 hasn't had
such a limit ('artificial' or not) from the beginning, and no
RFC4862-compliant implementation, such as FreeBSD, should have such
a limitation today.  According to the context, I guess what you actually
mean is that OpenBSD has made SLAAC independent from link-layer
IPv6-over-foo specifications.

Just to be accurate, rather than agreeing or disagreeing with
anything.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Mar 2018 19:03:33 -0300

> IPv6-over-foo specifications.

Isn't the artificial limit introduced by the addressing architecture itself?

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Sat, 17 Mar 2018 15:15:16 -0700

At Sat, 17 Mar 2018 19:03:33 -0300,

> Isn't the artificial limit introduced by the addressing architecture itself?

RFC4291 certainly introduces a /64 constant, but that's irrelevant to
what I tried to point out.

SLAAC primarily refers to link-layer specifications, and whatever
prefix length that is specified in those specifications is possible.
So an SLAAC implementation should be able to do it on prefix shorter
or larger than /64.  I tried to say "(they) can do SLAAC on prefixes
shorter and longer than /64" as if it were new is awkward, since any
RFC4862-compliant implementation should already do that today.

If it were "(they) now ignore the addressing architecture, or make SLAAC
independent from link-layer specs, or (as a subset of it) can do SLAAC
on prefixes other than /64 for (e.g.) ethernet, then I see it.  (And
I actually thought what you actually meant - I just tried to make it
accurate or clearer).

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Sat, 17 Mar 2018 19:53:14 -0300

> prefix length that is specified in those specifications is possible.

My "reading" is that such specs used to some up with a 64-bit IID
because the addressing architecture mandated such length in the first place.

> RFC4862-compliant implementation should already do that today.

One might argue that implementations compatible with RFC4291 shouldn't
-- i.e., that's the culprit for such limitation.

> on prefixes other than /64 for (e.g.) ethernet, then I see it.

RFC8064/RFC7217 (and also RFC4941) made SLAAC independent from the
link-layer -- they don't care about the size of link-layer identifiers.

So, in a way, an implmentation that does RFC7217 has made SLAAC
independent from link-layer specs, and you could probably also say that
if they accept prefixes != 64, they have ignored the addressing
architecture in that respect.

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Mar 2018 13:49:23 +1300

On 18/03/2018 11:53, Fernando Gont wrote:
...
> architecture in that respect.

Or, you could say that the current Draft Standard addressing
architecture is out of date. I think it must be, because there's
a bis version in the drafts repository.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 18 Mar 2018 00:54:50 +0000

> On 18 Mar 2018, at 00:49, Brian E Carpenter <[email-masked]> wrote:
> 
>> ....

Actually there isn’t. 

Ole

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

---

From: 神明達哉 <[email-masked]>
Date: Sun, 18 Mar 2018 02:09:03 -0700

At Sat, 17 Mar 2018 19:53:14 -0300,

> -- i.e., that's the culprit for such limitation.

I don't disagree that RFC421/addarch is in a central position of the
current mess.  My only point is that you should have simply said so,
instead of primarily referring to SLAAC as the implication of SLAAC is
more indirect.  If and when a link-layer that has non-64-bit IID is
standardized an RFC4862-compliant implementation should immediately be
able to use a non /64 prefix without a change - the possible conflict
between such a link-layer spec and addrarch is to be resolved simply
between these two specs.

--
JINMEI, Tatuya

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 11:17:08 +0100

On 2018 Mar 17 (Sat) at 19:53:14 -0300 (-0300), Fernando Gont wrote:
:On 03/17/2018 07:15 PM, 神明達哉 wrote:
:> At Sat, 17 Mar 2018 19:03:33 -0300,
:> Fernando Gont <[email-masked]> wrote:
:> 
:>>>> FYI, OpenBSD now ships with RFC7217 support, and in the process, they
:>>>> have removed the artificial /64 limit, and can do SLAAC on prefixes
:>>>> shorter and longer than /64 (say, /60, /32, etc.).
:>>>
...
:
:RFC8064/RFC7217 (and also RFC4941) made SLAAC independent from the
:link-layer -- they don't care about the size of link-layer identifiers.
:
:So, in a way, an implmentation that does RFC7217 has made SLAAC
:independent from link-layer specs, and you could probably also say that
:if they accept prefixes != 64, they have ignored the addressing
:architecture in that respect.
:

Yes, precisely.  As I pointed out in my commit message, mandating /64 is
a historical mistake.  This was an articifial limitation that was
(likely) added only because EUI-64 was easy to do.  SLAAC includes a
prefixlen field in the wire format, so clearly that was intended to be
available for networks to use.  OpenBSD (and several other OSes) allowed
for non-/64 prefixes to be manually configured on the interface, so this
was an obvious problem to solve.

Please note that the link-local fe80::/64 address is not modified to use
a different prefix size. This *only* has to do with the global unicast
address.

[I had previously sent this email from a different From, so apologies if
this email arrives twice]

-- 
Help fight continental drift.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:05:26 +0100

> what I tried to point out.

And it is because of that constant that all IPv6-over-foo specifications 
make 64 a constant as well.  Moreover: the new drafts developped now (in 
6lo, ipwave, others) all want to be conservative and do how rfc2464 
does, to avoid breaking something.

(I do not agree with that direction, it is just how I see it happening).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:06:31 +0100

>> a bis version in the drafts repository.

It was 'parked', I guess.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:08:16 +0100

I wanted to ask you: does this removal mean that now the system no 
longer complains when receiving an RA with plen 65?

What else does this removal mean, in practice?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:10:41 +0100

> between such a link-layer spec and addrarch is to be resolved simply

I do not know how an Internet Draft with a non-64-bit IID can be written 
without risking being rejected because incompatible with RFC2464.

Alex

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 18:36:25 +0100

On 2018 Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote:
:I wanted to ask you: does this removal mean that now the system no longer
:complains when receiving an RA with plen 65?
:

Yes, exactly.  Example from a VM on my laptop:

 inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf

:What else does this removal mean, in practice?
:

It also means a shorter prefix length will be completely filled with
random data, instead of only the finaly 64-bits of the address.

 inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf

:Alex
:
:Le 17/03/2018 à 22:06, Fernando Gont a écrit :
:> Folks,
:> 
:> FYI, OpenBSD now ships with RFC7217 support, and in the process, they
:> have removed the artificial /64 limit, and can do SLAAC on prefixes
:> shorter and longer than /64 (say, /60, /32, etc.).
:> 
:> Quite cool. -- but even if you disagree, I guess the "FYI" is still
:> valuable. :-)
:> 
:> P.S.: The reader might enjoy the commit message at:
:> <https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/slaacd/engine.c#rev1.22>
:>   :-)
:> 
:> Thanks!
:> 
:> Cheers,
:>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 18 Mar 2018 17:36:56 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu

> I do not know how an Internet Draft with a non-64-bit IID can be
> written without risking being rejected because incompatible with
> RFC2464.

Yes, in this rehash of multiple previous discussions, that is the main point. The /64 barrier was created by this RFC, and the rationale for it has been deprecated. It is RFC 2464 that needs to be revisited.

As another reason why RFC 2464 is overdue for a -bis, I was just thinking, in wired networks, MAC filtering is considered still a valid security measure. Not in wireless, of course, where the packets in flight can be monitored without giving away the intrusion. So, just how useless would MAC filtering be, as a security measure, if the MAC address is right in the IP destination address?

These things made sense when the Internet was still a polite medium.

Bert

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 18:44:04 +0100

On 2018 Mar 18 (Sun) at 17:10:41 +0100 (+0100), Alexandre Petrescu wrote:
:Le 18/03/2018 à 10:09, 神明達哉 a écrit :
:> At Sat, 17 Mar 2018 19:53:14 -0300,
:> Fernando Gont <[email-masked]> wrote:
:> 
:> > > So an SLAAC implementation should be able to do it on prefix shorter
:> > > or larger than /64.  I tried to say "(they) can do SLAAC on prefixes
:> > > shorter and longer than /64" as if it were new is awkward, since any
:> > > RFC4862-compliant implementation should already do that today.
:> > 
:> > One might argue that implementations compatible with RFC4291 shouldn't
:> > -- i.e., that's the culprit for such limitation.
:> 
:> I don't disagree that RFC421/addarch is in a central position of the
:> current mess.  My only point is that you should have simply said so,
:> instead of primarily referring to SLAAC as the implication of SLAAC is
:> more indirect.  If and when a link-layer that has non-64-bit IID is
:> standardized an RFC4862-compliant implementation should immediately be
:> able to use a non /64 prefix without a change - the possible conflict
:> between such a link-layer spec and addrarch is to be resolved simply
:> between these two specs.
:
:I do not know how an Internet Draft with a non-64-bit IID can be written
:without risking being rejected because incompatible with RFC2464.
:
:Alex
:

I don't think that is a problem.  RFC2464 addresses do stay at a prefix
length of 64, and I don't see any reason why that should change.

Changes to RFC4921 would be fairly simple, """Addresses in the fe80::/64
range MUST use a 64-bit IID.  All other global unicast addresses MAY use
any size IID.  A 64-bit IID is RECOMMENDED.""".

Apply the usual templates, normal editing to clean up the wording, etc,
etc.

-peter

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 18:58:11 +0100

>   inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf

Is d322 formed according to RFC7217?

>   inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf

Is f4:5681:1273:8150:90bd:22ed formed according to RFC7217?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:00:11 +0100

> any size IID.  A 64-bit IID is RECOMMENDED.""".

I agree with this:  All other global unicast addresses MAY use
any size IID.

Alex

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 19:09:58 +0100

On 2018 Mar 18 (Sun) at 18:58:11 +0100 (+0100), Alexandre Petrescu wrote:
:
:
:Le 18/03/2018 à 18:36, Peter Hessler a écrit :
:> On 2018 Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote:
:> :I wanted to ask you: does this removal mean that now the system no longer
:> :complains when receiving an RA with plen 65?
:> :
:> 
:> Yes, exactly.  Example from a VM on my laptop:
:> 
:>   inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf
:
:Is d322 formed according to RFC7217?
:
:> :What else does this removal mean, in practice?
:> :
:> 
:> It also means a shorter prefix length will be completely filled with
:> random data, instead of only the finaly 64-bits of the address.
:> 
:>   inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf
:
:Is f4:5681:1273:8150:90bd:22ed formed according to RFC7217?
:

For both: yes.  The RID is generated, then the least-significant
128-bits are taken and folded into the prefix masked with the prefixlen.

These addresses are stable, and reproducable.

-peter

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:24:36 +0100

Le 18/03/2018 à 19:09, Peter Hessler a écrit :
> On 2018 Mar 18 (Sun) at 18:58:11 +0100 (+0100), Alexandre Petrescu
> wrote: : : :Le 18/03/2018 à 18:36, Peter Hessler a écrit : :> On 2018
> Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote: :>
> :I wanted to ask you: does this removal mean that now the system no
> longer :> :complains when receiving an RA with plen 65? :> : :> :>
> Yes, exactly.  Example from a VM on my laptop: :> :>   inet6
> 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf : :Is d322 formed
> according to RFC7217? : :> :What else does this removal mean, in
> practice? :> : :> :> It also means a shorter prefix length will be
> completely filled with :> random data, instead of only the finaly
> 64-bits of the address. :> :>   inet6
> 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf : :Is
> f4:5681:1273:8150:90bd:22ed formed according to RFC7217? :
> 

It's good.

We refer to RFC7217 in IPv6-over-OCB draft in IPWAVE WG:
> Additionally, if semantically opaque Interface Identifiers are
> needed, a potential method for generating semantically opaque
> Interface Identifiers with IPv6 Stateless Address Autoconfiguration
> is given in [RFC7217].

Maybe we should say "MUST" instead of "if needed, then method is in...".

Alex

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Mar 2018 08:03:14 +1300

Bert,

> Yes, in this rehash of multiple previous discussions, that is the main point. The /64 barrier was created by this RFC, and the rationale for it has been deprecated. It is RFC 2464 that needs to be…

That isn't necessary. RFC 8064 updates RFC 2464:

   Nodes SHOULD implement and employ [RFC7217] as the default scheme for
   generating stable IPv6 addresses with SLAAC.
   ...
   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed a stable link-layer address in the IID.  In particular,
   this document RECOMMENDS that nodes do not generate stable IIDs with
   the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491],
   [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338],
   [RFC4391], [RFC5072], and [RFC5121].

and RFC 7217 is quite clear that the length is a parameter:

   2.  The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.

It's RFC 4291 that needs updating. Several of the variants of 4291bis
would have fixed this problem. A more explicit variant wording is
in draft-bourbaki-6man-classless-ipv6-03.

Or we can potter along with obsolete text while running code supports
BCP 198, RFC 8064 and RFC 7217.

   Brian

---

From: 神明達哉 <[email-masked]>
Date: Sun, 18 Mar 2018 13:25:51 -0700

At Sun, 18 Mar 2018 17:10:41 +0100,

> without risking being rejected because incompatible with RFC2464.

RFC2464 only talks about Ethernet, so it doesn't affect "If and when a
link-layer that has non-64-bit IID is standardized..." But if you mean
it's incompatible with RFC4291 (or its latest bis), then you're right.
But then the same logic also applies to this RFC7217 implementation.
So "they (...) can do SLAAC on prefixes shorter and longer than /64"
is awkward - if they care about the compatibility problem with
existing standards, they actually "cannot" do this; if they don't
care, SLAAC already allows that so the fact that "they can do it" is
not really a news.  And so, this is essentially an address
architecture issue, and if it were "they now ignore the /64 limitation
of addrarch", I can see the point.

Anyway, while I originally thought I'd make a fairly trivial
clarification, it looks like I actually triggered a further
confusion.  To avoid contributing to another 100+ message thread, I'll
stop for this thread at this point.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Sun, 18 Mar 2018 17:40:19 -0300

> Alexandre Petrescu <[email-masked]> wrote:
[....]
> of addrarch", I can see the point.

Yes, that's what I meant.

Thanks for the clarification!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 18 Mar 2018 17:41:25 -0300

On 03/18/2018 04:03 PM, Brian E Carpenter wrote:
[.....]
> in draft-bourbaki-6man-classless-ipv6-03.

Fully agree.

> BCP 198, RFC 8064 and RFC 7217.

Agreed here, too.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 22:23:41 +0100

> These addresses are stable, and reproducable.

Does it generate a RID for the link-local address as well?

Alex

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 22:31:31 +0100

On 2018 Mar 18 (Sun) at 22:23:41 +0100 (+0100), Alexandre Petrescu wrote:
:
:
:Le 18/03/2018 à 19:09, Peter Hessler a écrit :
:> On 2018 Mar 18 (Sun) at 18:58:11 +0100 (+0100), Alexandre Petrescu wrote:
:> :
:> :
:> :Le 18/03/2018 à 18:36, Peter Hessler a écrit :
:> :> On 2018 Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote:
:> :> :I wanted to ask you: does this removal mean that now the system no longer
:> :> :complains when receiving an RA with plen 65?
:> :> :
:> :>
:> :> Yes, exactly.  Example from a VM on my laptop:
:> :>
:> :>   inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf
:> :
:> :Is d322 formed according to RFC7217?
:> :
:> :> :What else does this removal mean, in practice?
:> :> :
:> :>
:> :> It also means a shorter prefix length will be completely filled with
:> :> random data, instead of only the finaly 64-bits of the address.
:> :>
:> :>   inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf
:> :
:> :Is f4:5681:1273:8150:90bd:22ed formed according to RFC7217?
:> :
:> 
:> For both: yes.  The RID is generated, then the least-significant
:> 128-bits are taken and folded into the prefix masked with the prefixlen.
:> 
:> These addresses are stable, and reproducable.
:
:Does it generate a RID for the link-local address as well?
:
:Alex
:

Yes, those are /64.

 inet6 fe80::751a:3467:99b4:1f8e%vio0 prefixlen 64

-peter

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 22:40:24 +0100

> :Does it generate a RID for the link-local address as well?

Are they virtual interfaces or real interfaces?

If they are virtual interfaces I dont think they should be /64 for LL, 
nothing requires them to.

Alex

---

From: Peter Hessler <[email-masked]>
Date: Sun, 18 Mar 2018 22:55:51 +0100

On 2018 Mar 18 (Sun) at 22:40:24 +0100 (+0100), Alexandre Petrescu wrote:
:Le 18/03/2018 à 22:31, Peter Hessler a écrit :
:> On 2018 Mar 18 (Sun) at 22:23:41 +0100 (+0100), Alexandre Petrescu wrote:
:> :Le 18/03/2018 à 19:09, Peter Hessler a écrit :
:> :> On 2018 Mar 18 (Sun) at 18:58:11 +0100 (+0100), Alexandre Petrescu wrote:
:> :> :
:> :> :
:> :> :Le 18/03/2018 à 18:36, Peter Hessler a écrit :
:> :> :> On 2018 Mar 18 (Sun) at 17:08:16 +0100 (+0100), Alexandre Petrescu wrote:
:> :> :> :I wanted to ask you: does this removal mean that now the system no longer
:> :> :> :complains when receiving an RA with plen 65?
:> :> :> :
:> :> :>
:> :> :> Yes, exactly.  Example from a VM on my laptop:
:> :> :>
:> :> :>   inet6 2001:67c:12f4:2500:112::d322 prefixlen 112 autoconf
:> :> :
:> :> :Is d322 formed according to RFC7217?
:> :> :
:> :> :> :What else does this removal mean, in practice?
:> :> :> :
:> :> :>
:> :> :> It also means a shorter prefix length will be completely filled with
:> :> :> random data, instead of only the finaly 64-bits of the address.
:> :> :>
:> :> :>   inet6 2001:67c:12f4:5681:1273:8150:90bd:22ed prefixlen 56 autoconf
:> :> :
:> :> :Is f4:5681:1273:8150:90bd:22ed formed according to RFC7217?
:> :> :
:> :>
:> :> For both: yes.  The RID is generated, then the least-significant
:> :> 128-bits are taken and folded into the prefix masked with the prefixlen.
:> :>
:> :> These addresses are stable, and reproducable.
:> :
:> :Does it generate a RID for the link-local address as well?
:> :
:> :Alex
:> :
:> 
:> Yes, those are /64.
:
:Are they virtual interfaces or real interfaces?
:
:If they are virtual interfaces I dont think they should be /64 for LL,
:nothing requires them to.
:
:Alex

OpenBSD doesn't treat virtual interfaces differently than "real"
interfaces.  In most cases, virtual interfaces are an emulated Ethernet
device.

-peter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Mar 2018 11:00:49 +1300

> nothing requires them to.

That's a case where the SHOULD proposed for 4291bis would apply.
There's certainly nothing wrong with /64 as a choice.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 07:09:48 +0900

On Sun, Mar 18, 2018 at 7:17 PM, Peter Hessler <[email-masked]> wrote:

> (likely) added only because EUI-64 was easy to do.

Actually, it is removing the fixed /64 size that would be a historical
mistake. Removing the 64-bit IID rule will in practice result in subnets
that are too small to accommodate multiple addresses per device, resulting
in the negative consequences listed, among others, in RFC 7934.

Additionally, doing SLAAC on a long prefix is a really bad idea as it is
very likely to cause IID collisions and thus cannot guarantee that RFC7217
addresses will be stable. Example: in a /112 subnet, there is a 50% chance
of collision at just ~250 hosts. With privacy addresses enabled, the chance
of collision goes up very rapidly, and with the default of 7 privacy + 1
stable address per host, there's a 50% chance of collision even with just
~30 hosts on the subnet.

Worse, if the subnet is wifi and used by mobile devices that rate-limit
multicast (which most devices do these days), address collisions don't
result in DAD failure but in total loss of IPv6 connectivity.

Cutting subnets to size was necessary in IPv4 because IPv4 has so little
address space. But there are 4 billion times more /64s than there are IPv4
addresses, so those limits don't apply to IPv6.

---

From: Erik Kline <[email-masked]>
Date: Sun, 18 Mar 2018 15:25:43 -0700

> addresses, so those limits don't apply to IPv6.

Agreed, absolutely.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Mar 2018 13:56:38 +1300

On 19/03/2018 11:09, Lorenzo Colitti wrote:
> Additionally, doing SLAAC on a long prefix is a really bad idea

If "long" means >80 or thereabouts, most people would agree with you.
But it's hard to make that argument if "long" means, say, 72. If we
hadn't been distracted by FireWire back in ~1995 it would have been
/80 anyway.

In any case, the cat's out of the (BSD) bag by now. It's implementers
who fix inconsistencies that the IETF leaves in its standards.

   Brian

> as it is

---

From: David Farmer <[email-masked]>
Date: Sun, 18 Mar 2018 21:20:17 -0500

On Mar 18, 2018, at 17:09, Lorenzo Colitti <[email-masked]> wrote:

With a significant reduction in IID size, I completely agree. However, a
small reduction in IID size, maybe up to 8 bits, shouldn’t cause any real
problems. Therefore, an absolute value of 64 isn’t necessary, except for
the case of link-local, which need a fixed size.  Also, a small reduction
in IID size can be advantageous for some specific situations, but 64 bits
is the recommended IID size.

Very short IIDs, especially when used with general-purpose hosts, are a bad
idea for many reasons, all discussed in RFC7421, and should not be used in
most cases, except for maybe point-to-point router link.

There are several possible mitigations for the multicast issues you
describe. Most WiFi systems include one or more of these mitigations, even
frequently consumer-grade products, and virtually all enterprises-grade
systems do.

If you know how to get most, if not all, ISPs to allocate more than a /64
to there customers, then I’d be happy with an absolute value of 64 for the
IID size. However, in my experience, that isn’t happening most of the time,
and even when it is possible to get more than a /64 from an ISP, it
frequently requires a special request.

In a utopian world, an absolute value of 64 bits for the IID size would
fine, but IPv6 has to be deployed in the real world. So, it's time for the
IPv6 Addressing Architecture to recognize how IPv6 is being deployed in the
real world, which is most of the time the IID size is 64 bits, but
sometimes it's not, and that's just fine.

Get over it, please!

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 19 Mar 2018 08:07:18 +0000

+1

Lorenzo pointed out sufficient reasons and I'm sure there are many more.

Even just consider that comparing IPv4 space with IPv6 space is comparing the smaller insect with the bigger whale we can find in the earth, and  consequendly removing the fixed /64 will be the worst thing I can imagine we can do. So please, don't even consider it.

Regards,
Jordi
 
-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Erik Kline <[email-masked]>
Fecha: domingo, 18 de marzo de 2018, 22:26
Para: Lorenzo Colitti <[email-masked]>
CC: IETF IPv6 Mailing List <[email-masked]>, Peter Hessler <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    Agreed, absolutely.

**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 17:20:32 +0900

> hadn't been distracted by FireWire back in ~1995 it would have been

Good thing we weren't, I'd say. You may have noted that the example in the
commit message is /112, which is too short for random allocation except in
the smallest of networks.

> who fix inconsistencies that the IETF leaves in its standards.

It's not an inconsistency, it's pretty clearly a violation of 4291 to
autoconf a non-64-bit IID on a prefix that's not in ::/3. It remains to be
seen what popular implementations will do.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 09:53:21 +0000

> frequently requires a special request.

Actually I believe that's not true. In my experience most ISPs will hand
out more than /64 either by default or if the CPE hints that it will accept
more than /64. I've heard firsthand that several large networks only hand
out /64 because of a number of CPEs exhibited the unfortunate behaviour of
taking the delegated prefix and announcing it in the RA, which of course
doesn't work at all if the prefix is not 64 bits long. Those networks will
hand out more than /64 if the CPE asks for it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 10:03:44 +0000

> sometimes it's not, and that's just fine.

No, sorry. We need to do better than that. Saying "get over it" is just
dodging a bunch of hard questions, and here's why.

Let's say we do get over it, and the de facto ISP assignment becomes 64.
What happens next? I suppose your recommendation is that we modify hosts to
accept non-64 prefix lengths. What lengths should hosts accept? Should they
do what openbsd has done and remove the limit entirely, accepting /126,
/127 and /128? What should a device do when it gets a /120? Should it
disable privacy addresses? Should the network actively police hosts by
aggressively sending DAD replies if a host configures more than one IPv6
address? What does that mean for the IPv6 address assignment best practices
published in RFC 7934? What do you suggest we recommend to network
operators that say, "we have a /24 for this subnet, we should therefore
allocate a /120 for it"? From your previous experience I think you don't
think that's a good idea, but what would you advise instead?

So suppose we react to the preceding paragraph by saying, "ok, the maximum
prefix length that hosts should do autoconf on is X", where X != 64. The
questions then become: what should X be? Brian says we should have X=72.
Peter used X=112. Let's say we pick a number out of thin air: /83. How is
/83 different from /64? If /83 works on all hosts, what happens if/when
network operators start using /83? Do we turn the crank again from /83 to
/89? If so, when does that end?

The thing about /64 is that it *always has space*. If you remove that
limit, then suddenly you have all these hard questions to answer. In the
absence of an answer, I promise you that what will happen is what is
happening in IPv4: one IP address per device, and network-assigned IP
addresses. This is the most likely outcome, simply because the industry
knows how to do it because they've been doing it for 20 years.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 19 Mar 2018 11:10:09 +0100

> in the negative consequences listed, among others, in RFC 7934.
<snip>

well said.

-- 

Roger Jorgensen
[email-masked] / [email-masked]

---

From: Karl Auer <[email-masked]>
Date: Mon, 19 Mar 2018 21:53:28 +1100

On Mon, 2018-03-19 at 10:03 +0000, Lorenzo Colitti wrote:
> No, sorry. We need to do better than that. Saying "get over it" is
> just dodging a bunch of hard questions, and here's why.

A HUGE amount of painstaking work by thousands of people has gone into
designing and implementing NUMEROUS interlocking standards that assume
or predicate /64 for SLAAC.

If you take it away, nearly all of that work is invalidated.

Doeesn't seem like a good plan to me.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75
Old fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A

---

From: Mark Smith <[email-masked]>
Date: Mon, 19 Mar 2018 22:09:03 +1100

+1

What problem is being solved, and is supporting arbitrary sized IIDs
the best way to solve it?

When the IPv6 address space is 73 billion billion times larger than
IPv4's (i.e. 2^96), why are some people trying to carry over their
IPv4 addressing practices for address scarcity when there is no need
to? How will allowing arbitrary sized IIDs change that address space
scarcity mindset?

I'm reminded of something I recently came across - "What you allow you
encourage.” - Michael Josephson

Regards,
Mark.

---

From: Wilco Baan Hofman <[email-masked]>
Date: Mon, 19 Mar 2018 12:26:52 +0100

+1

What problem is being solved? I can think of only one problem, which is
neighbor table exhaustion.. and I think that is better fixed by moving
Neighbor discovery to a subscription model instead of a discovery model.
Discovery takes up to the entire available address space, while
subscription takes up to the number of nodes in the network, which
should be vastly less.

For 802.11, a subscription model is already a necessity and already the
case through WiFi controllers that Proxy-ARP/Proxy-NDP on behalf of the
clients.

Fixing NDP would make more sense to me than creating address space
collisions by allowing SLAAC on less than 40 bits. It would even allow
for a more elegant way to limit broadcast traffic on 802.11 networks.

On naive 802.11 networks that rate-limit all multicast equally, these
collisions will break IPv6-connectivity altogether..

Regards,

Wilco

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 11:36:41 +0000

On 03/19/2018 09:53 AM, Lorenzo Colitti wrote:
> On Mon, Mar 19, 2018 at 2:20 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>>     Cutting subnets to size was necessary in IPv4 because IPv4 has so
>>     little address space. But there are 4 billion times more /64s than
>>     there are IPv4 addresses, so those limits don't apply to IPv6.
>     If you know how to get most, if not all, ISPs to allocate more than
>     a /64 to there customers, then I’d be happy with an absolute value
>     of 64 for the IID size. However, in my experience, that isn’t
>     happening most of the time, and even when it is possible to get more
>     than a /64 from an ISP, it frequently requires a special request.
> 
> 
> out more than /64 either by default or if the CPE hints that it will
> accept more than /64. 

I can tell you that the above is true in many cases. Both major ISPs in
Argentina, and Telefonica in Peru handle /64s.

So it's not a matter of beliefs.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 11:46:59 +0000

On 03/19/2018 10:03 AM, Lorenzo Colitti wrote:
>     In a utopian world, an absolute value of 64 bits for the IID size
>     would fine, but IPv6 has to be deployed in the real world.. So, it's
>     time for the IPv6 Addressing Architecture to recognize how IPv6 is
>     being deployed in the real world, which is most of the time the IID
>     size is 64 bits, but sometimes it's not, and that's just fine.
>       
>     Get over it, please!
> 
> 

In many ISPs it has already become. But in any case, the suggestion to
remove the hard-limit of /64 is not because of what ISPs are doing, but
actually because it reduces flexibility unnecessarily.

> What happens next? I suppose your recommendation is that we modify hosts
> to accept non-64 prefix lengths. What lengths should hosts accept?
> Should they do what openbsd has done and remove the limit entirely,
> accepting /126, /127 and /128? What should a device do when it gets a
> /120? Should it disable privacy addresses? Should the network actively
> police hosts by aggressively sending DAD replies if a host configures
> more than one IPv6 address? What does that mean for the IPv6 address
> assignment best practices published in RFC 7934? What do you suggest we
> recommend to network operators that say, "we have a /24 for this subnet,
> we should therefore allocate a /120 for it"? From your previous
> experience I think you don't think that's a good idea, but what would
> you advise instead?

If you look into
<https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03>, it
does remove the hard limit, while keeping the recommendation to do /64.
Th two are not mutually exclusive.

> So suppose we react to the preceding paragraph by saying, "ok, the
> maximum prefix length that hosts should do autoconf on is X", where X !=
> 64. The questions then become: what should X be? Brian says we should
> have X=72. Peter used X=112. Let's say we pick a number out of thin air:
> /83. How is /83 different from /64? If /83 works on all hosts, what
> happens if/when network operators start using /83? Do we turn the crank
> again from /83 to /89? If so, when does that end?

You don't need to pick a number. Just follow the algorithm. If a dumb
admin advertised a prefix that is that short, with many systems on-link,
then the outcome is the expected outcome: some things would not work as
expected (e.g., host might not be able to configure temporary addresses).

But as noted before, removing the hard limit does not mean removing a
recommendation of what size we expect networks to use (/64), but rather
making sure that other prefixes lengths can work as well if the admin
decides to do something else.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 19 Mar 2018 12:55:49 +0000

Yes, that's true, many operators, especially in LAC region, despite how much training we have done there, got it wrong and deliver /64 only to the customers.

But this is just ignorance and bad practices. They believe this way they will be able to sell more services by charging for extra /64, the same way they charge for static IPv4.

It is not our business to correct their really bad practices against all kind of standards and policies. Market competition will do that.

Regards,
Jordi
 
-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Fernando Gont <[email-masked]>
Fecha: lunes, 19 de marzo de 2018, 11:37
Para: Lorenzo Colitti <[email-masked]>, David Farmer <[email-masked]>
CC: IETF IPv6 Mailing List <[email-masked]>, Peter Hessler <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    
    Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 14:24:01 +0100

>> in the negative consequences listed, among others, in RFC 7934.

This is a solution to a problem statement that does not exist.

    Method to avoid a race to the bottom, satisfy RFC7934
and ensure long life scalability of the size of the Internet.

1. read and understand the spirit of RFC7934.
2. if you get a /64 from your operator and need more than just one
    subnet then ask the operator for a /63.
3. use DHCPv6-PD to get a /63.
4. if again you need that then ask again.
4.1 point your operator to RIR statements who give them abundant space.
5. as last resort, make two /65s out of the /64 for two networks
    and consider yourself happy. Use IIDs from RFC 7217 "Opaque IDs for
    SLAAC".
6. if that is not enough then make 4 /66 out of the /64 for 4 subnets.
    One-by-one increment, not by-two, nor more.
7. avoid to make too quickly too many subnets if you only need just a
    few.
8. be prepared one day somebody else will ask _you_ to give her a /64.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 13:29:07 +0000

> Th two are not mutually exclusive.

But that document doesn't answer the questions I asked above.

> expected (e.g., host might not be able to configure temporary addresses).

Sure, you can just remove the limit like openbsd has done". My point is
that there are lots of problems with that. Your email doesn't answer any of
them except by saying, "if an admin chooses something that's too small,
stuff won't work". That's not a good solution.

---

From: David Farmer <[email-masked]>
Date: Mon, 19 Mar 2018 08:56:43 -0500

> 4.1 point your operator to RIR statements who give them abundant space.

I'd even add;
4.2 find a diffrent provider that will allocate more than a /64.

> 8. be prepared one day somebody else will ask _you_ to give her a /64.

Market competition can fix this issue in many cases. However, many places
in the world do not have real competition, what do those users do then?

So, yes if we keep the /64 fixed boundary, the bottom never gets to /128,
but with the /64 fixed boundary, too many users are already at the bottom
with little or no recourse.

-- 
===============================================
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: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 13:58:53 +0000

> with little or no recourse.

The former is vastly better than the latter. If you're stuck at /64, you
can still allocate as many IPv6 addresses to as many devices as you want,
using bridging. If you're stuck at /128, the only thing you can do is NAT.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 15:01:51 +0100

Le 19/03/2018 à 14:58, Lorenzo Colitti a écrit :
> On Mon, Mar 19, 2018 at 1:56 PM, David Farmer <[email-masked] 
>     So, yes if we keep the /64 fixed boundary, the bottom never gets to
>     /128, but with the /64 fixed boundary, too many users are already at
>     the bottom with little or no recourse.
> 
> 
> can still allocate as many IPv6 addresses to as many devices as you 
> want, using bridging. If you're stuck at /128, the only thing you can do 
> is NAT.

But bridging won't get one as far as routing does.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 12:50:39 +0000

> the best way to solve it?

Among others, it allows you to extend your network in whatever way you
please. With the hard limit of /64, you'd have to resort to NAT, or ugly
hacks.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 14:25:31 +0000

> want, using bridging. If you're stuck at /128, the only thing you can do

Again, removing the hardcoded limit does not change the recommendation
on how much address space to give users.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 14:55:42 +0000

On 03/19/2018 01:29 PM, Lorenzo Colitti wrote:
> On Mon, Mar 19, 2018 at 11:46 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     If you look into
>     <https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03
>     <https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03>>, it
> that there are lots of problems with that. Your email doesn't answer any
> of them except by saying, "if an admin chooses something that's too
> small, stuff won't work". That's not a good solution.

Should the I-D have an "Idiocy Considerations" section?

Seriously, the document recommends /64 as a SHOULD. In order to g
against the SHOULD, you are supposed to know what you do.

---

From: Erik Kline <[email-masked]>
Date: Mon, 19 Mar 2018 08:14:59 -0700

> on how much address space to give users.

That makes zero difference. If the providing network is already going
against RFC 6177:

"""
                                        ...   Hence, this document
still recommends
   giving home sites significantly more than a single /64, but does not
   recommend that every home site be given a /48 either.
"""

why on Earth should we think this would produce any better outcome.
If the limit had been /80 in 1995, users would be stuck with a single
/80 at home.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 15:29:39 +0000

> If the limit had been /80 in 1995, users would be stuck with a single

As you start chainining one network after another, no matter where you
started, you may get to /64 and may need to go smaller.

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Mar 2018 06:21:44 +1100

> please. With the hard limit of /64, you'd have to resort to NAT, or ugly

The same can be said about /80, /96, /112, etc. - any value right up to and
including /128.

Removing this limit isn't going to make things better, it is accommoding
and can be used to justify making things worse.

Right now, the answer of whether end-user networks are getting enough
address space is easy and binary - are they getting enough /64s to number
their individual links or not. The answer is either yes or no, and if the
answer is no, then their provider is being unnecessarily precious.
Customers can push back on their providers being unnecessarily precious,
because the answer is easy to determine and binary.

If the /64 boundary goes, the answer becomes "it depends on how many links
they have, the variety of prefix lengths they're using on those links, and
how many addresses per host they need now and think they'll need in the
future.". I'd expect those who are in a position to allocate address space
to these end-sites, and who carry over their IPv4 addressing practices and
assumptions, would likely assume 1 address per host, as that is also what
they're used to from IPv4 (and what we've had to do in IPv4).

We'll end up with the complexity and cost of IPv4's variable length
addressing in IPv6, unnecessarily, and none of IPv6's host multi-addressing
and privacy address benefits.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Mar 2018 19:47:50 +0000

On 03/19/2018 07:21 PM, Mark Smith wrote:
> The same can be said about /80, /96, /112, etc. - any value right up to
> and including /128.

Exactly: There's no need to hardcode any specific value. That has
*nothing* to do with architecture.

> address space is easy and binary - are they getting enough /64s to
> number their individual links or not. The answer is either yes or no,
> and if the answer is no, then their provider is being unnecessarily
> precious. Customers can push back on their providers being unnecessarily
> precious, because the answer is easy to determine and binary.

This last bit is unreal. In many places, there are monopolies or
oligopolies. Besides, the normal user may not even know what an "IP
address" is.

Besides, as noted, removing the hard limit would not change the existing
recommendations to give plenty of space to users, or use /64 for SLAAC.
So you'd still have material to go fight your ISP if they were to give
you less than /64, because they would nt be following our advice.

> If the /64 boundary goes, the answer becomes "it depends on how many
> links they have, the variety of prefix lengths they're using on those
> links, and how many addresses per host they need now and think they'll
> need in the future.". I'd expect those who are in a position to allocate
> address space to these end-sites, and who carry over their IPv4
> addressing practices and assumptions, would likely assume 1 address per
> host, as that is also what they're used to from IPv4 (and what we've had
> to do in IPv4).

You either publish specs by people that can read, or you don't.

Removing the hardcoded /64 has nothing to do with how much space you
give users, but rather with whether things should work if one were to
decide to use a different value.

I do want to get more than /64 from my ISP. But wouldn't want to NAT or
not be able to extend my network as I please because the magic number
"64" was casted into stone for historical reasons.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 20 Mar 2018 08:29:32 +1100

On Tue, Mar 20, 2018 at 6:21 AM, Mark Smith <[email-masked]> wrote:
> Removing this limit isn't going to make things better, it is accommoding and
> can be used to justify making things worse.
>
> answer is no, then their provider is being unnecessarily precious. Customers
> can push back on their providers being unnecessarily precious, because the
> answer is easy to determine and binary.
>

+2^128 ;)

That was spoken well.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Tue, 20 Mar 2018 08:52:15 +1100

On Mon, Mar 19, 2018 at 11:50 PM, Fernando Gont <[email-masked]> wrote:
> please.

What's the use case for this?

Removing the /64 limit is harmful long-term. You start with /65, then
/70 and very soon we'll see not just /112 but /120 ("because we've
been always assigning /24 IPv4 here"). Then we'll end up in that
horrible mess of "shall this subnet has 32 addresses or 16 would be
enough?", "or damn, the previous admin assigned /122 and now I have to
renumber to /120" and "let's spend another week discussing the address
plan, in particular the topic of choosing between /120 and /121 for
this VLAN". I've been there, done that in IPv4 world and I hoped it's
all over. Apparently not.

/64 was (besides other things) a safety lock. I do not need to think
about "how many addresses do I need in this vlan", you just can not
get it wrong. Removing it has serious consequences from operational
perspective.

To go down this slippery slope we need a very, very good reason. It
might be that my Gmail filters are way too aggressive but so far I've
not heard any convincing reason. "I just want /66" or "I might want it
one day for reasons still to be discovered" do not sound really
convincing.  Does anyone have any examples of real issues which are
hurting users or operators and could not be solved unless /64 limit is
removed?

P.S. If "I want to run my network in whatever way I please" is a
reason good enough to do things which will inevitably do some harm, I
wish we used that argument while discussing Extension Headers
extensions on the fly...I want to do it in my network!

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Mar 2018 11:47:17 +1300

> all over. Apparently not.

Yes, many of us have been there, and don't want to go there again.
On the other hand, we now expect prefix and address assignment to
be automated, even autonomic, so that the discussion will be between
computers, and will take milliseconds, not weeks. This is not
science fiction. Some types of networks are going to do this,
whatever the IETF says.

> extensions on the fly...I want to do it in my network!

You aren't alone. There's a trend towards domain-local solutions
in general. Again, the IETF can't stop it.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Mar 2018 11:50:17 +1300

> seen what popular implementations will do.

The inconsistency is that RFC 4291 makes it a global setting and RFC 4862
and BCP 198 make it a floating boundary.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Mar 2018 22:57:45 +0000

> and BCP 198 make it a floating boundary.

There is no inconsistency.

RFC 4862 defines an algorithm that has a parameter.
RFC 4861 sets the value of the parameter, which happens to be "64 bits for
every global unicast prefix that's not in ::/3".
BCP 198 is irrelevant: it talks about routing, not addressing.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 19 Mar 2018 22:53:27 -0700

> to? How will allowing arbitrary sized IIDs change that address space

Back when we started this exercise in the 90s I don't think we quite
understood that what NAT/PAT was buying us apart from an expansion of
identifiers in into the source port space and therefore downward
pressure on address consumption was a freedom from coordination between
networks. Not that you should, but you can stack an essentially
arbitrary number of PAT translators with their usability essentially
bounded only by the availability of identifier mappings on the
outer-most one.

By the time we solved the problem of how to request and receive an
actual prefix assignment with dhcp PD around 2003 coordination using the
model use for direct address asignment that DHCP was intended to address
was back. Prior to that our major answer was well you can just bridge
since your subnet is huge, which ultimately is a terrible answer since
everything devolves to ND entries, a lot of signaling, and necessarily
information leakage since attaching more devices downstream results in
layer-2 adjacency.

With PD you can coordinate until until the upstream delegater choses not
to give you anymore and therefore limits the prefix size you can receive
to below your needs, or your build a deep enough stack that you cannot
further subdivide prefix assignments. at which point you're back to
bridging or some other mechanism that can be unilaterally employed.

Unilateral allocation of the identifier space is largely opaque to the
upstream networks in contrast to coordinated methods. That always has an
appeal as when dealing with relationships when what you want
(identifiers assigned to downstream devices), is not readily forthcoming.

By way of example of the coordination problem not necessarily of
subnetting, I get a PD delegate from my home CPE (which requested and
recieved a /60, so in that case the VMs in my intel NUC can use
identifiers, on my office network (which has a /48 assigned) with my
laptop I just get slaac, so coordination is right out in that case, as
is bridging since 802.1x authetication is anchored to the in use  mac
address...

joel

---

From: Sander Steffann <[email-masked]>
Date: Tue, 20 Mar 2018 11:20:43 +0000

Hi Jen,

> Op 19 mrt. 2018, om 21:52 heeft Jen Linkova <[email-masked]> het volgende geschreven:
> 

+1

Thanks,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2018 03:02:08 +0000

On 03/19/2018 09:52 PM, Jen Linkova wrote:
> been always assigning /24 IPv4 here").

Can you tel me where we were suggesting that ISPs lease clients prefixes
that are that short?

> hurting users or operators and could not be solved unless /64 limit is

I get a /64 from my ISP, and want multiple subnets. -- Or, "I get a /64
from whatever device is providing connectivity to me, and I want mltiple
subnets or provide further connectivity to other nodes in different
subnets".

> extensions on the fly...I want to do it in my network!

I don't follow. I never argued that you shouldn't do what you please in
your network. The thing that I have pointed out is that if you plan to
do that on the Internet, you have small chances of succeeding (e.g.
RFC7872).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 16:38:42 +0000

> Can you tel me where we were suggesting that ISPs lease clients prefixes

You're not following Jen's argument at all. Obviously, ISPs can't lease
clients /120 prefixes because they don't work today. Her argument is that
if they can be made to work, then ISPs could lease them. One of the
arguments for allowing longer than /64 prefixes, made earlier in this
thread,  is that some ISPs only hand out the maximum length prefix that
will work (which today means /64). If that's true, then it's plausible to
say that if the maximum acceptable prefix length changes, some ISPs will
hand out that length.

> subnets or provide further connectivity to other nodes in different

And once you can form, say, multiple /80 subnets from that /64, why
wouldn't your ISP or upstream device provide you with an /80 instead?

---

From: Jen Linkova <[email-masked]>
Date: Wed, 21 Mar 2018 03:40:40 +1100

> on how much address space to give users.

Fact #1: Subnets have fixed boundary of 64 bits, so addresses could be
given to users in blocks of /64.
Fact #2: There are recommendations that ISPs should give users more
that one /64.
Fact #3: Some operators are known to ignore such recommendations and
give users *one* /64 (as it's the absolute minimum they can give).

Question: what would happen if the boundary could be more that 64
bits? tick one box:
a) those operators will suddenly start following recommendations and
give users more that one /64
b) those operators will keep giving users one /64
c) those operators will discover than they can give users
/65.../66....up to /128 but will follow recommendations and give users
more that one /64
d) those operators will discover than they can give users
/65.../66....up to /128 and will be happily doing so
e) Other options....

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Mar 2018 16:48:37 +0000

On 20 Mar 2018, at 16:38, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Mar 20, 2018 at 3:02 AM, Fernando Gont <[email-masked]> wrote:
> You're not following Jen's argument at all. Obviously, ISPs can't lease clients /120 prefixes because they don't work today. Her argument is that if they can be made to work, then ISPs could lease them. One of the arguments for allowing longer than /64 prefixes, made earlier in this thread,  is that some ISPs only hand out the maximum length prefix that will work (which today means /64). If that's true, then it's plausible to say that if the maximum acceptable prefix length changes, some ISPs will hand out that length.
>  
> And once you can form, say, multiple /80 subnets from that /64, why wouldn't your ISP or upstream device provide you with an /80 instead?

+1, please let's avoid that race to the bottom...

Tim

---

From: Jen Linkova <[email-masked]>
Date: Wed, 21 Mar 2018 03:50:33 +1100

> Can you tel me where we were suggesting that ISPs lease clients prefixes

Were we suggesting that ISPs lease clients just one /64? We were  not.
Now tell me: are there ISPs giving uses *just one* /64?
If the answer is 'no', than there is no use case for removing the
fixed /64 boundary, as your ISP gives you enough subnets.
If the answer is 'yes' then we have just proved that:
1) some ISPs have not been listening to our recommendations;
2) some ISPs give customers the absolute minimum of addresses
(currently it's one /64).
Taking this into account, how probable is that  if we change that
absolute minimum to smth longer than /64, they will start giving you
longer prefix? The longest one which would still work/gets accepted by
your device? And how soon that prefix will become /128?

> subnets or provide further connectivity to other nodes in different

So now, when you allow your ISP to give you /120, your use case
becomes 'oh, I get a /120 and need multiple subnets.
You'll inevitably end up in 'oh, I get a /128 and I want multiple
subnets...oh wait...'

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 20 Mar 2018 17:01:25 +0000

The best we can do is to make sure that the ISPs that use IPv6 the same way as IPv4 and provide the customers a single /64 is to read:

https://www.ripe.net/publications/docs/ripe-690

Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose

May be we need to amend RFC6177:

It currently says: " A key principle for address management is that end sites always be
      able to obtain a reasonable amount of address space for their
      actual and planned usage, and over time ranges specified in years
      rather than just months.  In practice, that means at least one
      /64, and in most cases significantly more.  One particular
      situation that must be avoided is having an end site feel
      compelled to use IPv6-to-IPv6 Network Address Translation or other
      burdensome address conservation techniques because it could not
      get sufficient address space."

I think we should have a much stronger and clear language and go back to the /48 recommendation for all end-sites and any ISP not following that is not following standards. *End of the history*

Regards,
Jordi

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Mar 2018 10:02:35 -0700

> Fact #2: There are recommendations that ISPs should give users more
I don't recall it being possible in a standardized way to delegate a
prefix shorter than a /64 without using stateful dhcpv6 and PD. unless
you're suggesting 62/63/61/60 bit iid(s) and that doesn't exactly help
you with subnetting... That's a bit of a coordination problem for
platforms (LTE) or devices (say Android) where the operator or developer
choose not to offer or use PD or stateful coordination generally.
> give users *one* /64 (as it's the absolute minimum they can give).
In many cases the ability to offer shorter than a /64 is also
proscribed. that's a bit of an imagination failure on our part. so
instead we get things that don't require coordination such as Proxy-ND
and we impose our own event horizons.

---

From: Job Snijders <[email-masked]>
Date: Tue, 20 Mar 2018 17:13:12 +0000

> your device? And how soon that prefix will become /128?

This argument cuts both ways - what if indeed you only get a /64 -
then your only
means of growing your network (without permission from the ISP) is to
stretch the
layer-2 domain endlessly, right? Seems a bit silly to have endless
layer-2 stretching
while there obviously is sufficient IP space to make a beautifully
routed network.

We've branched out across this argument before, and I don't think we came to a
common view and agreed on what is more important in that regard.

Kind regards,

Job

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2018 16:56:31 +0000

On 03/20/2018 04:38 PM, Lorenzo Colitti wrote:
> On Tue, Mar 20, 2018 at 3:02 AM, Fernando Gont <[email-masked]
> clients /120 prefixes because they don't work today.

Side question: do you think that's the case because SLAAC
implementations check whether the announced prefix falls within the /3
on which /64 is mandated, or rather non-/64 will not work regardless of
whether the advertised prefix belongs (or not) to the /3 on which we
have mandated /64?

> Her argument is
> that if they can be made to work, then ISPs could lease them. One of the
> will work (which today means /64). If that's true, then it's plausible
> to say that if the maximum acceptable prefix length changes, some ISPs
> will hand out that length.

If that's true. But you (no me) don't know whether that's the case. If
you think our recommendations in the area 8like one prefix per host) are
a no-op, then I wonder why you cared to make them.

> wouldn't your ISP or upstream device provide you with an /80 instead?

What I would expect is that my ISP follow the recommendations in that
area. Removing the hardcoded /64 has nothing with changing that
recommendation.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 17:37:40 +0000

> whether the advertised prefix belongs (or not) to the /3 on which we

You got it the wrong way around. There is no /3 in which /64 is mandated.
There is only a /3 in which /64 is optional. That /3 is not really relevant
to autoconf because at this time it cannot be used for unicast addressing
of actual hosts.

> area. Removing the hardcoded /64 has nothing with changing that

If ISPs follow the recommendations and always provide enough address space
for users, there's no need to allow longer than /64 prefixes.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 21 Mar 2018 04:43:59 +1100

> area. Removing the hardcoded /64 has nothing with changing that

Sorry, it might be just me being stupid but I can not understand why
do you think that your ISP which has not been following
recommendations and gave you just one /64, would suddenly start
following recommendations and would not limit number of addresses to
/120, /127 or /128?
What would make them to change their behavior? All 'SHOULD' are equal
but some SHOULD are more equal than other?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2018 17:51:12 +0000

> but some SHOULD are more equal than other?

Option 1) You think ISPs just handles the minimum address space that
might work. Then, I ask: What's the point of publishing recommendations
such as RFC8373?

Option 2) You think ISPs do follow our recommendations (hence publishing
stuff like RFC8273 makes sense). In such case,
draft-bourbaki-6man-classless-ipv6, removes the hardcoded /64, but does
not change the recommendation to use /64 for SLAAC.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2018 17:54:54 +0000

On 03/20/2018 05:37 PM, Lorenzo Colitti wrote:
> On Tue, Mar 20, 2018 at 4:56 PM, Fernando Gont <[email-masked]
> You got it the wrong way around. There is no /3 in which /64 is
> mandated. There is only a /3 in which /64 is optional. That /3 is not
> really relevant to autoconf because at this time it cannot be used for
> unicast addressing of actual hosts.

The above doesn't change the discussion. That /3 is still unicast. If
SLAAC implementations decline to work on non-64 prefixes, if we
eventually want to do slaac with such /3, it will just not work. And
that's bad.

> If ISPs follow the recommendations and always provide enough address
> space for users, there's no need to allow longer than /64 prefixes.

If the ISPs folow the recommendations removing the hardcoded /64 limit
would change nothing, because we're still recommending, e.g., that SLAAC
be done with /64s.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 20 Mar 2018 18:19:51 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Jen Linkova

> Sorry, it might be just me being stupid but I can not understand
> why do you think that your ISP which has not been following
> following recommendations and would not limit number of addresses
> to /120, /127 or /128?

(I realize that we have been down this same road before.)

Is it just me, or is the main objection to allowing CIDR in IPv6 only to control the behavior of ISPs? There must be other considerations too.

When you make an appointment with a plumber, to come and fix something, he often says as he leaves, "Just call back if you still have problems." Easy for him to say. You want the problem fixed so he doesn't have to come back. Making these appointments is a royal nuisance. The plumber has a completely different world view from the client.

Same with whoever it is that is delegating address space. Maybe the mindset of service providers, or other address delegation authorities, is that the clients "can just ask for more space." But from the point of view of a network designer, he/she probably would much prefer having the flexibility to do as much as possible WITHOUT going back to that authority, hat in hand? Like, just let me do my thing. In order to "guarantee" that ISPs hand out nothing greater than /64s, we are preventing use of flexible CIDR in IPv6. Is there any other reason?

Parenthetically, while IPv6 supports 96 bits more address space than IPv4, that doesn't mean that it can support anywhere close to that many more hosts. More realistically, IPv6 supports 32 bits more addresses for hosts than IPv4, as things are now. Not all that impressive. Because the lower 64 bits have to be very, very sparsely populated.

Bert

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 20 Mar 2018 18:35:37 +0000

> Now tell me: are there ISPs giving uses *just one* /64?

The answer is yes. Mobile networks provide just one /64. The reason, however, they provide just one is because there exists a major handset OS provider who refuses to support DHCPv6 IA-PD. This OS provider has been very active in discouraging equipment manufacturers from supporting DHCPv6. DHCPv6 is currently the only means of providing something other than an "assumed" /64. So, while I think y'all are wonderful people -- especially Jen -- darnit, please stop with this ISP bashing! Mobile ISPs "refusing to provide more than a /64" are not the reason 3GPP core networks are deployed without the ability to provide more than a /64. 

And, BTW, it's killing me on fixed wireless. Fixed wireless is such a small portion of LTE deployment, that it makes no sense to deploy a special core for it. So it has to use this kludgy assumption to provide a /64 to actual "broadband Internet service" customers. 

Plenty of directions to point fingers at. So be nice. To me.
There are ISPs offering only /64. Deal with it.
Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 19:15:39 +0000

> would change nothing, because we're still recommending, e.g., that SLAAC

But if you're right, then the situation is:

   - For ISPs that follow recommendations, allowing SLAAC with longer than
   /64 has little upside and little downside.
   - For ISPs that *don't* follow the recommendations, this change has
   strong downsides (a race to the bottom) and no upside.
   - Thus, the expected downside is negative.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Mar 2018 19:20:58 +0000

On Tue, Mar 20, 2018 at 6:35 PM, STARK, BARBARA H <[email-masked]> wrote:

> The answer is yes. Mobile networks provide just one /64. The reason,
> however, they provide just one is because there exists a major handset OS
> provider who refuses to support DHCPv6 IA-PD.

Actually I think the reason IA_PD is not deployed in mobile networks is
because mobile operators don't see a use case for it. I've talked to a few
of them, and everything I heard was that RFC 7278 does a good enough job
for them that they don't see the need to offer PD.

IA_NA is another story, of course.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2018 19:32:35 +0000

On 03/20/2018 07:15 PM, Lorenzo Colitti wrote:
> On Tue, Mar 20, 2018 at 5:54 PM, Fernando Gont <[email-masked]
>   * For ISPs that follow recommendations, allowing SLAAC with longer
>     than /64 has little upside and little downside.

For this case, the benefit is for the user.

>   * For ISPs that *don't* follow the recommendations, this change has

Having a single prefix to play with is a downside. It would be quite bad
to deploy IPv6 and have to deploy NAT.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 20 Mar 2018 20:01:17 +0000

Manfredi, Albert E wrote:
> Is it just me, or is the main objection to allowing CIDR in IPv6
> only to control the behavior of ISPs?

It's a bit more subtle, but yes, this appears to be the basis of several
peoples' main objection to classless addressing in ipv6.

As you mention it, it's quite a curious inversion to use layer 2.5 to
assert control of layer 9.

> There must be other considerations too.

Some vendors have possibly hardcoded /64 into SLAAC, in direct
contravention to what the protocol mandates. Although this has been
quoted as gospel in this WG, no-one has quantified the scale.

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Mar 2018 20:07:41 +0000

IA_PD is a good fit for devices that connect IoT mobile networks over
VPN tunnels, e.g., OpenVPN client/server.

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, March 20, 2018 12:21 PM
To: STARK, BARBARA H <[email-masked]>
Cc: Fernando Gont <[email-masked]>; IETF IPv6 Mailing List <[email-masked]>
Subject: Re: SLAAC on non-/64 networks

On Tue, Mar 20, 2018 at 6:35 PM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
The answer is yes. Mobile networks provide just one /64. The reason, however, they provide just one is because there exists a major handset OS provider who refuses to support DHCPv6 IA-PD.

Actually I think the reason IA_PD is not deployed in mobile networks is because mobile operators don't see a use case for it. I've talked to a few of them, and everything I heard was that RFC 7278 does a good enough job for them that they don't see the need to offer PD.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Mar 2018 21:43:11 +0100

> given to users in blocks of /64.

Er?  why?  I dont think the subnets have a fixed boundary of 64 bits, I 
dont know why you think so.  A 'subnet' is made by what ND and SLAAC can 
do and these are not bounded.

> /65.../66....up to /128 but will follow recommendations and give users

Half check.

They'll discover that they can still give just one /64 to an end user 
but the end user will make as many sub-prefixes as she wants.

Whether that is /65 or /80 depends on the end user, not the operator.

The end user has to learn how not to waste it too much.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Mar 2018 21:44:15 +0100

> Now tell me: are there ISPs giving uses *just one* /64?

YEs there are.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Mar 2018 21:59:50 +0100

Le 20/03/2018 à 20:20, Lorenzo Colitti a écrit :
>     however, they provide just one is because there exists a major
>     handset OS provider who refuses to support DHCPv6 IA-PD.
> 
> 
> because mobile operators don't see a use case for it. I've talked to a 
> few of them, and everything I heard was that RFC 7278 does a good enough 
> job for them that they don't see the need to offer PD.

I have talked to an operator and I deduce it wouldnt hurt to do PD to
mobile from the same server they do PD to home or to enterprise.  It
would be easier addressing architecture and routing.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 20 Mar 2018 22:42:58 +0000

I think the overall conversation is more about the broadband providers.

I agree that the cellular world (in the case of a smartphone) is a specific case, and we have mention it in RIPE690:

4.2.4. Considerations for Cellular Operators
There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers, i.e. in the case of broadband by means of cellular access, it will still be necessary to choose a /48 or /56 in accordance with the aforementioned considerations.

Regards,
Jordi

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Mar 2018 13:33:10 +1300

>    - Thus, the expected downside is negative.

ISPs are businesses operating, in many cases, in a domain with very limited
consumer protection. They certainly don't care about obeying RFCs as a matter
of principle. They do what seems easiest to maximise revenue and minimise
OPEX. So what they do on something like prefix length is mainly dictated
by those considerations plus available products.

If all CPEs insist on prefixes shorter than or equal to 64, that's what they'll
hand out. It's irrelevant what length prefixes are used within the homenet.
It's irrelevant whether 4291bis says MUST or SHOULD.

I think we got this right in RFC 7084:

   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
           router the size of the prefix it requires.  If so, it MUST
           ask for a prefix large enough to assign one /64 for each of
           its interfaces, rounded up to the nearest nibble, and SHOULD
           be configurable to ask for more.

   WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.  [RFC6177] covers the recommendations for service
           providers for prefix allocation sizes.

   -- Brian

---

From: Octavio Alvarez <[email-masked]>
Date: Tue, 20 Mar 2018 23:58:49 -0600

> Can you tel me where we were suggesting that ISPs lease clients prefixes
Are we talking about draft-bourbaki-6man-classless-ipv6-03?

It is great for users to remove the /64 fixed limit, as if an ISP gives
me a single /64 (because they can) I, as a subscriber, can still subnet
the network at home or at work.

However, I don't see an explicit recommendation against ISPs leasing
short prefixes either.

Adding an explicit recommendation or mandation about appropriate prefix
leasing would help prevent any misinterpretation. Or better yet, an RFC
that explicitly states the current state of the recommendations.

Octavio.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 21 Mar 2018 08:54:54 +0000

> For this case, the benefit is for the user.

No, there is no benefit to the user because in this hypothesis ISPs are
already assigning enough /64s to the user for the user to do whatever they
need.

> to deploy IPv6 and have to deploy NAT.

That's precisely why a hard boundary is needed. As long as users get a /64,
they can always use bridging to assign as many addresses as they need. If
there's a race to the bottom and all users get is a /128, then NAT is
really the only thing they have left. The hard boundary doesn't have to be
at /64, but it doesn't seem like any other value would behave any
differently, so we might as well make it /64.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2018 06:03:21 +0000

> Are we talking about draft-bourbaki-6man-classless-ipv6-03?

Yes.

> that explicitly states the current state of the recommendations.

Point taken. Will discuss with co-authors.

Thanks!

Cheers,

---

From: Jen Linkova <[email-masked]>
Date: Wed, 21 Mar 2018 20:47:31 +1100

> might work. Then, I ask: What's the point of publishing recommendations

It's there for people who are looking for recommendations and are listening.
People who ignores 'SHOULD' in RFCs and gives users one /64 will as
well ignore recommendations
to provide a prefix long enough.

Let me give you an example. There are laws out there which say 'you
SHOULD NOT kill other people'.
However there are bad people who meet other people on dark streets and
kill them.
Are you saying that there is no point of publishing recommendations
'people SHOULD NOT kill other people' and
send policemen to patrol such streets?

> stuff like RFC8273 makes sense).

If they do, your use case 'my ISP gives me just one /64' ceases to
exist. ISPs don't do that, they are following recommendations!

So far, reading this thread I've got an impression that:
- there are some ISPs out there not following the recommendations;
- we are removing the hard /64 limit to allow users connected to those
ISPs to have subnets;
- as a result of those changes  the following might (and most likely
will) happen:
    -- some of those ISPs will do nothing and users will be able to do
subnetting;
    -- some of those bad ISPs will be able to give users less than one
/64, even /128 which will result in NAT
   also, we'll see people developing IPv6 address plans for dual-stack
networks like 'I have /25 IPv4 subnet in this LAN, so I'll assign /121
Ipv6 here'.
I've seen them trying to do it before and the only thing stopping them
was 'it does not work'.

The price we are paying for having *temporary* relief for users
connected to 'bad' ISPs is too high. The cure is worse than the
disease

---

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2018 09:22:03 +0000

On 03/21/2018 08:54 AM, Lorenzo Colitti wrote:
> On Tue, Mar 20, 2018 at 7:32 PM, Fernando Gont <[email-masked]
> already assigning enough /64s to the user for the user to do whatever
> they need.

The user might be getting connectivity from another user/device, which
in turn got connectivity from another user/device...  Ad a sufficient
number of these, and the "sufficient /64s" the initial user got from the
ISP are not enough for the folk hanging from the edge to get one.

If you want the flexibility of multiple prefixes, I don't get why this
other flexibility is not important for you.

> That's precisely why a hard boundary is needed.

Isn't this the "protocol police" thing that we are not supposed to play?
 Unless there is a technical reason, that's the only way it can come across.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Mar 2018 11:38:21 +0100 (CET)

> other flexibility is not important for you.

I think you misunderstand. The people advocating for hard /64 limit do not 
do this because they think it's not important to have flexibility, it's 
that they think that this flexibility will cause some ISPs to offer bare 
minimum resulting in race to the bottom, without end gain.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2018 12:31:12 +0000

On 03/21/2018 10:38 AM, Mikael Abrahamsson wrote:
> I think you misunderstand. The people advocating for hard /64 limit do
> not do this because they think it's not important to have flexibility,
> it's that they think that this flexibility will cause some ISPs to offer
> bare minimum resulting in race to the bottom, without end gain.

I do understand that.

It is simple: there will be folks that will follow our recommendations,
and folks that don't.

A device/network might as well limit the number of addresses per mac
address, and you'd end up with a single IPv6 address, despite the huge
address space.

Me, I don't think the hard-limit of */64* belongs to an architecture
document (that's anything but "architecture").

I also believe that folks who don't follow our recommendations should
get what they get (wasn't it "no protocol police"?)

And also think that it is unfortunate that similar reasoning ("it could
be configured to only lease a single address") has been employed as an
excuse to not support DHCPv6.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 21 Mar 2018 15:59:09 +0000

> other flexibility is not important for you.

But even if this happens, and even if the ISP refuses to provide more
space, then those users can always use bridging because a /64 is always
large enough. If the users have a small prefix, there is no recourse other
than NAT.

>  Unless there is a technical reason, that's the only way it can come

That statement is too vague to be meaningful in this context. It's not
clear what "protocol police" means or who/what made the statement that
we're not supposed to "play it".

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 18:51:42 +0100

>   inet6 fe80::751a:3467:99b4:1f8e%vio0 prefixlen 64

But this invalidates the stronger privacy afforded by a 65bit IID in
GUA, right?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2018 08:33:37 +1300

...
> Point taken. Will discuss with co-authors.

That recommendation is already in BCP 157 (RFC 6177):

  "- it should be easy for an end site to obtain address space to
   number multiple subnets (i.e., a block larger than a single /64)
   and to support reasonable growth projections over long time
   periods (e.g., a decade or more)."

> document (that's anything but "architecture").

+1. I've thought for a long time that the /64 doesn't belong in
the addressing architecture at all; with the changes we've made to
IID creation, it belongs in a BCP - and we already have one, BCP 157.

(And it belongs somewhere as a specified value for LL address formation.)

I'm not very clear why we can't find consensus wording on this, since
istm we are all after the same result: ISPs hand out >=64, SLAAC
continues to work, and sites have flexibility when they need it.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Mar 2018 12:04:51 +1100

> On 21 Mar 2018, at 8:22 pm, Fernando Gont <[email-masked]> wrote:
> 

Then you ask the ISP for more than one /48.  The existing instructions
says “ASSIGN THE CLIENT AN ADDITIONAL /48 and repeat if they need more
address space after that etc.”  The additional /48s just need justification.

The space assigned to ISPs is done on the basis that clients can get a /48
BY DEFAULT and that they WILL assign additional /48’s as required.

Most of these problems are due to a imbalance of power between ISPs and
customers.  In civilised countries governments will step in and restore
the balance of power when the vendor is overstepping be it a ISP or
some other company.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: DY Kim <[email-masked]>
Date: Thu, 22 Mar 2018 10:59:06 +0900

> On 22 Mar 2018, at 04:33, Brian E Carpenter <[email-masked]> wrote:
> 
> the addressing architecture at all

++1

> we are all after the same result: ISPs hand out >=64, SLAAC

+1

---

From: DY Kim <[email-masked]>
Date: Thu, 22 Mar 2018 11:26:27 +0900

I’m not sure whether my comments could be anything near to ‘new’ as the chairs requested, but I’ll try.

I’d think

  - the concern against the ‘race to the bottom’, and

  - the wish for the flexibility in the edge networking

are independent issues and should be dealt with separately.

(1) For one thing, I’d fully agree to Gont when he says:

  "the hard-limit of */64* does not belong to an architecture document (that's anything but "architecture”)”

And I’d like to believe that everyone might agree at least unto this point.

(2) As for the concern about ‘the race to the bottom’ through malpractice by ISPs, the number ‘/64’ could be documented as a separate BCP to ensure a strong recommendation that the ISPs should handout prefixes of /64 or shorter.

(3) As for the flexibility on the part of the user networks, subnets with a prefix longer than /64 could be formed and the host address generation through SLAAC would work with no problem since SLAAC by itself is agnostic to the length of the prefix.

With these (1) ~ (3), everyone would be happy:

  - The architecture doc is clean and becomes a real ‘arch’ doc.

  - The user nodes are sure to get a /64 prefix from the ISPs.

  - The user nodes can give birth to as many children subnets as wanted, and that even recursively if wanted, downstream.

---
DY

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Mar 2018 16:48:37 +0000

> continues to work, and sites have flexibility when they need it.

That's exacty my take, and why the situation puzzles me.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Mar 2018 16:55:27 +0000

> That's exacty my take, and why the situation puzzles me.

I don't think there is lack of consensus over what the desired result is.

I think the lack of consensus is a) over what will happen if we remove this
limitation, and b) whether that outcome is more desirable or less desirable
than the situation we are in now.

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Mar 2018 16:57:33 +0000

> That's exacty my take, and why the situation puzzles me.

An important part of reaching a consensus is for each side to understand the other side's arguments and point of view.
It might be worth for both sides to puzzle over that for a while...

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Mar 2018 17:12:47 +0000

> BY DEFAULT and that they WILL assign additional /48’s as required.

That's perfect for the node that connects to the ISP. But it is not
when, e.g., a node obtains connectivity from another node (and this
happens multiple times in chain).

> the balance of power when the vendor is overstepping be it a ISP or

Let's not get in there. Actually, regulating the market has little to do
with being "civilized" (it's probably orthogonal).

Thanks,

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 08:37:39 +0900

Why do you have to place the limit in the architecture document? Why not

  - leave the architecture document free of this implementation-specific constant (so that it becomes the clean architecture document), and

  - generate a separate standard-track document to place such a limit into?

This way, we don’t have to worry about whether there’s consensus on the two items of yours and technically stay with the status quo.

---
DY

> On 23 Mar 2018, at 01:55, Lorenzo Colitti <[email-masked]> wrote:
> 
> I think the lack of consensus is a) over what will happen if we remove this limitation, and b) whether that outcome is more desirable or less desirable than the situation we are in now.

---

From: Erik Kline <[email-masked]>
Date: Thu, 22 Mar 2018 17:00:36 -0700

Someone trying an RA with /65 today will see that it does not "just
work" (OpenBSD aside).

Once /65, /66, etc all pretty much "just work" the document saying
"everyone should have more than one /64" isn't worth spit.

To see that this is true just observe that such a document already
exists appears to be ignored (according to anecdotal evidence
elsewhere on this thread).

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 09:14:47 +0900

It’s interesting that RA with other than /64 might not work. As I understand, IPv6 routers are meant to work for any prefix lengths...

---
DY

> On 23 Mar 2018, at 09:00, Erik Kline <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Mar 2018 01:33:16 +0100

> On 23 Mar 2018, at 01:14, DY Kim <[email-masked]> wrote:
> 

The IPv6 architecture has a split of the address at the 64 bit boundary. 64 bits to the network and 64 bits to the hosts. 

That’s a fundamental part of the IPv6 architecture.

Changing that boundary isn’t going to fix any technical problem you have.
So, what problem are you wanting to solve? If it’s “permission-less” extension of the network, well so work on that...

Ole

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 09:57:34 +0900

If it’s the fundamental part of the IPv6 architecture, whey then do you have the texts like followings in the document?:

(quote)

2.4.  Unicast Addresses

IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing.

   IPv6 unicast routing is based on prefixes of any valid length up to 128 [BCP198].

  ...

   IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays
   (for instance, host versus router).  At a minimum, a node may consider that unicast addresses (including its own) have no internal structure:

  ...

(end quote)

And why do you have ‘128-n’ for the length of the interface ID right below the above text. Why don’t you just start with 64 instead of ‘128-n’.

And further down at 2.4.4, the length of the interface ID is ‘128-n-m’, where n and m being parameters as implied. If ’64’ is such fundamental, why don’t you write like

  global routing prefix          n bits
  subnet ID                   64-n bits
  interface ID                  64 bits

The arch documents says as if n and m are parameters, but all of a sudden it mandates (n+m=64).

I’d suspect that at some point of the development of the IPv6 spec, the intention was to be generic and leave n and/or m variables, but at some other point of time they put a constant ’64’ into an odd place.

From the academic perspective of the standard document, and that on anything called ‘architecture’, the current 4291 is the worst example that future students should never follow a similar path.

Shame on IETF.

---
DY

> On 23 Mar 2018, at 09:33, Ole Troan <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 12:19:06 +1100

> On 23 Mar 2018, at 4:12 am, Fernando Gont <[email-masked]> wrote:
> 

Why not? If you exhaust your pool of /64’s you ask your upstream for more /64s
to meet your now expanded NEEDS.  This process can be done by EVERYTHING involved
in the allocation chain.  The major difference is that ISP’s would normally give out
more than is requested rather than just what is requested (8 /64’s requested
become 65536 /64’s returned).

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 10:31:34 +0900

It’s not true, at least in such an uncivilized countries like South Korea. Neither KT nor SKT will give you (a home customer) more than one IPv6 address, let alone a /64 prefix, unless you pay a considerable extra fee.

I live in a country side and own a small mountain and would apply advance ICT technology on my farms/tree on and around the mountain. That is, I’m going to build an IoT network with many many intelligent Internet dusts, be they sensors, remote motors or drones.

I do want to apply IPv6 technology within my IoT intranet, for then I might benefit from cheap or open-source networking software. In my situation wherein paying for extra addresses/prefix make no sense to me, I’d like to build many a subnets within my field. I do hope all software like SLAAC or anything involved work smoothly, wherein my nodes definitely will be assigned IIDs shorter than 64. 

If all software I buy would only work for IID’s of 64, I’m done. Unless I move to any other civilized countries, I cannot enjoy the benefit of advanced ICT technology based on IPv6.

I hate this fate of being jailed into uncivilized ISPs. God bless me.

---
DY

> On 23 Mar 2018, at 10:19, Mark Andrews <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 23 Mar 2018 01:32:31 +0000

I'm pretty sure SKT will give you a whole /64 on their mobile network.

On Fri, Mar 23, 2018 at 1:31 AM, DY Kim <[email-masked]> wrote:

> It’s not true, at least in such an uncivilized countries like South Korea.
> Neither KT nor SKT will give you (a home customer) more than one IPv6
> address, let alone a /64 prefix, unless you pay a considerable extra fee.
>
> I live in a country side and own a small mountain and would apply advance
> ICT technology on my farms/tree on and around the mountain. That is, I’m
> going to build an IoT network with many many intelligent Internet dusts, be
> they sensors, remote motors or drones.
>
> I do want to apply IPv6 technology within my IoT intranet, for then I
> might benefit from cheap or open-source networking software. In my
> situation wherein paying for extra addresses/prefix make no sense to me,
> I’d like to build many a subnets within my field. I do hope all software
> like SLAAC or anything involved work smoothly, wherein my nodes definitely
> will be assigned IIDs shorter than 64.
>
> If all software I buy would only work for IID’s of 64, I’m done. Unless I
> move to any other civilized countries, I cannot enjoy the benefit of
> advanced ICT technology based on IPv6.
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 12:46:01 +1100

I suppose it is time to lobby RIR’s to increase annual fees to such ISP’s.
/48’s cost essentially nothing.  There is no additional administrative costs
to hand out /48’s over /64’s.  The equipment costs are the same.

APNIC IPv6 /20 costs $45050 AUD
$45050/(2^28) = 0.0001 AUD

For comparison a IPv4 /8 is $77075 AUD

https://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=&ipv6=%2F20&action=Calculate

> On 23 Mar 2018, at 12:31 pm, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 11:13:29 +0900

Why would you lock my fate into the malice of ISPs?

As long as my IoT intranet is concerned, it basically has nothing to do with ISPs. As long as my open-source software works fine for any IID lengths, I’m fine. I don’t have to beg to the ISPs for every additional address/prefixes.

Let me fly freely. Free of any small and big brothers. I thought that’s the paradigm the Internet or IP technologies has once told me.

I don’t want to live in the bondage of ISPs, all the more because mine is an intranet, not an Internet. As long as the IPv6 standard docs are written so that all software work fine for any IID length, I’m fine.

With that constant ’64’ hammered into 4291, you rip me of freedom and put me into the malice of the ISPs.

Not pretty.

---
DY

> On 23 Mar 2018, at 10:46, Mark Andrews <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 11:16:43 +0900

To add, some folks talk about privacy. Although there might not be any serious privacy issue in my local network, that also would not be a problem, for, as long as the IID length is larger than 40 bits, the node privacy would not be affected any seriously, as I know; I remember some doc talked about that minimum 40 bits to ensure enough privacy.

---
DY

> On 23 Mar 2018, at 11:13, DY Kim <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 13:37:51 +1100

> It’s not true, at least in such an uncivilized countries like South Korea. Neither KT nor SKT will give you (a home customer) more than one IPv6 address, let alone a /64 prefix, unless you pay a co…

Complain to your Government.  Fixing this isn’t the responsibility of the IETF.

> I live in a country side and own a small mountain and would apply advance ICT technology on my farms/tree on and around the mountain. That is, I’m going to build an IoT network with many many intel…

Use a ULA addresses for them. You can create as many /48’s as you require where each one gives you a 65000 odd /64’s.

> I do want to apply IPv6 technology within my IoT intranet, for then I might benefit from cheap or open-source networking software. In my situation wherein paying for extra addresses/prefix make no…

Your big problem here is that you are thinking in IPv4 mode.

> If all software I buy would only work for IID’s of 64, I’m done. Unless I move to any other civilized countries, I cannot enjoy the benefit of advanced ICT technology based on IPv6.

No you are not done.  You just haven’t explored the solution space.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2018 16:13:38 +1300

> Complain to your Government.  Fixing this isn’t the responsibility of the IETF.

That's true, but it is our job to write standards and BCPs that tip
governments and businesses in the (technically) right direction.
That's why we published RFC6177 (BCP157) as well as RFC 7608 (BCP198).
So our documented BCPs are that ISPs should provide at least /64 and
that routers should route any length prefix up to /128. 

We also standardised that interface identifiers should support privacy
(RFC8064) and that SLAAC should work with an arbitrary IID length (RFC4862).

Put those together, and to me the claim that /64 is an *architectural*
limit is hard to support. 

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 14:47:28 +1100

> On 23 Mar 2018, at 2:13 pm, Brian E Carpenter <[email-masked]> wrote:
> 

It really depends on what you include in the term “architectural”.  There
is absolutely nothing wrong with saying to router vendors and host vendors
make sure your code able work with other sizes as we may need to change
them in the future while at the same time saying to ISPs, RIRs that we
are applying these limits to these features in this address range.  Both
of these areas fall into the term “Architecture”.

What we have now is not inconsistent.  We do have ISP’s that are not supplying
prefix space to their customers that is consistent with the specified Architecture
for IPv6.

---

From: Octavio Alvarez <[email-masked]>
Date: Thu, 22 Mar 2018 22:19:49 -0600

On 03/21/2018 01:33 PM, Brian E Carpenter wrote:
>>> It is great for users to remove the /64 fixed limit, as if an ISP
>>> gives me a single /64 (because they can) I, as a subscriber, can
>>> still subnet the network at home or at work.
>>> 
>>> However, I don't see an explicit recommendation against ISPs 
>>> leasing short prefixes either.
>>> 
>>> Adding an explicit recommendation or mandation about appropriate
>>>  prefix leasing would help prevent any misinterpretation. Or 
>>> better yet, an RFC that explicitly states the current state of 
>>> the recommendations.
>> 
> number multiple subnets (i.e., a block larger than a single /64) and
>  to support reasonable growth projections over long time periods 
> (e.g., a decade or more)."

The same documents says: "This document does not make a formal
recommendation on what the exact assignment size should be. The exact
choice of how much address space to assign end sites is an issue for the
operational community."

Thanks,
Octavio.

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Mar 2018 06:44:33 +0000

> choice of how much address space to assign end sites is an issue for the

So a formal statement would be what was in its predecessor, RFC3177.

Above is saying X */64s, with X > number of links at site, but not formally
stating by how much greater. RFC 3177 did.

Regards,
Mark

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 10:27:49 +0100

> "everyone should have more than one /64" isn't worth spit.

I dont think so.  I think the document saying that everyone should have 
more than one /64 will always be very valid.  It's a very good way to 
go.  Maybe it is a condition to set in the contract that RIR signs when 
allocating to ISP.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 10:29:19 +0100

Le 23/03/2018 à 01:14, DY Kim a écrit :
> It’s interesting that RA with other than /64 might not work.

Longer version: _SLAAC_ with RA /65 on linux does not work.

> As I understand, IPv6 routers are meant to work for any prefix
> lengths...

Yes, they do, for forwarding.  (not SLAAC).

Alex

> --- DY

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 23 Mar 2018 09:34:00 +0000

The policies in all the RIRs already said that, but it can't be "enforced" unless the RIR communities agree on that with a strict policy change that also enforces the RIR staff do to verification about the compliance. Then the RIR membership contract, already states that if a policy is not followed the ISP can be forced to lose the resources.

The way the RIR policies work is by consensus in the community, and the ISPs that do that are part of that community.

You can make your own conclusions.

I think, as indicated the other way, the only that we can do from IETF, is to improve the 6177 language, and even maybe in our agreement with IANA to provide the resource to the RIRs, state that as a condition as well (thinking loud).

Regards,
Jordi
 
-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Alexandre Petrescu <[email-masked]>
Fecha: viernes, 23 de marzo de 2018, 9:28
Para: <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    
    Alex

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 18:35:57 +0900

In my long-term vision, I keep the prospect of opening my IoT network to the Internet so that I can control my IPv6 dusts from outside while I’d be enjoying California sunshine, hence I’d like to load my dust devices with IPv6-routing-compatible GUAs, which, according to 2.4.4 of rfc 4291, can hold IID’s of any length, 128-n-m, in principle, if not for that constant 64 nailed down therein.
 
---
DY

> On 23 Mar 2018, at 11:37, Mark Andrews <[email-masked]> wrote:
> 
> Use a ULA addresses for them.

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 18:37:57 +0900

Well put.

---
DY

> On 23 Mar 2018, at 12:13, Brian E Carpenter <[email-masked]> wrote:
> 
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 10:40:34 +0100

> I'm pretty sure SKT will give you a whole /64 on their mobile network.

Do we want one /64 or _more_ than one /64 from the ISP to the end-user?

UE on cellular means that one /64 is one address.

I dont understand your arguments.

Alex

> 
> On Fri, Mar 23, 2018 at 1:31 AM, DY Kim <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     It’s not true, at least in such an uncivilized countries like South
>     Korea. Neither KT nor SKT will give you (a home customer) more than
>     one IPv6 address, let alone a /64 prefix, unless you pay a
>     considerable extra fee.
> 
>     I live in a country side and own a small mountain and would apply
>     advance ICT technology on my farms/tree on and around the mountain.
>     That is, I’m going to build an IoT network with many many
>     intelligent Internet dusts, be they sensors, remote motors or drones.
> 
>     I do want to apply IPv6 technology within my IoT intranet, for then
>     I might benefit from cheap or open-source networking software. In my
>     situation wherein paying for extra addresses/prefix make no sense to
>     me, I’d like to build many a subnets within my field. I do hope all
>     software like SLAAC or anything involved work smoothly, wherein my
>     nodes definitely will be assigned IIDs shorter than 64.
> 
>     If all software I buy would only work for IID’s of 64, I’m done.
>     Unless I move to any other civilized countries, I cannot enjoy the
>     benefit of advanced ICT technology based on IPv6.
> 
>     > On 23 Mar 2018, at 10:19, Mark Andrews <[email-masked] <mailto:marka@isc..org>> wrote:
>     >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 18:44:27 +0900

Not all ISP engineers are smart enough to sort out the apparently conflicting IETF standards to comply with your intention, especially not in such an uncivilized countries as mine; 4291 vs SLAAC vs BCP157 vs BCP198, etc.

---
DY

> On 23 Mar 2018, at 12:47, Mark Andrews <[email-masked]> wrote:
> 
> We do have ISP’s that are not supplying

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 18:50:24 +0900

SLAAC by itself is designed to work with any prefix lengths. It is rfc 4291 which has confined the operation only to /64. So, it’s rfc 4291, not SLAAC, which is responsible for SLAAC working only for /64.

---
DY

> On 23 Mar 2018, at 18:29, Alexandre Petrescu <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 10:53:18 +0100

Le 23/03/2018 à 10:44, DY Kim a écrit :
> Not all ISP engineers are smart enough to sort out the apparently
> conflicting IETF standards to comply with your intention, especially
> not in such an uncivilized countries as mine; 4291 vs SLAAC vs BCP157
> vs BCP198, etc.

BCP157 reads compatible with BCP198 and with SLAAC-without-2464 and with 
parts of RFC4291, in their independence of a /64 limit.

SLAAC together with RFC2464 and with other parts of RFC4291 enforce a 
/64 limit.

Alex

>> We do have ISP’s that are not supplying prefix space to their
>> customers that is consistent with the specified Architecture for
>> IPv6.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 10:54:19 +0100

Le 23/03/2018 à 10:50, DY Kim a écrit :
> SLAAC by itself is designed to work with any prefix lengths. It is
> rfc 4291 which has confined the operation only to /64. So, it’s rfc
> 4291, not SLAAC, which is responsible for SLAAC working only for
> /64.

I agree to a large extent.

Alex

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 18:59:47 +0900

What if my link is not of the Ethernet family? I’m happy with RFC 2464, but why do we have to nail down the constant 64 into RFC 4291?

By having that constant imbedded in RFC 4291, you effectively limit the operation of SLAAC exclusively to /64, which is not the intention of the original SLAAC spec, as I understand.

---
DY

> On 23 Mar 2018, at 18:53, Alexandre Petrescu <[email-masked]> wrote:
> 
> SLAAC together with RFC2464 and with other parts of RFC4291 enforce a /64 limit.

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 19:23:53 +0900

RFC 3177 has been obsoleted by RFC 6177 (BCP 157).

---
DY

> On 23 Mar 2018, at 15:44, Mark Smith <[email-masked]> wrote:
> 
> Above is saying X */64s, with X > number of links at site, but not formally stating by how much greater. RFC 3177 did.

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Mar 2018 10:35:03 +0000

So you want to change the IPv6 architecture because you have trouble with one ISP?
And change it in a way that allows the ISP to give you much more trouble?
That doesn't sound like a good idea to me.

Again, what problem are you trying to solve?

If it is to attain some isolation between site addressing and the global Internet addressing, that's one of the main reasons why there is the 64 bit boundary in the first place (see 8+8, GSE, ILNP for history).

If the problem you want to solve is "I want to be able to extend a network that has only a /64 with arbitrary number of links/hosts", then you might go back and look at the MLSR work we did a decade or two ago.
I at least would be very supportive if you would pick that work up again.

Ole

> On 23 Mar 2018, at 01:31, DY Kim <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 11:43:36 +0100

I agree with the question.

I agree that SLAAC per se is not limited to 64bit only.

For other than Ethernet links: there are other IPv6-over-foo documents, 
like IPv6-over-802.15.4 RFC4944, or IPv6-over-NFC draft-ietf-6lo-nfc-09. 
  They all source their inspiration in RFC2464, and thus make 64bit 
IIDs.  In a sense, all what IETF outputs as IPv6-over-foo (remark 'foo') 
are all 64bit IID, because of conservatorism.

The only particular detail is this Opaque Identifiers RFC with variable 
length IIDs.  Ideally, all IPv6-over-foo documents should refer to it in 
its natural variable-length form.

For IPv6-over-NFC, which is an IoT technology, it could be this.

OLD text in draft-ietf-6lo-nfc-09:
>    Following the guidance of [RFC7136], interface identifiers of all
>    unicast addresses for NFC-enabled devices are 64 bits long and
>    constructed by using the generation algorithm of random (but stable)
>    identifier (RID) [RFC7217] (see Figure 3).

NEW text in draft-ietf-6lo-nfc-09:
>    Following the guidance of [RFC7136], interface identifiers MUST be
>    opaque and constructed by using the generation algorithm of random
>    (but stable) identifier (RID) [RFC7217] (see Figure 3).

_If_ we did that, it would be a great example of how to avoid further
propagation of the 64bit limit from RFC2464 to other IPv6-over-foo
documents.

Alex

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 20:03:53 +0900

I’d suspect the result is not only from inspiration in RFC2462, but more from RFC4291 which mandates 64-bit IIDs ‘independently’ of any link types.

If not for that constant in RFC4291, designers for other link types might have thought

  ‘Wow, we’re not Ethernet, so don’t have to follow RFC2462. Moreover, RFC4291 (in an imaginable version) says the IID length is 128-n-m where n and m are variables, and so the IID can be of any length. We should be more creative in using  the IPv6 address format.’

For all odds (which some groups in this ML do not think as such), RFC4291 is to blame.

---
DY

> On 23 Mar 2018, at 19:43, Alexandre Petrescu <[email-masked]> wrote:
> 
> For other than Ethernet links: there are other IPv6-over-foo documents, like IPv6-over-802.15.4 RFC4944, or IPv6-over-NFC draft-ietf-6lo-nfc-09.  They all source their inspiration in RFC2464, and thus make 64bit IIDs.  In a sense, all what IETF outputs as IPv6-over-foo (remark 'foo') are all 64bit IID, because of conservatorism.

---

From: DY Kim <[email-masked]>
Date: Fri, 23 Mar 2018 20:27:19 +0900

> On 23 Mar 2018, at 19:35, Ole Troan <[email-masked]> wrote:
> 

I’m not trying to solve any specific problem at the moment. The IoT network on my mountain is just an imaginary example to illustrate my case; I don’t even own a mountain, in fact… 

All I’m trying is just to point out that placing a hard limit on the IID length in RFC 4291 is a flaw.

  - Make RFC 4291 as generic as possible, with n and m all variables, as once intended.

  - Specific requirements of /64, understandably with good reasons, should be documented in separate standards. RFC2462 is an example. Any further similar requirements be in RFCs similar to 2464.

> then you might go back and look at the MLSR work we did a decade or two ago.

I’m not sure whether one of my documents named ‘sid6’ once posted to v6ops is a stuff belong to the MLSR class, but, at the moment, I’d not dare do that since it involves additional texts to both RFC 4291 (arch) and RFC 4861 (nd6).

Trying to change/extend/add even a word in those documents seem implausible, at least to me. I’m still struggling to grasp the real meaning of ‘rough consensus’. I begin to wonder if there’s a group with a veto right you have to get over… Fatally discouraged…

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Mar 2018 11:52:44 +0000

> I’m not trying to solve any specific problem at the moment. The IoT network on my mountain is just an imaginary example to illustrate my case; I don’t even own a mountain, in fact…

It's a lot more constructive to work on real problems... :-)

>  - Specific requirements of /64, understandably with good reasons, should be documented in separate standards. RFC2462 is an example. Any further similar requirements be in RFCs similar to 2464.

Right as stated before and again confirmed by this thread, there is no consensus to do that.

> Trying to change/extend/add even a word in those documents seem implausible, at least to me. I’m still struggling to grasp the real meaning of ‘rough consensus’. I begin to wonder if there’s a grou…

For the consensus process I recommend you read RFC7282.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Mar 2018 13:08:02 +0100

Le 23/03/2018 à 12:52, Ole Troan a écrit :
[...]
> It's a lot more constructive to work on real problems... :-)

HEre's my list of the expressions of the problem:
- race to the bottom problem
- rfc4291 /64 vs 128-n problem
- “permission-less” extension of the network
- "I want to be able to extend a network that has only a /64 with
   arbitrary number of links/hosts"
- operator does not give 2 /64s to UE problem

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 23 Mar 2018 13:02:50 +0000

On Fri, Mar 23, 2018 at 11:03 AM, DY Kim <[email-masked]> wrote:

>   ‘Wow, we’re not Ethernet, so don’t have to follow RFC2462. Moreover,
> RFC4291 (in an imaginable version) says the IID length is 128-n-m where n
> and m are variables, and so the IID can be of any length. We should be more
> creative in using  the IPv6 address format.’
>

I and many others would actually make the opposite statement: "we need to
thank RFC 4291". :-)

---

From: Erik Kline <[email-masked]>
Date: Sat, 24 Mar 2018 00:59:53 +0900

> I and many others would actually make the opposite statement: "we need to

Yes, 4291 is why the ISP has to give you a /64 and not just a single /128.

Without it, we would be (re)forming the behave(6) working group...

---

From: DY Kim <[email-masked]>
Date: Sat, 24 Mar 2018 09:54:58 +0900

Back to where we were…

What makes you think the ISP would give me much more trouble in that way? A separate standard document mandating the ISPs to handout /64 prefixes would eliminate the concern you have, perhaps most probably, about the ‘race to the bottom’ problem.

---
DY

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Mar 2018 12:30:20 +1100

On 23 March 2018 at 22:27, DY Kim <[email-masked]> wrote:
> I’m not trying to solve any specific problem at the moment.

So if you can't describe a specific problem, there is no problem to solve.

Others suggest the problem is ISPs etc. not giving end sites enough
address space to give each link a /64 at the site.

If that argument can continue without change, even if the prefix
size/IID parameter value was changed to say /80, or /96, or /120, or
made entirely arbitrary and variable, then the value of the parameter
itself isn't the problem.

> The IoT network on my mountain is just an imaginary example to illustrate my case; I don’t even own a mountain, in fact…
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Mar 2018 14:49:23 +1300

> So if you can't describe a specific problem, there is no problem to solve.

The problem is discussed in https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03#section-3

   Brian

---

From: DY Kim <[email-masked]>
Date: Sat, 24 Mar 2018 11:20:47 +0900

OK, let me then describe some problems I find:

P1) Although, SLAAC is designed to work for any prefix lengths, because of the IID length fixed to 64 in RFC 4291, many deployed SLAACs implementations work only for /64.

P2) With a /64 given to my node, I’d like to have the flexibility to generate subnets downstream with a longer prefix and so with a shorter IID. With the current RFC 4291, the freedom is fundamentally blocked, which is a nuance to me. I don’t want the troubles to ‘argue’ with the ISP for more /64 prefixes, which troubles can be far more troublesome than you might think in a civilized situation.

P3) Talks are also about the privacy, but I’m informed IID not less than 40 bits won’t much compromise the privacy, so I’d like to make use of the 24 bit space (64-40) to my creative advantage, be it subnets or any creative wild things that may emerge in the future. The current RFC 4292 fundamentally block this freedoms space.

P4) The major concern from the opposing camp seems to be the possible ‘race to the bottom’ problem. That concern can be dealt with a separate standard-track document mandating handouts of at least /64 to each link in a site by the ISPs. The cure does not have to be fixing the IID length (which would be an indirect measure) in RFC 4291.

P5) Many ‘IPv6-over-foo’ documents are written to work only for 64-bit IIDs, which in fact would not be a necessity for many link types other than Ethernet. Removing ’64’ in RFC 4291 would release those docs from such a false notion, and be written to make the best of the specific link capabilities.

P6) Basically, the IID length and ISP’s ensuring a /64 for each link in a site are rather independent issues. As for the second issue with ISPs, a separate standard-track document would eliminate related concern. The cure does not have to be fixing the IID length in RFC 4291 which is but an indirect measure only to spawn other problems in connection with other standard documents.

---
DY

> On 24 Mar 2018, at 10:30, Mark Smith <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Fri, 23 Mar 2018 19:45:25 -0700

> P4) The major concern from the opposing camp seems to be the possible ‘race to the bottom’ problem. That concern can be dealt with a separate standard-track document mandating handouts of at least…

I fundamentally have zero faith that any such document would result in
the desired outcome.

The number of times I've heard "my network, my rules"...there's no way
that *every* network operator in the world would comply.

And that's really what's required: *every* network has to respect your
proposed "/64 per link" document.  It only takes ONE major network to
thumb its nose at the document and the whole endeavor fails.  We'll
have people showing up claiming that $MAJOR_CARRIER only gives them a
"/way_too_small", and in short order we'll have NAT again.

No: the hard protocol limitation is really the only backstop.

---

From: DaeYoung KIM <[email-masked]>
Date: Sat, 24 Mar 2018 12:42:11 +0900

Sent from my iPhone

>> No: the hard protocol limitation is really the only backstop.

Then, rewrite rfc 4291. Declare 64 right from the start of the document and 

   - remove all variables n & m in the figures depicting the IID length and instead put 64 therein

   - remove all texts suggesting ‘no internal structure of the IPv6 address’ and instead say ‘IPv6 address is 128 bits long and consists of a 64-bit prefix and a 64-bit IID.

This will ensure all companion standards, be it routing or SLAAC or any other, would be hard-coded to the 64 limit, not to mention ISPs mandated to ensure at least a /64 prefix to each links in a site.

That way, clean-cut unambiguous arch doc and consistency throughout all IPv6 related standard.

Why not do that?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 24 Mar 2018 08:03:25 +0100 (CET)

On Sat, 24 Mar 2018, DY Kim wrote:

> What makes you think the ISP would give me much more trouble in that 
> way? A separate standard document mandating the ISPs to handout /64 
> prefixes would eliminate the concern you have, perhaps most probably, 
> about the ‘race to the bottom’ problem.

We're already telling them to hand out /56:es, but that seems to be 
working so-so. Right?

---

From: DaeYoung KIM <[email-masked]>
Date: Sat, 24 Mar 2018 16:39:39 +0900

> On 24 Mar 2018, at 16:03, Mikael Abrahamsson <[email-masked]> wrote:
> 
> We're already telling them to hand out /56:es, but that seems to be working so-so. Right?

Where’s the document to strongly recommend or mandate that they SHOULD or MUST hand out /56:es?

With the one for /64, I mean a strong recommendation or mandating as SHOULD or MUST.

If ISPs still don’t comply, it’d only mean that IETF has simply lost its authority as an SDO.

---

From: Lee Howard <[email-masked]>
Date: Sat, 24 Mar 2018 09:34:40 +0000

> If ISPs still don’t comply, it’d only mean that IETF has simply lost its authority as an SDO.

The only authority the IETF has is in ensuring interoperability.

The only appropriate use for MUST is "If you don't do this, your stuff 
won't work with others' stuff."

RFC2119 "Key words for use in RFCs to Indicate Requirements Levels" 
Section 6 Guidance in the use of these Imperatives:

Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)*For example, they must not be used to try to impose a particular method 
on implementors where the method is not required for interoperability.*

(emphasis mine)

I don't think the case has been successfully made that IPv6 (or higher 
protocols) fails to interoperate with the 64 bit boundary.

Lee

---

From: DY Kim <[email-masked]>
Date: Sat, 24 Mar 2018 18:59:18 +0900

It’s only because the 64 bit boundary has already been mandated in RFC 4291.

There’s no proof that the interoperability would fail if we remove the boundary in RFC 4291 and instead state that in a separate standard document.

The status quo is not a proof that the other way around would fail for interoperability.

---
DY

> On 24 Mar 2018, at 18:34, Lee Howard <[email-masked]> wrote:
> 
> I don't think the case has been successfully made that IPv6 (or higher protocols) fails to interoperate with the 64 bit boundary.

---

From: Lea Roberts <[email-masked]>
Date: Sat, 24 Mar 2018 03:15:59 -0700 (PDT)

On Sat, 24 Mar 2018, DaeYoung KIM wrote:

> Where?s the document to strongly recommend or mandate that they SHOULD or MUST hand out /56:es?
>
> If ISPs still don?t comply, it?d only mean that IETF has simply lost its authority as an SDO.

when we did RFC6177, it was pointed out that the capitalized should and 
must were not appropriate in speaking about address allocation, since that 
is not part of the protocol specification.  we did make sure to recommend 
assigning prefixes shorter than /64 and not continuing the restrictive 
address assignment practices deployed to extend the useful life of IPv4.

/Lea

from RFC 6177:

    there are important operational
    considerations as well, some of which are important if users are to
    share in the key benefit of IPv6: expanding the usable address space
    of the Internet.  The IETF recommends that any policy on IPv6 address
    assignment policy to end sites take into consideration the following:

       - it should be easy for an end site to obtain address space to
         number multiple subnets (i.e., a block larger than a single /64)
         and to support reasonable growth projections over long time
         periods (e.g., a decade or more).

       - the default assignment size should take into consideration the
         likelihood that an end site will have need for multiple subnets
         in the future and avoid the IPv4 practice of having frequent and
         continual justification for obtaining small amounts of
         additional space.

---

From: Lee Howard <[email-masked]>
Date: Sat, 24 Mar 2018 10:44:44 +0000

> The status quo is not a proof that the other way around would fail for interoperability.

No, but a functioning status quo is a proof (well, evidence) that we 
have interoperability now. The responsibility is on the change to show 
it will not cause harm, and will cause good.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 24 Mar 2018 12:28:23 +0100

Hi Lea,

In my IPv6 deployment survey (for residential broadband, not including cellular), with responses from over 1520 ISPs worldwide, it shows that:

- 33% of the ISPs provide a single /64
- 23% provide a /48
- 35% provide a /56
- 9% provide other prefixes

In my opinion, it will help to revise RFC6177 and make a stronger language against not only a single /64 but options such as only a "few" /64s.

Can you check with the authors will be interested in working on that?

Otherwise, I'm happy to take over that work myself.

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de Lea Roberts <[email-masked]>
Fecha: sábado, 24 de marzo de 2018, 11:17
Para: DaeYoung KIM <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    
    /Lea
    
    from RFC 6177:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 24 Mar 2018 12:39:08 +0100

> In my opinion, it will help to revise RFC6177 and make a stronger language against not only a single /64 but options such as only a "few" /64s.

The survey is a great first step. It may help to have public data
showing which ISPs got IPv6 right and which ones not so much. This
might even wake up regulators. Of course, this is not really an IETF
business but perhaps ISOC could be interested to sponsor a substantial
survey how IPv6 has been deployed and perhaps even celebrate an 'IPv6
prefix delegation done right day' to give credits to ISPs who provide
useful IPv6 prefixes to their customers. Some public encouragement to
do things right help more than MUSTs and SHOULDs buried in RFCs.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 24 Mar 2018 12:46:42 +0100

The survey was disseminated by all the RIRs, ISOC, etc., and has been presented in many events (updated versions each time). It is available in many languages.

Is still open, so I can get updated data and publish it every few months:

http://survey.consulintel.es/index.php/175122

Last presentation was January this year in the UKNOF-39:

https://indico.uknof.org.uk/event/41/contribution/5/material/slides/0.pdf

I also presented there the RIPE690, which is very related.

It also shows, when looking at the results in different countries, deployment dates, etc., that in general earlier deployments got it much better (RFC3177 was the guideline at that time), so RFC6177 is at least, partially, responsible for the problem.

Regards,
Jordi
 
-----Mensaje original-----
De: Juergen Schoenwaelder <[email-masked]>
Responder a: Juergen Schoenwaelder <[email-masked]>
Fecha: sábado, 24 de marzo de 2018, 12:39
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Lea Roberts <[email-masked]>, 6man WG <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    /js

---

From: DY Kim <[email-masked]>
Date: Sat, 24 Mar 2018 20:54:45 +0900

Are you saying that the recommendations of RFC 6177 are well observed even if should and must are not capitalized.

If RFC 6177 suffices, then why do you have to keep the constant 64 in RFC 4291? It would do no harm to remove 64 from RFC 4291. Why do people object to that while it would do no harm to the community?

---
DY

> On 24 Mar 2018, at 19:15, Lea Roberts <[email-masked]> wrote:
> 
> when we did RFC6177, it was pointed out that the capitalized should and must were not appropriate in speaking about address allocation, since that is not part of the protocol specification.  we did make sure to recommend assigning prefixes shorter than /64 and not continuing the restrictive address assignment practices deployed to extend the useful life of IPv4.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 24 Mar 2018 13:01:47 +0100

Because the language used is not clear enough.

People don't read correctly "a number of /64", and they just go for a single /64.

In RFC3177 it was "use always /48".

Regards,
Jordi
 
-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de DY Kim <[email-masked]>
Fecha: sábado, 24 de marzo de 2018, 12:55
Para: Lea Roberts <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    ---
    DY

---

From: DY Kim <[email-masked]>
Date: Sat, 24 Mar 2018 21:08:03 +0900

How far do you believe in RFC 6177?

 - If you believe in it, then the doc is the very insurance that the interoperability will be retained even if we remove 64 from RFC 4291.

 - If you don’t, it’s a pity for the authors, for they have simply wasted their time. IETF has well to deprecate RFC 6177.

---
DY

> On 24 Mar 2018, at 19:44, Lee Howard <[email-masked]> wrote:
> 
> No, but a functioning status quo is a proof (well, evidence) that we have interoperability now. The responsibility is on the change to show it will not cause harm, and will cause good.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 24 Mar 2018 13:12:06 +0100

That's why we worked in a more "updated" document:

But anyway, I still think RFC6177 needs to be updated and have a stronger language.

Regards,
Jordi
 
-----Mensaje original-----
De: ipv6 <[email-masked]> en nombre de DY Kim <[email-masked]>
Fecha: sábado, 24 de marzo de 2018, 13:08
Para: Lee Howard <[email-masked]>
CC: <[email-masked]>
Asunto: Re: SLAAC on non-/64 networks

    
    
    ---
    DY

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Mar 2018 08:53:15 +1300

> If RFC 6177 suffices, then why do you have to keep the constant 64 in RFC 4291? It would do no harm to remove 64 from RFC 4291. Why do people object to that while it would do no harm to the communi…

There is a balance of power between the IETF+IAB, the RIRS, and the ISPs.
Management of the routeable IPv6 address space belongs to IANA (see RFC1881,
an IAB document). IANA has delegated it to the RIRs, whose constituents are
the ISPs.

I say "IETF+IAB" because RFC3177 was an IAB+IESG document (I had a hand in it).
RFC6177 replaced it, and is an IETF document that includes a lot of feedback from
the RIR community. Updating it without deep consultation with the RIRs would be
pointless. This stuff really works by consent among all parties, not by dictatorship
from the IETF. The ISPs are under commercial pressures as well as depending
on industrial products, including CE routers.

The more I think about it, the more I realise that it's the mass-market CE routers
that maintain the /64 boundary, not the text of any RFC.

    Brian

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 08:03:17 +0900

I might like to confirm from the statement below that removing 64 from RFC 4291 won’t disrupt the good status-quo practice of the market to maintain the /64 boundary.

---
DY

> On 25 Mar 2018, at 04:53, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Sun, 25 Mar 2018 08:13:58 +0900

It still will.  What's maintaining the /64 boundary isn't CPEs, but
the fact that SLAAC doesn't work on non-/64s...IMHO.

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 09:07:29 +0900

To be exact, removing 64 from RFC 4291 won’t influence the current level of compliance by the ISPs in issuing prefixes of length /64 or shorter.

That is, there’d be no ‘race to the bottom’ problem which is the main reason why some people object to removing 64 from RFC 4291.

---
DY

> On 25 Mar 2018, at 08:03, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 09:09:54 +0900

SLAAC by design is meant to work on any prefix lengths. It’s RFC 4291 which unnecessarily restrict the operation of SLAAC.

As soon as the limit of the IID length to 64 in RFC 4291 be removed, SLAAC will work fine for any prefix lengths as it was designed.

---
DY

> On 25 Mar 2018, at 08:13, Erik Kline <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 25 Mar 2018 11:58:17 +1100

> That is, there’d be no ‘race to the bottom’ problem which is the main reason why some people object to removing 64 from RFC 4291.

Of course they will. Allocating a single /64 site is already starting
to race to the bottom, when the advice in RFC3177 is to provide at
least as many /64s as there links at a site.

The reason they're giving out a /64 is that it has been stated as the
smallest unit of address allocation. Effectively change that to /128,
by removing the /64 boundary, will cause them to use that number as
their minimum allocation.

People might not think removing the /64 boundary means changing it to
/128, but it effectively does. Why? When people don't have experience,
fear the unknown, have no strong guidance, and just want follow a
recipe that just works, they, quite reasonably resort to what they
consider to be the least risky choice - what they know and are
familiar with. That's CIDR IPv4, with a single public address per site
and NAT.

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 10:39:40 +0900

> On 25 Mar 2018, at 09:58, Mark Smith <[email-masked]> wrote:
> 

Removing the /64 boundary does not mean to allocation of /128 by ISPs.

> familiar with. That's CIDR IPv4, with a single public address per site

Just your imagination for what has yet to be seen. You dream of the worst. You’re effectively threatening the community with your negative dream.

And whom do you mean by ‘people’? ISPs? End site users? I cannot imagine any reasonable ISPs would think the stupid ways you described above.

RFC 6177 is there to guard against the race to the bottom ‘by the ISP’.

As to the end site users…. What the user nodes would do further with the given prefix of /64 or shorter should not be the concern of the third party. That specifically does not belong to the problem of ‘race to the bottom by ISPs’; nothing to do with that.

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 10:54:37 +0900

In a healthy competitive market, ISPs would in fact race to the opposite direction, i.e., race to the top.

  “I’ll give you more prefixes (shorter prefixes with much more address space) than other ISPs, at the same monthly rate.”

  “The other guy gives you a /64? Well, I’ll give you a /56 or even /48 at the same price, so be my customer. That doesn’t cost me any different anyhow.”

---
DY

> On 25 Mar 2018, at 10:39, DY Kim <[email-masked]> wrote:
> 
> I cannot imagine any reasonable ISPs would think the stupid ways you described above.
>

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 10:58:01 +0900

Arguments for the fixed /64 boundary even reminds me of the familiar BIG BROTHER strategies to confine and exploit you within a walled garden.

---
DY

> On 25 Mar 2018, at 10:54, DY Kim <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 25 Mar 2018 13:43:15 +1100

Hi Brian,

On Sat., 24 Mar. 2018, 12:49 Brian E Carpenter, <[email-masked]>
wrote:

> The problem is discussed in https://tools.ietf.org/html/
> draft-bourbaki-6man-classless-ipv6-03#section-3

So I think the trouble with that draft is that it starts out, including in
its title, making assertions that aren't really true, and then uses them as
the basis of argument.

It implies that IPv6 is currently considered "classful" with the /64
boundary, yet there are no distinct Class "A, B, C, D and E" types of IPv6
addresses.

It says that the /64 boundary is rigid (i.e fixed, unbending), yet if that
were the case, it is likely that there would be clearly separate network
and host/node/interface address fields, as there was in at least XNS/IPX
and AppleTalk. It wouldn't be possible to use anything else but /64 if it
was a rigid boundary.

If IPv6 was "classful", with a rigid boundary between the network and
node/host address fields at /64, then BCP198 (i.e. longest match on the
entire 128 bit address field) would have to separately describe the two
lookup methods for the network and host/node/interface parts of the
address, because they could be different (as IPX's is, for example, with a
longest match on the 32 bit address field, and exact match on the 48bit
host/node field).

I would describe /64 as much closer to an addressing convention, default
and a medium "strength" boundary, than a rigid, classful and hard boundary.

The one thing I would change about it is to state that it only applies to
currently defined unicast IPv6 address spaces (i.e. GUA, ULA), and that if
a new unicast address space is defined in the future, then a statement of
whether the 64 bit IID applies or not will be made at that time. That would
provide the opportunity to entirely re-evaluate and change the addressing
structure we have in the future if it proves necessary to do so.

Regards,
Mark.

> >> The IoT network on my mountain is just an imaginary example to
> illustrate my case; I don’t even own a mountain, in fact…
> >>
> >>   - Specific requirements of /64, understandably with good reasons,
> should be documented in separate standards. RFC2462 is an example. Any
> further similar requirements be in RFCs similar to 2464.
> >>
> >>
> >> I’m not sure whether one of my documents named ‘sid6’ once posted to
> v6ops is a stuff belong to the MLSR class, but, at the moment, I’d not dare
> do that since it involves additional texts to both RFC 4291 (arch) and RFC
> 4861 (nd6).
> >>
> >> Trying to change/extend/add even a word in those documents seem
> implausible, at least to me. I’m still struggling to grasp the real meaning
> of ‘rough consensus’. I begin to wonder if there’s a group with a veto
> right you have to get over… Fatally discouraged…
> >>

---

From: DY Kim <[email-masked]>
Date: Sun, 25 Mar 2018 11:52:43 +0900

So, any new unicast address you imply is anything other than ‘global’? Anything other than /64 boundary is a second-class citizen…?

With the fixed /64 boundary, the current IPv6 address is surely ‘glassful’:

   prefix (64) + iid (64)

It’s not the wording (Class A, B, etc.) but the context that matters.

---
DY

> On 25 Mar 2018, at 11:43, Mark Smith <[email-masked]> wrote:
> 
> it only applies to currently defined unicast IPv6 address spaces (i.e. GUA, ULA), and that if a new unicast address space is defined in the future

---

From: Mark Smith <[email-masked]>
Date: Sun, 25 Mar 2018 14:36:18 +1100

> In a healthy competitive market, ISPs would in fact race to the opposite direction, i.e., race to the top.

Agree.

IETF changing /64 won't create a health competitive market if there
isn't already one. Monopoly providers can and are usually likely to
create artificial scarcity for any resource they sell or provide
because they can.

There's a commercial market for VPNs to overcome VOD geoblocking,
indicating that it is cheap enough to send bulk traffic over a
potentially much longer path to overcome that constraint. They or
others could evolve to provide proper amounts of IPv6 address space to
end sites for same reason in monopoly markets. It could be a market
that a CPE vendor might choose to get into using automated tunnels via
an annual maintenance subscription model.

I think the real problem is education. It is some ISP's carrying over
their IPv4 scarce address space mindset to IPv6, rather than doing
some maths to realise how much bigger their allocation of IPv6 address
space is, or at least following RFC3177 advice, and it is their
customers not making having enough /64s for all their links to be an
IPv6 deal breaker.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 25 Mar 2018 16:26:23 +1100

> And whom do you mean by ‘people’? ISPs? End site users? I cannot imagine any reasonable ISPs would think the stupid ways you described above.

So how do you explain that per Jordi's survey, 33% of the ISPs in the
survey giving customers a single /64?

https://blog.apnic.net/2017/10/16/ipv6-deployment-survey-update/

"The numbers for prefix sizes for the customer site remains constant
with 22% using a /48, 36% a /56 and 33% a /64."

Remember that all of these ISPs have at least a /32 from their RIR,
meaning they each have more than 4 billion /64s. How can they
objectively justify giving out just a single /64 to their customers
when they themselves have been provided with more than 4 billion /64s
by their RIR?

> RFC 6177 is there to guard against the race to the bottom ‘by the ISP’.

Hasn't worked in 33% of cases in the above survey.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 25 Mar 2018 07:01:51 +0100

> survey giving customers a single /64?

"Whereof one cannot speak, thereof one must be silent."
(https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus)

One might ask... but if not, it's impossible to tell -- unless we want
to enter the game of guesswork.

That aside, I don't think it's our job to police ISPs, but rather
providing good recommendations.

Thanks,

---

From: DaeYoung KIM <[email-masked]>
Date: Sun, 25 Mar 2018 17:44:30 +0900

Sent from my iPhone

> On 25 Mar 2018, at 14:26, Mark Smith <[email-masked]> wrote:
> 

What makes you think that’s anything Camp Change has to explain? On the contrary, it ought to be Camp NotChange who has to provide an explanation for that. The 33% phenomenon is something that happens in the status quo of NotChange, and all I can tell you, if I must, is that the constant 64 in rfc 4291 is to blame for that.

Or at least, all I observe is that the claim that that 64 is the backstop against the race to the bottom is not grounded.

> Hasn't worked in 33% of cases in the above survey.

Be reminded again all that comes in play at this game now, with Change not yet adopted are:

  - rfc 4291: “... IID length IS 64 bits.”

  - rfc 6177: soft language recommendations not even with either SHOULD or MUST.

And also don’t fail to note that ‘IS’ is a much stronger word than SHOULD or MUST, for ‘IS’ leaves not a bit of space for any other possibilities.

Then, which of the two above is more responsible for the misbehavior of the ISPs? Obviously, it’s rfc 4291. 

If we grade the level of strength of words like

   IS:               ****
   MUST         ***
   SHOULD    **
   soft lang.   ^

then

   rfc 4291.     ****
   rfc 6177.      *

That is, rfc 4291 is much more responsible for the situation, for it’s rfc 4291 which holds a dominating command over the case with much stronger language weighing 4 times that of rfc 6177.

So, Camp NotChange please provide an explanation for that 33% phenomenon.

Curious to hear about that.

---

From: Lee Howard <[email-masked]>
Date: Sun, 25 Mar 2018 09:45:00 +0100

How many RFCs do people think an operator reads before deploying IPv6?

RFC6177 uses gentle language to relax a requirement, but clearly 
reinforces the 64 bit minimum.

Lee

---

From: Ole Troan <[email-masked]>
Date: Sun, 25 Mar 2018 11:07:19 +0200

There are many reasons an ISP would have to only give out a single /64. 

- mobile. Handsets aren’t very good routers (yet). And don’t support PD. 
- need. Many customers need only a single link. And get more if they ask
- cpe support. Some older cpes only supported /64. 

Ole

> On 25 Mar 2018, at 10:44, DaeYoung KIM <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 25 Mar 2018 11:16:27 +0200 (CEST)

> - mobile. Handsets aren’t very good routers (yet). And don’t support PD.

/64 to the handset, because 3GPP standard says so. They have much more 
stringent standards. Let's call it a "profile", that includes specific 
parameter settings to standards that might be their own or from other SDOs 
(such as IETF).

> - cpe support. Some older cpes only supported /64.

Do we have more data on this issue?

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 25 Mar 2018 13:35:31 +0200

> that maintain the /64 boundary, not the text of any RFC.

There may be a point in feeling that the mass-market CE routers maintain 
the /64 boundary.

I am going through experience with some modem manufacturer. It is now
almost a year long activity to get beyond the /64 limit in the modem.
The key technical reason is a belief at the manufacturer that 'that
[/64] is the design of IPv6'. I bet it is an RFC that influences that
belief.

On another hand, that particular modem manufacturer _is_ open to satisfy
requests of operator who is itself open to desires of end-users. Other
modem manufacturers do not impose /64 limits at all. So it is encouraging.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 25 Mar 2018 13:47:17 +0200

[...]
> /128,

On another hand, bridging one /64 into many /128s is a dead end, because
it does not scale. Although theoretically many 128s fit a single
/64, the brigding technology for the relevant use-cases is absent (e.g.
no LTE-to-Ethernet bridging) and when it exists it does not scale to
2^64 addresses in a subnet by any means.

(we can talk how bridging works separately, if one so wishes).

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Mar 2018 08:28:28 +1300

> boundary, yet there are no distinct Class "A, B, C, D and E" types of IPv6

Well, the use of "classful" in the draft is metaphorical. 
 
> and AppleTalk. It wouldn't be possible to use anything else but /64 if it

The problem is that although some IPv6 RFCs say that the boundary is
flexible (including RFC4291), others define it as rigid (including RFC4291).

> longest match on the 32 bit address field, and exact match on the 48bit

That's exactly where BCP198 is inconsistent with part of RFC4291.
 
> and a medium "strength" boundary, than a rigid, classful and hard boundary.

Others say that if we change it, the sky will fall.

> structure we have in the future if it proves necessary to do so.

I agree, but I seem to remember that was one of the variants of 4291bis
that failed to gain consensus.

Regards
    Brian

---

From: Lee Howard <[email-masked]>
Date: Sun, 25 Mar 2018 20:41:00 +0100

> Do we have more data on this issue?

Like what, a device count? Make/Model/Version?
When I started deploying, we had three models of modem that would brick 
if they received anything other than a /64. They were DOCSIS 3.0 modems 
we bought before the DOCSIS 3.0 spec was published, in 2008 if I recall 
correctly. So we defaulted to /64 and told all of our current vendors to 
hint for /56.

Lee

---

From: Mark Smith <[email-masked]>
Date: Mon, 26 Mar 2018 07:16:35 +1100

On 25 March 2018 at 17:01, Fernando Gont <[email-masked]> wrote:

> >> Just your imagination for what has yet to be seen. You dream of the
> worst. You’re effectively threatening the community with your negative
> dream.
> >>
> >> And whom do you mean by ‘people’? ISPs? End site users? I cannot
> imagine any reasonable ISPs would think the stupid ways you described above.
> >
> >

I may not always produce it, however I do usually have evidence up my
sleeve for assertions I make.

"Exetel still don't offer proper IPv6"
http://forums.whirlpool.net.au/archive/2614384

"Order Additional IP Addresses Service"
...
"/56 block of IPv6 addresses $0.00 $200.00"

(That's from 2017. You can get up off the floor now.)

"IPv6 Default Allocation - What size allocation are you giving out"
https://mailman.nanog.org/pipermail/nanog/2014-October/070339.html

"I guess the idea of handing a customer /56 (256 /64s) or  a /48 (65,536
/64s) just makes me cringe at the waste. Especially when you know 90% of
customers will never have more than 2 or 3 subnets. As I see it the
customer can always ask for more IPv6 Space."

That thread was from 2014. There was another one in December last year that
again covered the same ground, with some expressing the same sentiment.

This was my favourite quote from somebody who's saying IPv6 allocations are
too wasteful.

https://mailman.nanog.org/pipermail/nanog/2017-December/093679.html

"There are 10^38 IPv6 addresses but only 10^19 IPv6 /64 LANs."

"only"!. I wish I "only" had 10^19 cents in the bank, 10^19 seconds left to
live, 10^19 breaths left to take, ...

> providing good recommendations.

This isn't about policing. The IETF can't police what operators do. What
the IETF does have to do is choose default values for parameters that
promote interoperability between implementations, and best achieve the
specific design goals.

This is about having a single, default value for a parameter that is
optimal for the common cases, and that reliably facilitates capabilities
IPv6 has and can have over CIDR based IPv4 with NAT, such as privacy
addresses, and stable opaque addresses.

Values other than /64 could have achieved that e.g. /80, however /64 has
been that value for 20+ years.

The only issues with /64 look to be that some operators have considered it
to be the allocation size for a site, rather than for an individual link,
and some consider it wasteful, despite its large and fixed size providing
useful value for end-users and operators ("waste" only occurs when no
useful value is attained from a particular resource).

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Mar 2018 07:57:41 +0200 (CEST)

> Like what, a device count? Make/Model/Version?

I'm trying to understand the scope of the problem. Is this still a problem 
in products that are still in the field? Any special types of access media 
where this is more common, for instance your DOCSIS example below. Is this 
still a problem in firmware these devices have?

> When I started deploying, we had three models of modem that would brick if 
> they received anything other than a /64. They were DOCSIS 3.0 modems we 
> bought before the DOCSIS 3.0 spec was published, in 2008 if I recall 
> correctly. So we defaulted to /64 and told all of our current vendors to hint 
> for /56.

That's a good data point.

---

From: Lea Roberts <[email-masked]>
Date: Mon, 26 Mar 2018 03:53:53 -0700 (PDT)

hello again, Jordi -

some other thoughts inline...

> In RFC3177 it was "use always /48".

actually, RFC3177 said "use /48 or /64 or /128" and ISPs were doing /64s

On Sat, 24 Mar 2018, JORDI PALET MARTINEZ wrote:

> In my opinion, it will help to revise RFC6177 and make a stronger 
> language against not only a single /64 but options such as only a "few"
> /64s.
>

Jordi, I think Brian Carpenter's reply, included below, describes
better than I could what would be involved in revisiting RFC6177...

the consensus was that address assignment was in the realm of the
RIRs, which we tried to reflect in the document.  we also believed
prefix assignments longer that /48 should be allowed.

I think that if you feel strongly about writing a prefix assignment
size document, it might be more appropriate in v6ops these days...
but if there is a consensus for a 6177bis, I would join in.

I think Brian is also onto something in blaming the low-budget CE
routers for the persistance of /64 assignments, so you might want to
make sure the DHCP-PD is a SHOULD in router requirements?  (I know
that work is in progress but I haven't been following it closely.)

On Sun, 25 Mar 2018, Brian E Carpenter wrote:

>> Are you saying that the recommendations of RFC 6177 are well observed 
>> even if should and must are not capitalized.
>> 
>> If RFC 6177 suffices, then why do you have to keep the constant 64 in 
>> RFC 4291? It would do no harm to remove 64 from RFC 4291. Why do people
>> object to that while it would do no harm to the community?
> 

it certainly seems that there need to be continued efforts made to
change the prefix assignment mindset to be generous with IPv6 and
allow sufficient subnets to users!

best regards,
/Lea

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Mar 2018 13:13:58 +0200 (CEST)

On Mon, 26 Mar 2018, Lea Roberts wrote:

> make sure the DHCP-PD is a SHOULD in router requirements?  (I know that 
> work is in progress but I haven't been following it closely.)

https://tools.ietf.org/html/rfc7084

If it's not by default asking for a /60 (and support this), it's not 
RFC7084 WPD-2/3 compliant.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 26 Mar 2018 13:14:29 +0200

Hi Lea,

Responses below in-line.

Regards,
Jordi
 
-----Mensaje original-----
De: Lea Roberts <[email-masked]>
Fecha: lunes, 26 de marzo de 2018, 12:54
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: RFC6177 and prefix assignment size (was Re: SLAAC on non-/64 networks)

    hello again, Jordi -

    

Yeah, I meant that the general case was recommending /48 ("it recommends the assignment of /48 in the general case"). When we moved to not so strong language in RFC6177, it has been interpreted, as "we can just do /64". I know is a matter of education/ignorance, but we can make it better in the text.

    

Agree, should be allowed, but with a stronger recommendation, I will say.

Agree, v6ops is the way. If you have the XML file, we can start working on that. I'm happy to edit a first version. If you don't have it, let me know and I will ask to the RFC editor, who typically can provide it.

It is already a MUST in RFC7084. I will say that this was a problem in the earlier router implementations, but I don't think it is anymore today.

    

Let's move on !
    
    best regards,
    /Lea

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 26 Mar 2018 13:17:44 +0200

I was reading this part:

W-4:  The router MUST act as a requesting router for the purposes of
         DHCPv6 prefix delegation ([RFC3633]).

Most of the routers today have 4 LAN ports, plus 1-2 radios, so that will mean 6 subnets, rounded to the nearest nibble.

However I don't think routers today have a restriction, to support only /60 (for example).

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 26 Mar 2018 14:24:43 +0200

Forgot to mention that also most of the CPEs today support several SSIDs, so it means probably the smaller prefix a CPE should be able to allocate must be shorter than /60, just to be in the "safe" side, and this not considering homenet and downstream routers, which is becoming quite normal.

Anyway, I still believe is not a real CPE restriction today, is more a mentality change.

Regards,
Jordi
 
-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]>
Fecha: lunes, 26 de marzo de 2018, 13:17
Para: Mikael Abrahamsson <[email-masked]>, Lea Roberts <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: RFC6177 and prefix assignment size (was Re: SLAAC on non-/64 networks)

    I was reading this part:

    
    
    Regards,
    Jordi

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2018 13:46:07 +0100

> RFC7084 WPD-2/3 compliant.

You meant /64?

(configurable to do != doing)

Thanks,

---

From: David Farmer <[email-masked]>
Date: Mon, 26 Mar 2018 08:38:15 -0500

On Mon, Mar 26, 2018 at 6:13 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> I think Brian is also onto something in blaming the low-budget CE routers
>> for the persistance of /64 assignments, so you might want to make sure the
>> DHCP-PD is a SHOULD in router requirements?  (I know that work is in
>> progress but I haven't been following it closely.)
>>
>

Maybe that point should be pushed a little harder in WPD-2, by adding
something like the following;
"In many cases, this means CE routers will be asking for a /60 or even a
/56 prefix."

Thanks

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2018 14:45:10 +0100

On 03/26/2018 02:38 PM, David Farmer wrote:
> 
> On Mon, Mar 26, 2018 at 6:13 AM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         I think Brian is also onto something in blaming the low-budget
>         CE routers for the persistance of /64 assignments, so you might
>         want to make sure the DHCP-PD is a SHOULD in router
>         requirements?  (I know that work is in progress but I haven't
>         been following it closely.)
> 
> 
>     <https://tools.ietf.org/html/rfc7084>
> 

Maybe this should have been "Ask more than a /64, and fail if the
request is not granted". Then you are not playing the "run to the
bottom", and need not keep the /64 enforced in places where you
needn't/shouldn't.

Thanks,

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Mar 2018 14:08:33 +0000

> From Fernando Gont
> Maybe this should have been "Ask more than a /64, and fail if the request is
> not granted". Then you are not playing the "run to the bottom", and need
> not keep the /64 enforced in places where you needn't/shouldn't.

So all CE routers being used in fixed wireless environments fed by a "LTE antenna +" that converts the RA A prefix (assumed delegation via RFC 7278) into a DHCPv6 IA_PD /64 offer to the CE router should fail? Because the choices are either accept that /64 or no IPv6. 
And perhaps 6rd deployments where only a /64 is supplied (and there is no DHCPv6) should also start to fail? 
No. I'm opposed to that.
Barbara

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2018 15:12:47 +0100

> And perhaps 6rd deployments where only a /64 is supplied (and there is no DHCPv6) should also start to fail? 

If folks want to avoid the "run t the bottom", the place to enforce it
is at the CPE (it should, say, fail or complain if it cannot get more
than /64) rather than squeeze/enforce a requirement of /64 everywhere,
and pretend that that has anything to do with "architecture".

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Mar 2018 16:45:06 +0200 (CEST)

...
> (configurable to do != doing)

No, I meant /60. "rounded up to nearest nibble" on a 4 LAN port router 
would be /60.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Mar 2018 14:55:03 +0000

> From: Fernando Gont 
> > So all CE routers being used in fixed wireless environments fed by a "LTE
> antenna +" that converts the RA A prefix (assumed delegation via RFC 7278)
> into a DHCPv6 IA_PD /64 offer to the CE router should fail? Because the
> choices are either accept that /64 or no IPv6.
> If folks want to avoid the "run t the bottom", the place to enforce it is at the
> CPE (it should, say, fail or complain if it cannot get more than /64) rather than
> squeeze/enforce a requirement of /64 everywhere, and pretend that that
> has anything to do with "architecture".

I agree with you completely that the artificial /64 boundary has nothing to do with architecture. And the "race to the bottom" argument is based on FUD. It can be neither proven nor disproven, and has no foundation in science. It's a belief.
And when people are debating religious beliefs it's not good to given them ideas like "make CE routers fail" under scenarios that currently work. Some people might think that's a good idea and pursue it.

But we could suggest a requirement that a CE router not accept IA_PD of less than /64. Then use HNCP to distribute shorter prefixes inside a LAN. Or even an RA mechanism. That wouldn't break any current deployment. It would prevent ISPs from being able to delegate longer prefixes. Especially if it got picked up by BBF and CableLabs specs (and I'd have no problem getting this in BBF). And especially if we got it in the CE router IPv6 Ready certification.
Barbara

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2018 16:08:56 +0100

> But we could suggest a requirement that a CE router not accept IA_PD of less than /64. Then use HNCP to distribute shorter prefixes inside a LAN. Or even an RA mechanism. That wouldn't break any cu…

FWIW, agree with everything that you said above.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Mar 2018 17:42:12 +0200

> No, I meant /60. "rounded up to nearest nibble" on a 4 LAN port router 

I always wondered why 'rounded to a nibble'.  /63 should be fine as 
well.  There are routers with just 2, or 3 ports.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 26 Mar 2018 18:00:37 +0200 (CEST)

> well.  There are routers with just 2, or 3 ports.

If you want to delegate reverse-DNS then nibble boundaries fit nicely.

---

From: James R Cutler <[email-masked]>
Date: Mon, 26 Mar 2018 12:09:05 -0400

> On Mar 26, 2018, at 12:00 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> 
>>> No, I meant /60. "rounded up to nearest nibble" on a 4 LAN port router would be /60.
>> 
>> I always wondered why 'rounded to a nibble'.  /63 should be fine as well.  There are routers with just 2, or 3 ports.
> 
In addition to simplifying reverse DNS configuration, it can ease comprehension of the relationship of the boundary position and the written form since a nibble corresponds to one hexadecimal digit.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 Mar 2018 12:44:14 +0100

STARK, BARBARA H wrote:
> I agree with you completely that the artificial /64 boundary has
> nothing to do with architecture. And the "race to the bottom"
> argument is based on FUD. It can be neither proven nor disproven, and
> has no foundation in science. It's a belief.
> And when people are debating religious beliefs it's not good to given
> them ideas like "make CE routers fail" under scenarios that currently
> work. Some people might think that's a good idea and pursue it.

All this is true.

It is disturbing the degree to which religion and politics are used to
shut down protocol development / discussion on v6ops and 6man.

Nick