[ppml] 2005-1:Business Need for PI Assignments

[Tony Hain]

Leo, 

What is absurd is making generalizations about design choices without
acknowledging the trade-offs. 

The design point for IPv6 was 10^12 networks with 10^15 endpoints. A 64 bit
space was deemed to be sufficient to accomplish that at .0001 allocation
efficiency. The decisions were being made at the start of the bubble and
there were concerns raised about having sufficient room to handle large
levels of hierarchy to support the growing number of providers. We ended up
giving the whole 64 bits to the routing function and started debating how
many more to use for identifying hosts. Auto-configuration drove the choice
for another 64 bits. Unfortunately we continually have to fight with the
routing community because they are an extremely greedy bunch and insist that
despite consolidation in the number of providers the already provided
addition to more-than-enough is still not enough, also insisting that 64
bits for each lan is a waste without recognizing that there are new
opportunities available by changing the per-device conservation model. It is
long past time to get over it; auto-configuration requires numbers on the
order of 60 bits no matter if you choose random numbers or have a central
registry like the IEEE. In fact the RFID crowd wants to stuff their 96 bit
thingies into an IPv6 address so one could argue that we were short sighted
in giving the bits to the routing function and should really be squeezing
them back down to 32 bits. In any case if routing can't do the job with 64
bits then it is time to find a new routing system.

Much of the insistence on 'doing it the same as IPv4' is in fact a
short-sighted approach that explicitly curtails the ability to do new things
in the application space. Yes we are bad predictors of the future, but we
had the foresight to not allocate the entire space up front. We are working
with 1/8 of the space right now, so if the current policies prove to be
insufficient over the next 50 years we have the opportunity to start over a
few more times which should get us well beyond 100 years. As Geoff & David
pointed out we need to do some revisiting of the H-D ratio percentage for
very large providers in the short term, and that effort alone will probably
get us by. We can also discuss additional recommendations like business
reasons for longer than /48 to customers, but that is more to placate the
business desire to differentiate services than it is to deal with any
lifetime issues. The driving issue for a fixed size was to allow
organizations the freedom to switch providers without having to rebuild
their entire subnet plan. See
http://www.ietf.org/internet-drafts/draft-hain-prefix-consider-00.txt for
discussion about some longer values that would allow people to move between
providers with a consistent bucket size and retain their subnet plan. 

This thread is about PI space. One of the things that is not discussed much
is changing the overall routing model from 'everyone has to know everything'
to regional knowledge. The routing community is saying they don't want a
swamp, but at the same time they don't want to change anything about how
they make routing decisions. The business community is saying that a
provider lock is a non-starter, so we are at an impasse. The natural
reaction by the RIR community is to try to find a simple metric that will
allow differentiating between a global enterprise and a multi-homed consumer
so explicit routing entries can be justified. 

We could talk about making the metric be money, but that would likely drive
an even stronger push by the ITU to take over the process because
governments would rightly perceive that this is a valued resource that
impacts sovereign rights. Just about any other metric will cause an
evaluation of need with some arbitrary and subjective outcomes. Perception
of inequity is a problem where solutions tend to be political rather than
technical. What we are really talking about is justifying a global routing
slot.

If on the other hand we defined the routing system to also allow regionally
valid PI space with strict aggregation between regions, we would alleviate
the majority of the issue about switching providers by allowing everyone to
have PI space while containing the swamp explicit routing entries to
whatever scale seemed technically appropriate. This could be done through
geo-political approaches like country-code/city-code, or devoid of political
context using strict geographic allocations. ISP's don't like either of
these because it changes the relationships and perception of roles, but the
overall result fits well with existing practice in non-IP networks. 

At the end of the day the point is to manage the combined routing &
allocation system to keep the network functional while allowing the network
consumers to get their job done. The RIR model is biased toward keeping the
ISP membership happy (because that group tends to speak with a more unified
voice), and therefore naturally leans toward minimizing the cost in the
routing part of the problem. The business community tends to think in terms
of monetary impact which ends up stirring the political pot because the
historically disadvantaged see their opportunity at a level playing field
being bartered away without their participation. In these discussions we
walk a fine line between maintaining the status-quo as technically driven
decisions and inciting a take-over by those who would make politically
driven decisions. Unfortunately there is no trivial technical metric that
draws a clean line in the sand about who gets to have a routing slot and who
doesn't. Once you acknowledge there is no technical metric the question
becomes who's political approach wins.

