Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)

From: RJ Atkinson <[email-masked]>
Date: Wed, 6 Aug 2014 14:27:08 -0400

On 06  Aug 2014, at 13:54 , David Farmer wrote:
> Or, are you suggesting that the simplicity of SLACC with
> a single IID length is important for minimising technical
> infrastructure and network management effort, especially in
> small enterprises? 

Yes, to the *edited* text above. 

(Of course the same comment also applies to a number of other
deployment scenarios, for example residential networks,
but my note was focused on "small enterprises".)

Yours,

Ran

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Aug 2014 20:37:59 +0200

> but my note was focused on "small enterprises".)

Whereas I consider the small enterprise perspective very enriching, I 
disagree with the conclusion on SLAAC.

Other than big and small enterprises, there are many single users who 
need to grow their networks beyond what their suppliers consider to be edge.

The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to 
that growth.

Alex

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2014 10:09:17 +1200

>> but my note was focused on "small enterprises".)

We already have some language about the benefits of simplicity,
which I personally see as important for any size of network,
not excepting campus networks. (I have discussed this exact point
with colleagues managing address space for a large campus). Ran
is undoubtedly correct that the benefit is even greater for small
networks which probably have part-time, non-expert managers, or
fly-by support technicians who look after dozens of such customers.
Short of 100% autonomic configuration, simplicity and homgeneity
is highly desirable.

> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to

I could only agree to that if everything is zero-conf. Such users
can't handle complex choices. Anyway, that is out of scope for this
draft, isn't it?

   Brian (anxious to start editing the next version...)

---

From: Steven Blake <[email-masked]>
Date: Wed, 06 Aug 2014 22:28:55 -0400

> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to 

How so?  Are you saying that there are single users that aren't able to
get sufficient space (say /56 or shorter) from their providers?

Regards,

// Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Aug 2014 22:46:53 -0400

It strikes me that if we start permitting subnet lengths longer than 64, 
than any operator who is so stingy that they are currently giving out 
/64s will likely switch to giving out whatever other length we tell them 
is the longest permissible.

Hence, I really don't think the answer to oeprator misunderstqnding is 
changing the prefix rules.

Yours,
Joel

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 6 Aug 2014 22:43:37 -0700

----- Original Message -----
> From: Joel M. Halpern <[email-masked]>
> To: Steven Blake <[email-masked]>; Alexandru Petrescu <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, 7 August 2014 12:46 PM
> Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
> 

Agree, it is a slippery slope.

Operators who're thinking this way might be just trying to continue the practice where different levels of service were dependent on address attributes e.g., residential customers get dynamic addresses, business customers get static addresses/routed prefixes at a much higher cost.

I think operators who try to continue this sort of practice, by creating artificial IPv6 address scarcity, will find their competitors quickly stealing business from them because of it. They should think about find something else about their service to win customer business with.

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 09:50:06 +0200

Le 07/08/2014 00:09, Brian E Carpenter a écrit :
>>>> Or, are you suggesting that the simplicity of SLACC with a
>>>> single IID length is important for minimising technical
>>> deployment scenarios, for example residential networks, but my
>>> note was focused on "small enterprises".)
>
> We already have some language about the benefits of simplicity, which
> I personally see as important for any size of network, not excepting
> campus networks. (I have discussed this exact point with colleagues
> managing address space for a large campus). Ran is undoubtedly
> correct that the benefit is even greater for small networks which
> probably have part-time, non-expert managers, or fly-by support
> technicians who look after dozens of such customers. Short of 100%
> autonomic configuration, simplicity and homgeneity is highly
> desirable.
>
>>
>> Whereas I consider the small enterprise perspective very enriching,
>> I disagree with the conclusion on SLAAC.
>>
>> Other than big and small enterprises, there are many single users
>> who need to grow their networks beyond what their suppliers
>> consider to be edge.
>>
>> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break
>> to that growth.
>

Right, this risks turning into an argumentation of why SLAAC is
important, presumably vs. DHCP.  This argumentation is out of scope of
this draft discussing 64bit lengths.

Alex

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 09:56:13 +0200

Le 07/08/2014 04:24, Steven Blake a écrit :
> How so?  Are you saying that there are single users that aren't able
> to get sufficient space (say /56 or shorter) from their providers?

Certainly yes, there are single users that aren't able to get sufficient
space, like a /56.  These users are not facing real 'providers'.

The easiness of putting SLAAC on, with Ethernet, is what end users get
in a wifi hotspot area, for example.  At that place the 'provider' is
actually a sysadmin, or more the other-craft-man turned sysadmin for a
few dozens minutes just to action the just unwrapped Access Point.

However, the end users of that hotspot have more than one device to
connect - a Personal Area Network, made of WiFi and Bluetooth devices.
(tablet plus watch, for example, or other IoT Internet of Things).  Or a
vehicle.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 10:49:18 +0200

> changing the prefix rules.

In a sense I agree.  If one changes the 64 barrier to, say 65, then the 
barrier will just move, but not disappear.

