Subject: potpourri

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Aug 2005 14:28:52 +0200

Following up on the meeting session:

As the IPv6 working group draws to a close the *only* proper action is to
recommend to the IESG that all stable and eligible documents be progressed
along the standards track. The IESG will do whatever it would anyway, so it
does no good to try to fineness things by endless debates about last minute
tweaks and the resulting potential to recycle in place. If there are minor
clarifications to make, those should be done as independent documents in the
context of addenda to the stable documents. IPv6 as the components which
functionally replace RFC 791, 826, etc. is complete. Solving problems that
are still unsolved in IPv4 remains as work for continuing or future working
groups. That does not diminish the stability of the base documents, so they
need to progress now.

On the discussion about prefixes, we need to stop revisiting decisions. The
IETF does need to make a statement because leaving this to the RIRs is
equivalent to leaving the fox in charge of access to the chickens. The point
I was trying to make at the mic is that there are vocal participants in the
RIR community that are stuck in the conservation mindset and can't seem to
do basic math. They will agree with Thomas, Geoff, & Lea's work that without
doing anything IPv6 will be sufficient for a number of decades, but they
seem to loose context when the simple change of the HD from .8 to .94 buys
an order of magnitude which results in IPv6 being sufficient for a number of
*centuries*. That timeframe is substantially long enough that it becomes
difficult to grasp so without a good grasp of the lifetime their
conservation mindset steps in claiming the need to curtail wasted bits at
every turn. The whole /56 discussion is looking to take us from centuries to
tens (or hundreds if combined with the HD change) of millennia. What they
fail to recognize is that this is a zero sum game where we currently have a
balance, and moving the efficiency toward allocation removes it from
operational deployment models that are different from the past. It is
extremely easy to overlook the fact that some deployment models don't
currently exist because they can't under the constraints of current
allocation policy. This leads to a false belief that they will not appear
over the next several centuries because we have yet to see them, when the
reality is that it is the limited perspective policies which insure they
will not ever appear. The IETF has to take the position of broad vision here
and flatly state that undue conservation is detrimental.

The RIR members are basically a greedy bunch. For those who have forgotten
history, the initial 64 bit proposal exceeded the IPv6 design requirements
by 3 orders of magnitude. At the start of the dot com boom it appeared there
would not be enough room for comfortable waste by the service providers in
terms of hierarchy so the entire 64 bits was dedicated to routing. Removing
the allocation needs of 10^15 hosts meant 'more than enough' was now 'more
than more than enough', particularly in light of the bust and consolidation.
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. 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... Fundamentally the RIR members just don't like being told what to
do. If left alone they will constrain network deployments to what has been
done in the past. 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.

Finally it takes extreme hubris to believe that IPv6 is 'THE' protocol for
centuries or millennia to come. Technology moves on, and IPv6 will be
replaced long before the pool is exhausted. 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 so that example should be measured in
decades rather than centuries. 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. The /64 decision provides more than 'more than enough' routing
space, and the /48 decision allows flexibility at the site level without
significant impact on the service provider's ability to waste bits
themselves. Changing those values only makes it harder to innovate in the
space of automated configuration of site networks and hosts, and really
doesn't buy any useful time because we are talking about adding time to the
point well beyond the useful lifetime of the protocol. As I said in
draft-hain-prefix-consider-00.txt there may be business reasons to consider
other lengths, but there are no technical reasons. We need to state that
clearly before the IPv6 WG closes.

Tony

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: David Conrad <[email-masked]>
Date: Thu, 4 Aug 2005 00:42:41 -0700

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

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?

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

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

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

Rgds,
-drc

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Aug 2005 19:33:32 +0200

> fanatics and their obviously broken variable length addresses, didn't

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. 

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

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

> 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

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. 

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

> 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

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

> or Telia, how much address space should (say) the People's Liberation

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.

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

> 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