[ppml] potpourri

David Conrad david.conrad at nominum.com
Thu Aug 4 03:42:41 EDT 2005


I know I'm going to regret this since your post was so obviously  
flamebait preaching to the choir, but as the saying goes, you bring  
the flamethrower and I'll bring the marshmallows.

On Aug 3, 2005, at 5:28 AM, Tony Hain wrote:
> The IETF has to take the position of broad vision here
> and flatly state that undue conservation is detrimental.

Of course it is.  And water is wet.

The obvious point of contention is the definition of "undue".  Your  
definition differs from others due to the fact that there are  
different interpretations of possible future utilization trends.  The  
IETF's choice of a (relatively) small fixed number of bits guaranteed  
that this would be a problem, but hey, we sure showed those silly OSI  
fanatics and their obviously broken variable length addresses, didn't  

> The RIR members are basically a greedy bunch.

No, no.  The correct, IETF sanctioned term is "Evil Greedy Bastard".   
Just checked the T-shirt I got back in '94 at the ALE meeting and  
that's definitely what it says.  Of course, I'm just one of the foxes  
in the henhouse now so I guess I need a different T-shirt.

> Even so there are continuing complaints about the /64 boundary and  
> demands
> to relax that constraint because in historical deployment terms  
> that number
> of bits per subnet is a waste.

Well, yes.  There are those who feel 18,446,744,073,709,551,616  
addresses is a bit much for any flat routed individual LAN, but those  
arguments are so passe these days.  Auto-configuration is indeed  
nice, at least in those environments that don't mind having arbitrary  
devices connect to the network and get valid IP addresses, but I  
guess I just have a wee bit of concern with arbitrary fixed  
boundaries since they worked so stunningly well in the past.  Must be  
a EGB flashback.  I'm sure I'll get over it.

> Never mind the issue that at some point in
> the lifetime of IPv6 the IEEE will be forced to move from 48 to 64 bit
> EUI's...

I suppose IPv6 will need to be revised so that the RFID addresses  
will fit.  Oh, wait...

> Fundamentally the RIR members just don't like being told what to do.

I guess this is accurate.  Perhaps, just maybe, the presumption that  
the IETF is qualified and/or appropriate to tell the RIR members what  
to do is where the dislike of being told what to do originates?

> If left alone they will constrain network deployments to what has been
> done in the past.

No.  If left alone, I would imagine they will constrain network  
deployments to what they believe will meet their business  
requirements.  At least the commercial ones.  If a particular RIR  
member believes what has been done in the past meets those  
requirements, that is probably what they will do.  If they believe  
deploying IPv6 will meet their requirements, guess what will happen?

> It is up to the IPv6 WG to set the bar to avoid the state
> where people are forced to work around the restrictive policies of a
> provider and/or LIR/RIR.

I would have thought it was the IPv6 WG's responsibility to  
standardize protocols that would address the issues that resulted in  
the restrictive policies.  The issue of address space limitations was  
sort-of addressed (in a sub-optimal way given this discussion).  But  
how about issues like transparent renumbering, multi-homing,  
separation of the end point identifier from the routing locator, and/ 
or other issues around routing system scalability?

For example, people are going to be forced to work around the  
restrictive policy that you have to renumber when you change  
providers.  I personally suspect they'll do that via NATv6.  If  
you're true to form, I'm sure you'll argue they'll do that by some  
variant of geographical addressing.  Since the EGBs you have such  
disdain for would have to play nicely together to go with your scheme  
and they don't have to do anything to support NATv6, I have a  
sneaking suspicion which approach will be deployed for the folks  
whose definition of the Internet is the World Wide Web and whose  
interpretation of "end-to-end" is something you find on those  
unmentionable web sites that, of course, they'd never go to (wink,  
wink, nudge, nudge).

Looking at the existing RIR databases, the "restrictive  
policies" (most of which were taken verbatim from the IETF holy  
texts) you deride have already resulted in /19s being allocated to  
single organizations (which, coincidentally, used to be the same  
prefix length RIPE-NCC used to allocate to LIRs when they initially  
requested space.  IPv4 /19s, of course).  And this is without  
governments requesting the space they feel they'll need for their  
national interests.  Governments like, oh say, China, India,  
Indonesia, etc.  If a /20 can be justified and allocated to Telstra  
or Telia, how much address space should (say) the People's Liberation  
Army of China get?

> Those who point to the phone
> system as an example conveniently overlook the rolling evolution that
> effectively reduces the window of applicability. While there may be  
> pockets
> where things still work, in my experience equipment from 40 years  
> ago is not
> compatible with the current network

My dad has a Stromberg-Carlson model 1212-A made in the 1930s.  I  
just spoke with him over it.  Seems to be compatible.  Not full  
featured by today's standards, but it does appear to do the function  
it was built for.  But perhaps you mean something else.

> Even the numbering has undergone periodic
> change, so claiming we know enough to recognize allocation waste  
> centuries
> before the person with a bright new idea is born is the highest  
> form of
> arrogance.

Alternatively, claiming we know enough to assume profligate waste  
will not cause the exact same arguments sometime within the  
foreseeable future could simply reiterate Hegel's quote "Those who  
cannot learn from history are doomed to repeat it".

I would however agree with you on one thing: there is a lot of  
arrogance here.


More information about the ARIN-PPML mailing list