Tony 


> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Leo
> Bicknell
> Sent: Monday, April 25, 2005 9:45 AM
> To: ppml at arin.net
> Subject: Re: [ppml] 2005-1:Business Need for PI Assignments
> 
> In a message written on Mon, Apr 25, 2005 at 04:31:42PM +0100,
> Michael.Dillon at radianz.com wrote:
> > The question of waste has to do with the environment you are in, the
> sources
> > of supply, and the difficulty of obtaining a resource. IPv6 addresses
> may
> 
> Your analogy here holds more water than you might think.
> 
> Water, like IPv6 addresses, is abundant.
> 
> Drinkable water, like usable IPv6 addresses, is not.
> 
> Using a /64 for a "LAN" is like dumping raw sewage into the water
> and then wondering why it's contaminated.  2^32 times more than the
> entire existing address space, for a single LAN.  When you dump in
> pollution, you prevent those downstream from using the water to
> drink.  Similarly, when you number a lan with a /64 you prevent
> other network users from using any of those addresses, even though
> you may only have 50,000 or 1,000,000 devices on your local LAN.
> 
> Similarly, at the subnet level we have the same thing.  A /48 is
> 2^16 bits of subnet, or 65536 subnets.  Now, I'll be the first to
> admit I'd like to not have to use 1918 space for the 650 subnets I
> have at home behind my 3Mbps cable modem, but giving me 100 times
> that again prevents someone else from using the space who might
> actually need it.
> 
> The problem with all of this is we're extremely bad predictors of
> the future.  Back in the day, a /8 (16/8, to be specific) to DEC
> seemed like they right thing to do, their big, they will grow.
> Similarly, giving MCI a /24 (198.4.182.0/24 to be specific) in 1993
> seemed like a smart idea, they were just a small dial up e-mail
> provider, after all.
> 
> So, while the IPv6 authors are busing thinking about my 65000 subnets
> at home, and my 18 quintillion hosts per subnet they are forgetting
> that the most interesting things that happen in the future are the
> things we can't predict now.  Much as people laughed at the concept
> that you would need a microprocessor in every doorknob in the 1960's,
> we now regularly use them on a day to day basis in hotels and
> businesses around the world.
> 
> We have people who are talking about allocating IPv6 addresses to
> serve a 60 year need.  Well, that's all well and good, but it's
> only 40 years after the doorknob quote and the reality is quite
> different.  Ideas that seem far fetched today like colonizing mars,
> or faster than light travel, or nanomachines that have IP stacks
> may be so common place in 60 years time that no one gives them a
> second thought.
> 
> What's most absurd about things like a /48 for cable modem users
> is that it only promotes waste.  Having fixed addresses is great
> /but only if you can take them with you/.  Well, if you can take
> them with you that's an entry in the global table, which is not
> what any of us want.  So presumably, you won't take them with you,
> which means every time you move you'll be getting new IP's.  How
> many people live in the same place for 60 years?  Can't we use these
> external events to adjust the size of the blocks given out over
> time?
> 
> While I may look like a stodgy conservative when it comes to address
> space management, I'l really not.  I'm pretty much a give it away
> sort of guy....just on a sane scale.  Let's give every home a /104
> (that is, the same amount of address space that's in a /8 today).
> Further, let's go ahead and let them have 256 subnets, so it's a
> /96 per house.  If I'm right that this is wanton waste, we just
> recovered a 48 BITS of address space.  If I'm wrong, in 10 years
> we can start giving out /80's to home users, 65,000 times the address
> space, and still have recovered a full 32 bits of the address space.
> That way when my grandchildren colonize alpha centauri and have
> to number the six trillion whoiewhats that live there already they
> will have plenty of space.
> 
> In other words, let's take a bath in the water, and enjoy that it
> is plentiful, but let's not dump raw sewage into the lake "because
> it doesn't matter".  History has a way of always making it matter.
> 
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org