Operator misunderstanding - yes, that can be blamed, but only as long as 
there is a real operator acting as one would expect an operator to act. 
  When the operator is more like a non-professional operator (but 
respected professional in that other art), then it is hard to put the 
blame on a human, and easier to put on the architecture.

I think there should exist ways to deal with it such as to not appear as 
a barrier, and to not be moving either.

No, not variable-length addresses.

But maybe stating that (1) the prefix length must not be 128 and (2) if 
the prefix length is 127 then the provider must offer a freely available 
alternative to NAT.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Aug 2014 20:33:41 +0900

On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <[email-masked]>
wrote:

> than any operator who is so stingy that they are currently giving out /64s
> will likely switch to giving out whatever other length we tell them is the
> longest permissible.
>

And after a short while, the race to the bottom ends at /128, and we're all
forced to implement NAT because customers don't want to pay twice to
connect two devices to the same network.

---

From: David Farmer <[email-masked]>
Date: Thu, 07 Aug 2014 08:43:54 -0500

On 8/7/14, 06:33 , Lorenzo Colitti wrote:
> On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     It strikes me that if we start permitting subnet lengths longer than
>     64, than any operator who is so stingy that they are currently
>     giving out /64s will likely switch to giving out whatever other
>     length we tell them is the longest permissible.
>
> And after a short while, the race to the bottom ends at /128, and we're
> all forced to implement NAT because customers don't want to pay twice to

Do we have to drop the NAT-Bomb?  There is no consensus to change the 64 
bit IID at this time, but 64 is not a magic number.  Considering 
alternative IID sizes or even a variable length is NOT equivalent to 
condoning NAT.

Can we have a conversion without hyperbolic NAT-Bombs, please.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Aug 2014 22:48:08 +0900

> alternative IID sizes or even a variable length is NOT equivalent to

Of course it's not equivalent to condoning it. The road to hell is paved
with good intentions :-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:08:14 +0200

Le 07/08/2014 15:48, Lorenzo Colitti a écrit :
> On Thu, Aug 7, 2014 at 10:43 PM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> And after a short while, the race to the bottom ends at /128, and
> we're all forced to implement NAT because customers don't want to
> pay twice to connect two devices to the same network.
>
>
> Do we have to drop the NAT-Bomb?  There is no consensus to change the
> 64 bit IID at this time, but 64 is not a magic number. Considering
> Of course it's not equivalent to condoning it. The road to hell is
> paved with good intentions :-)

One good intention is Prefix Delegation.

But unfortunately Prefix Delegation distributing /64s to whomever asks
is not making for an intuitively simple - aggregated - addressing
architecture.

Alex

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 17:44:44 +0000

Hi Alex,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, August 07, 2014 7:08 AM
> To: [email-masked]

My understanding is that DHCPv6 Prefix Delegation can be used
to delegate prefix lengths up to and including /128, and I have
identified good uses for such "long" prefixes. But, they must
not be assigned to links on which SLAAC is intended to operate;
for that we need /64.

Thanks - Fred
[email-masked]

---

From: Roman Czyborra <[email-masked]>
Date: Thu, 7 Aug 2014 21:22:27 +0200 (CEST)

/me loves your Italian humor :)

2014-08-07[Thu]13:33 Lorenzo Colitti wrote:
>
> On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <[email-masked]> wrote:
>       It strikes me that if we start permitting subnet lengths longer than 64, than any operator who is so stingy that they
>       are currently giving out /64s will likely switch to giving out whatever other length we tell them is the longest
>       permissible.
> 

In my sad State of the Union address I must bitch that http://edis.at/ 
currently hands out 1 IPv4 opening a /48 slice in 6to4 paired with for 
each of my 0f10 front toes exactly one NATtable /128 slice in modern IPv6 
like [2a03:f80:ed15:ed15:ed15:ed15:ed15:c30] just to name the shortest.

At least http://netcup.de/ is generous enough to hand me one usable /64 
slice next to my self-administering 6to4 /48 so I hope that will suffice 
to configure me a static "poor man address family transition routing" with 
plain ip -{4,6} {tunnel,route} from http://packages.debian.org/iproute and 
ip6tables --jump SNAT from http://packages.debian.org/ipfilter replacing 
the ftp://ftp.isc.org/isc/aftr/ flunking in coming up to serve me.

Ciao belle: Romano Czyporro

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 8 Aug 2014 01:01:04 -0700

----- Original Message -----
> From: Alexandru Petrescu <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 8 August 2014 12:08 AM

If I understand this statement correctly, I don't think PD was designed with the intention of just delegating a single /64, but rather an aggregate of many /64s.

That being said, at some point it is necessary to aggregate routes to scale. A broadband ISP supporting millions of subscribers is not going to be able to permanently delegate a prefix of any size (/64, /56 or /48) to the subscriber regardless of where they're connected to the network, because of course it would involve trying and failing to carry all of those routes in all of the ISP's internal routers.

Aggregation at geographic boundaries seems reasonable to me - if people move far enough (different city, different suburb, different PoP etc.) then they should expect to have to a different delegated prefix. As an ISP you could offer, at additional cost, to preserve their original prefix, which fundamentally charging for the individual route table slot they're occupying in all of your routers.