[ppml] potpourri

[Tony Hain]

David Conrad wrote:
> Tony,
> 
> 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
> we?

To recall history, I was a proponent of TUBA (TCP over NSAPs), simply due to
getting things done quickly... That is irrelevant though as we now have what
we have. Yes we differ on the definition of 'undue'. My definition says that
we should have more than enough to last us until the replacement is
deployed. Three will be all kinds of reasons for that to happen before 2100,
not the least of which is that yet to be born researchers will be
continuously looking for the 'optimal' approaches to move bits around.
History shows that the definition of 'optimal' varies based on perspective
and the specific application at hand. Yes we should make sure that if no
better ideas come along before the end of the century that we can sustain
until that happens, but we don't need to make it last longer than recorded
history. 

> 
> > 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.

I was not trying to create hostilities, just point out that complaining
about the other guy having too many when you already have more than 'more
than enough' can only be described as greed.

> 
> > 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?

The IETF can and should say what the technical issues and trade-off's are.
The policies about managing within those constraints is not the IETF's
business. 

> 
> > 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.  

'Their business requirements' is the key here. Those without voice are left
to take what they can get, and will innovate with bypass technologies (like
skype) when they can't get what they really want. 

> 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?

History shows that their requirements end up being restrictions on what
their customers can do. Until there is true competition which allows people
to shop for service that meets their needs there will be bypass technologies
developed to get around the arbitrary restrictions. We don't need bypass
technologies for artificially restricted address allocations. 

> 
> > 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?

Those are interesting topics but they were/are not design requirements for
the packet transport protocol between networks. What the IPv6 WG has done is
define the pieces to replace those associated with IPv4 as packet transport
between networks. 

> 
> 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. 

I don't care what form PI takes. My proposal is just one way that happens to
work with the existing BGP and has a managed degree of aggregation. I tried
to get a bof at this IETF to talk about the general issue of aggregating
approaches to PI but it was turned down because people are putting too much
faith in shim6. 

> 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).

See draft-ietf-v6ops-nap-01.txt

> 
> 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?

Misinterpretation of host measures as useful in allocating network prefixes
is not an IETF issue. Using the proposed measure of .94 would fix the basic
problem you raise. Not fixing that will result in the ITU helping answer
your last question.

> 
> > 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.

My rotary dial model is able to receive but not place calls. Placing calls
is a fundamental requirement in my experience. YMMV ;)

> 
> > 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".

Our difference is in the measure of 'waste'. Your claim is that there is
waste in allocating the same number of bits to the subnet as to routing. The
number of bits used by a subnet is completely irrelevant because that was
decided after the number of bits used for routing was decided to be more
than enough to meet the design goals. The discussion about /48 vs. /56 is
simply about the amount of cushion in routing bits that will be 'wasted'
after IPv6 is replaced. If we knew the date that cool new innovations would
drive a replacement for IPv6 we could optimize allocations to exactly meet
the need. The best we can do is target a lifetime, and several centuries
that are the result of /48's with an HD of .94 is likely to be more than
long enough. 

Tony

> 
> I would however agree with you on one thing: there is a lot of
> arrogance here.
> 
> Rgds,
> -drc