Waste will kill ipv6 too

Brock Tice brock at bmwl.co
Fri Dec 29 03:26:46 UTC 2017


Hi Lyndon, thanks for taking the time to address my questions. Responses
below.

On 2017-12-28 17:57, Lyndon Nerenberg wrote:
>> On Dec 28, 2017, at 3:28 PM, Brock Tice <brock at bmwl.co> wrote:
>> We are currently handing out /52s to customers. Based on a reasonable
>> sparse allocation scheme that would account for future growth that
>> seemed like the best option.
> Could you detail the reasoning behind your allocation scheme?  I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated?  What data fed the model you used to come up with those numbers?

I am going to address a bunch of these together below.

> I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers.  I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with.
> 
>> I can't really see how /52 is too small for a residential customer. I
>> know originally it was supposed to be /48 but after doing a bit of
>> reading I think many people have admitted there is room for nuance.
> What reading?  Can you provide pointers to the documents you were reading?  Again, I'm curious to understand how and why ISPs are making these decisions.
> 
> Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't.  An ISP's job is to shovel packets around.  No more, no less.

I think with a little more nuance, an ISP's job is to manage resources
properly in order to shovel packets around as well as possible. In this
case, IP address space.

>> Do you think I could go to ARIN and say, well, we haven't used hardly
>> any of this but based on such-and-such allocation scheme, it would be
>> much better if you gave us a /32 instead of a /36?
> Hardly used any of what?  Are you talking about density of the customer hosts inside each of these /64 subnets?  This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from.

No, see below. I'm talking about the fact that we've got a sparse
allocation scheme and even within that most of the subnets we've
allocated for towers don't have towers attached to them. They certainly
could in the next decade, though.

> Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment?  

No

>> Also, does anyone know whether ARIN is using sparse allocation, such
>> that if we go back later and ask for more they will just increase the
>> size of our allocation starting from the same point?
> You could just ask them.  But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.†
> 
> But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers?

I'm just wondering if I'm likely to have to renumber just to go to a
more generous allocation scheme. I guess better now than in 5 years if so.

> You need to treat IPv6 addresses as being 64 bits long.  Those extra 64 bits on the right are just noise – ignore them.  Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network.  That makes for a densely allocated /48 for each person on the planet.  (Coincidence?)  But when we get to the point of filling up that /3, we still have five more /3s to work with.

OK addressing all of the rest of this here. I'm admittedly no expert on
IPv6, I've been forced to learn it in a hurry. I did read most of
"Migrating to IPv6" by Marc Blanchet and "IPv6 Address Planning" by Tom
Coffeen. I believe I read quite a few things about deciding on subnet
sizing there.

>From those books I basically learned to think in /64s (generally one per
router interface). I'm not very concerned with the number of hosts in a
/64 for obvious reasons.

Most of our customers only have 2-5 devices. I know this is not the case
in most of America but we are quite rural and for many people they've
never had better than 1.5Mbps DSL until we install service at their
location. Most of them have no idea what a subnet is. Let us say that
over the next ten years they get quite savvy and decide to isolate their
wireless clients, some public servers, their IoT devices, and their
security cameras. We have given them a /52 which contains 4096 /64s. So,
most likely, they will use one of those for their LAN and be done. In
case they decide to make several VLANs or whatever they have used 4 /64s
and they have 4092 left.

Well, maybe, you say, they want to do something more hierarchical. Ok,
they have 16 /56s they can split into 16 /60s and they can split those
into 16 /64s.

So now for my customers that have expanded to like 10 devices they can
give them their own /56 each.

I will again say I am indeed no expert, I am happy to get feedback. Is
there some kind of allocation scheme where a residential user or even a
small or medium business will have any chance of using 4096 /64s?

> Now think about scaling.  If the population doubles, we're now down to four spare /3s.  If that doubled population doubles the number of devices, we're down to two spare /3s.  If the population doubles again, there will be no civilization left, let alone an Internet.  Etc.  So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes.  Each node having its own /64 to address individual endpoints within whatever that 'node' represents.  Just think, 2^64 port-443 HTTPS servers per "thing."  Isn't this the utopia we've been seeking out?
> 
> I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space.

If the correct answer is just "ask for more space", which is the sense
I'm getting, then I should probably just do that. I do really appreciate
the feedback.

--Brock




More information about the NANOG mailing list