[governance] FW: [] Fwd: IPv4 Address Exhaustion Milestone & Comcast Starts DOCSIS IPv6 Trial

[Karl Auerbach]

On 02/05/2011 02:22 PM, Thomas Lowenhaupt wrote:

> Could you please point me to the "sad phenomenon" / "sad story" you
> refer to below. I have not seen anything that presents the existence of
> controversy about IPv6. If there's nothing currently out there, some
> type of de-teching would seem to be in order, perhaps by some on this list.

A lot of the things you might be thinking of existing in the pre-history 
before things got digitized and findable via google.

IPv6 got started around 1990 (in fact much of it came from a few steps 
from my office at Sun.)

There were multiple concerns back then.  Only one of those concerns of 
those was about IPv4 address space exhaustion.  Another concern was 
about the difficulty of processing and propagating routing information.

The OSI network layer used a 20 byte address versus the 4 byte IPv4 
address - so it seemed reasonable to go to the 16 byte IPv6 address. 
(In the original IPv6 one half of that address space was reserved for 
Novell Netware!)

Other things were thrown into IPv6 - like a restructuring of the options 
and moving fields around so that routers could begin processing a packet 
before it fully arrived.  All of that was OK but largely was gilding the 
lily of 64-bit addresses.

And a flow identifier field was also thrown in to pacify those of us who 
saw some value in labeled flows and also in the possibility of using a 
form of source-based routing (a proposal called "nimrod") and of doing 
flow-based reservations of network resources (another proposal called 
"RSVP".)

But the issue of routing was never squarely faced.  Which means that 
IPv6 is no better than IPv4 when it comes to propagating and processing 
routing information faster than the occurrence of routing topology 
changes.  (In fact, arguably IPv6 might be a bit worse because the size 
of the addresses means that often more bits need to be slogged around 
and processed.)

To my mind routing remains the big Godzilla - a monster that IPv6 does 
not stop.

(There were other annoying things - like the fact that UDP and TCP 
pull-up parts of the IP header into a TCP and UDP pseudo header.)

There were lots of dances around the question of interoperation of IPv4 
and IPv6 stacks - many of us had lived through the flag day when the net 
went from NCP to TCP.   We knew that that could never be done again 
because of the size and the fact that the net no longer had a network 
techie at every node.

We have never really found an IPv4-talks-to-IPv6 dance that works 
completely transparently.

I tend to think of IPv6 as being a separate internet that happens to 
share physical wiring.

So, one can make an argument that the cost of moving to IPv6, because it 
is a different network, is roughly proximate the cost of bridging 
between separate IPv4 networks.

The potential benefit of a large single address space and full 
end-to-end connectivity will tend to be overlooked by the vast majority 
of network users who perceive the internet as a land of applications 
rather than of IP-to-IP packet connectivity.  When viewed as a platform 
for applications, invisible application level gateways between separate 
IPv4 networks will be no more complained-about than the invisible SMS 
gateways between mobile providers are complained of by Twitter users.

And explicit bridges between IPv4 networks are, unfortunately, becoming 
increasingly desirable by governments that want to build walls around 
their countries (or watch or filter traffic.)

		--karl--
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.cpsr.org/lists/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t