Addressing plan exercise for our IPv6 course

Marco Hogewoning marcoh at marcoh.net
Fri Jul 23 08:06:43 UTC 2010


On 23 jul 2010, at 01:33, Matthew Walster wrote:

> On 22 July 2010 14:11, Alex Band <alexb at ripe.net> wrote:
>> There are more options, but these two are the most convenient weighing all
>> the up and downsides. Does anyone disagree?
> 
> I never saw the point of assigning a /48 to a DSL customer. Surely the
> better idea would be to assign your bog standard residential DSL
> customer a /64 and assign them a /56 or /48 if they request it, routed
> to an IP of their choosing.


/64 is too small, especially when sensornetworks take off you probably want multple ranges.

In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one.

Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum.

So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing.

First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day.

Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need  more did the rest.

So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway.

So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk that I lose business because the shop across the road does offer /56 or even /48.

Which brings me into the economics, we are in a hurry. We need to deploy and we need to deploy yesterday. In fact if you are not running IPv6 by now, you are too late. So I have the choice of creating a really complicated deployment scheme in which I can assign variable subnet lenghts to customers without breaking aggregation and without annoying them with renumbering. One-size-fits-all makes life easy and saves an huge pile of money and not only money but it saves time, time I need, beacuse we are already a bit late.

In short, why a /48 'Because we can!'. We had about 15 years to design a proper scheme, we failed. Now we can discuss a redesign, but then we need to squeeze another 10 years out of IPv4.

MarcoH





More information about the NANOG mailing list