Addressing plan exercise for our IPv6 course

Fri Jul 23 09:13:22 UTC 2010

Well said.

One more reason is transition mechanisms.

For example, 6to4, TBs, manual tunnels, those are just a few examples, which
use/provide /48.

We have today many customers using /48, which have already their own
internal addressing plans, or manual subnets configured internally.

Are you going to tell them now that you provide a dual stack service with
less subnets and they need to remake their addressing plan and/or renumber ?

Those customers are smart, they will look to your competitors and look for a
better provider.

No economical reason to provide "less" subnets to customers, many economical
reasons to provide them as many subnets as you can, avoid wasting time,
renumbering, etc., and being able to provide more applications that may be
easily deployed in different subnets. Yes, 16 bits subnets are a lot, but
time cost more, announcing more prefixes per customer is even more
expensive, even for residential customers that will use more and more
applications and services requiring them.

You don't want to manage again a more complex network specially if as Tony
Hain calculated some time ago, providing /48 for every possible customer in
the Earth will mean IPv6 will last 480 years.

Do you really believe we will keep using IP (not talking about v4 or v6) as
we know it today ? I bet in less than 100 years we will need, for other
reasons different than the need for more addresses, a new protocol.

Why we insist in making things complicated againg, I guess because humans
like complicated life !

Regards,
Jordi

> From: Marco Hogewoning <marcoh at marcoh.net>
> Reply-To: <marcoh at marcoh.net>
> Date: Fri, 23 Jul 2010 10:06:43 +0200
> To: Matthew Walster <matthew at walster.org>
> Cc: nanog list <nanog at nanog.org>
> Subject: Re: Addressing plan exercise for our IPv6 course
> 
> 
> 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
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

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