[ppml] Revising Centrally Assigned ULA draft

[Mark Smith]

On Fri, 15 Jun 2007 15:13:40 -0500
"Kevin Kargel" <kkargel at polartel.com> wrote:

> I agree wholeheartedly.  There is nothing you can do with ULA-C that you
> can't do with PI and a minor firewall rule or two.  Leaving the space as
> PI gives it either-or capability, putting it as ULA reduces PI.  (And
> don't talk about 'more PI than we could ever use'..  remember when Mr.
> Gates told us you would never need more than 640K of RAM?)(of course he
> denies it now..)
> 
>  

I understand that that was an IBM design decision - they chose to allow
384KB out of the 1MB of address space of the 8086/8088 for option ROMs
for add-in cards. That decision was made during the design of the
original IBM PC (i.e. the one before the XT), which originally came
with 16KB of RAM (and a audio cassette interface for storage, no serial
ports or printer ports, and a monochrome 4KB text adaptor). Allowing
384KB for option ROMs allowed for plenty of IO card expansion, because
the platform was initially very barebones, and 640KB was extremely
large amount of RAM at the time. The OS at the time didn't
provide device drivers, unlike today's OSes - the option ROMs was were
that functionality resided. When you look at that problem, at the time
it was addressed, the 640KB/384KB boundary seems, at least to me, to be
quite reasonable.

The IBM PC architecture was never expected to (a) set an industry
standard and (b) ever last as long as it has. Gates was unlikely to
have ever been consulted on it, or conversely, was only ever agreeing
with a decision that had already been made.

Don't use this (mis)quote as a lack of design foresight, use it as an
example of wildly unexpected success. IPv6 doesn't have the addressing
quantity constraints that IPv4 has, so allow for wildly different and
expanded uses of it and it's large address space. 

As a general example of how IPv6's "large" addressing
could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on
a LAN segment. We "waste" millions of addresses everytime we enable a
new LAN segment. The Ethernet address space we "waste" when a point to
point ethernet link is brought up is the most "obscene" amount of
address space "waste" I've ever seen in my life - because a
point-to-point link doesn't even need addressing - the frame is either
for this end or the other end.

So what has all that "wasted" Ethernet address space got us ? _Convenience_

It is convenient that we can plug an Ethernet card in and not have to
worry about configuring addresses or addressing collisions.
Non-technical people can buy a network card at the local
electrical store, plug it into their computer, and the ethernet
functionality work (installing device drivers is obviously not a
problem that ethernet attemps to solve). It's the original
"plug-and-play".

With Ethernet, we get a lot of convenience at the cheap price of 32 or
so bits of "wasted" address space (on the rough assumption that nobody
would ever build an ethernet segment with more than 65K nodes), or 64
bits in each packet.

Here's what the people who chose 48 bit addressing for Ethernet said
about the decision :

"48-bit host numbers lead to large Ethernet and internet packets. We
believe that this will not pose a problem as both local and public data
networks continue to offer higher bandwidths at reasonable costs, and
the memory and logic costs associated with storing and processing these
numbers continue to become lower with the advances in LSI technology."
("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal
and Robert S. Printis - definately worth a read)

When did they say it ? 1981! 26 years ago!

The problem with applying an IPv4 mentality to an IPv6 addressing
problem is that IPv4 hasn't been an abundant resource for 15 or so
years. We've had to give up operational convenience with it because we
needed to ensure functionality as the Internet grew. When it came to
the crunch, convenience had to be sacrificed.

IPv6 address space is abundant, so we can now go back to placing value on
operational convenience. All we need to do is ensure there isn't any
reckless use of IPv6's address space.

So, getting back to the ULA topic :

If (non-globally routed) PI is the answer to the ULA-C question, is
there going to be enough (non-globally routed) PI so that I can get a
(non-globally routed) PI allocation for my home, at a small charge for
the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal
Area Network that interconnects my mobile phone, portable music player
and pedometer in my shoes. Will there be enough (non-globally routed)
PI that everybody on the planet who might end up having that sort of
PAN can get a (non-globally routed) PI address allocation, should they
want one ? How about if they want separate allocations for both their
PAN and their home network.

If the answer is no, then (non-globally routed) PI it isn't solving the
ULA/ULA-C problem.

> 
> > -----Original Message-----
> > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> > Behalf Of Owen DeLong
> > Sent: Friday, June 15, 2007 2:41 PM
> > To: jordi.palet at consulintel.es
> > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; 
> > address-policy-wg at ripe.net
> > Subject: Re: [ppml] Revising Centrally Assigned ULA draft
> > 
> > 
> > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:
> > 
> > > If you doubt about folks stating anything, then you should read
> > > *before*
> > > minutes of meetings. I'm now off-line in a plane, so can't 
> > point you 
> > > to a specific URL, but this has been said at least in one ARIN 
> > > meeting.
> > >
> > > It has been clear across all this discussion in several exploders, 
> > > that there are both opinions, people that want ULA-C and 
> > people that 
> > > don't. What you need to be smart here is to realize that those than 
> > > don't want ULA-C have no any objective reason to oppose to 
> > it, because 
> > > implementing ULA-C has no negative impact in others. While 
> > opposing to 
> > > it has negative impact to
> > > all: Folks will use global space (PA or PI) for doing the 
> > function of 
> > > ULA-C an this is a waste, yes a small waste but a waste.
> > >
> > Jordi,
> > 	You have this backwards.  Using PI for the purposes of 
> > ULA-C is no waste at all.  Sectioning off a huge chunk of 
> > address space for ULA-C is the waste.
> > If it's all PI, then, it can seamlessly move between being 
> > unrouted or routed as the address-holder sees fit and as 
> > needs change.  If it is set aside as ULA, then, the address 
> > space is forever wasted and cannot (theoretically) be used as 
> > routable space, no matter how little of it is needed for ULA-C.
> > 
> > 	Those of us who oppose ULA-C have what we believe to be 
> > an objective position that it provides no additional benefit 
> > over PI space while simultaneously creating some unnecessary 
> > classification of addresses that makes their status in the 
> > routing table ill-defined at best.  In our opinion, this 
> > carries the potential for significant consequences globally.
> > 
> > 	Just because we do not agree with you does not mean 
> > that our concerns are not legitimate.
> > 
> > 	Do I think UUNET and others should be able to get 
> > secondary microallocations to solve the problem they 
> > presented? Absolutely.  Do I think that we need to set aside 
> > a /8, /12, /16, or whatever separate from the rest of PI 
> > space to do it? No.
> > We should just issue them a /48 or whatever it is they need 
> > from the general pool of available PI space and be done with 
> > it.  No waste at all.  No negative consequences to anyone.  
> > No ambiguous status as to where you can or can't route the 
> > addresses, etc.
> > 
> > Owen
> > 
> > _______________________________________________
> > This message sent to you through the ARIN Public Policy 
> > Mailing List (PPML at arin.net).
> > Manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml
> > 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml