[arin-ppml] Policy Proposal 2008-6: Emergency TransferPolicyforIPv4 Addresses - Last Call

Cliff Bedore cliffb at cjbsys.bdb.com
Sun Jan 4 10:45:34 EST 2009


Bill Darte wrote:
>
> .... cja at daydream.com...wrote...
>
> I guess I am still waiting for someone to come up with the killer
> application for IPv6.  Or a marketing scheme... get this new
> service/speed/whatever if you sign up for IPv6.  Of course you have to 
> have
> IPv6 deployed to sell it as part of a service.
> *************
>
> Seems to me the sell is... the future comes with IPv6...we(as an ISP) 
> offer that service now.. if you want to be part of the future, come 
> with us....
> (then a little FUD about what happens if you don't get on board) ;-)
>
> bd
>
There is no way to develop a "killer ap" for IPv6.  There is too much 
inertia with IPv4.  I think the only way to get IPv6 going is to develop 
a transparent "magic"* gateway between IPv6 and IPv4.  This is not NAT, 
tunneling, etc.  It is a IPv6 backbone with IPv6 routers and IPv6 
addresses assigned to every IPv4 host in the world.  This is premised on 
the fact that IPv6 is so huge that every org could put a copy of the 
entire IPv4 space in one small section of each organization's IPv6 
space.  I've talked about this before but will restate it here in a 
somewhat different way.  The gateway box passes v4 requests for 
addresses through the box for outside domains and knows how to translate 
the internal v4 address to it's external v6 address along with any 
changes in protocol needed.  As more and more machines become IPv6, the 
requirements for this box will be reduced but there will probably be a 
need for it for a long time for legacy applications. 

A diagram would look something like this

v6 host --\                                    /-v4 host(with external 
unique v6 address)
           \              local               /-v4 host(with external 
unique v6 address)
v6 server--- v6 internet--router--\--v4-v6 box
           /                       \
other v6--/                         \--local v6 hosts


(I hope this comes through on all the mail readers without too much 
distortion.)

I expect there are technical problems that will have to be addressed but 
I keep reading about all the NATs, v6-v4 NAT this and  v6-v4-v6 that and 
it must be possible to get this done.  The key is that the backbone is 
NOT v4, it is v6 and v4 will only exist on local nets behind the magic 
gateway.

Advantages are:
IPV6 can start immediately
IPv4 can work as long as it needs to
Backbone routers will be v6 only
DNS can be IPv6 only until you get to the local v4 network.
We don't need a "killer" v6 app to get it going.

I don't think there has ever been a successful large conversion without 
backwards compatibility.  When I had to start dialing the area code to 
call my next door neighbor, the phones didn't stop working,  When the 
phone switches went digital, my analog phone still worked.  The (US) 
digital TV conversion didn't require that I throw out my old TV ( and if 
that were two way, I could send old analog video back and people would 
see it.)  My Windows XP system runs (almost) all my DOS programs and I 
can boot it to DOS if I need some special DOS feature.  Intel has 
maintained compatibility with 8086 code.

Frankly, there are too many IPv4 things that will break for IPv6 to ever 
become the only protocol.  I think dual stack has all the problems of 
both and none of the advantages of either.  If something along the lines 
of what I propose above doesn't happen, I don't think IPv6 will ever 
take off.  People will continue to NAT to the nth power until IPvX that 
is backward compatible will come along.  I've said it before but I'll 
repeat it here.  I think IPv6 is so similar to the OSI/GOSIP SNAFU of 
the 1980s that it will suffer a similar fate unless the backward 
compatibility problem is addressed.

Cliff


* as in Arthur C Clarke's "Any sufficiently advanced science is 
indistinguishable from magic"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090104/a3d6e4ff/attachment.htm>


More information about the ARIN-PPML mailing list