[arin-ppml] IPv6 Heretic thoughts

Hawkes, Dave DHAWKES at abrazohealth.com
Mon Sep 8 13:59:38 EDT 2008

I agree.  There is nothing forcing a IPv6 migration.

The inherent problem with IPv6 is that no one is forced to initiate the migration today.  It has already been made clear that many of the larger companies that can drive the technology have large legacy IPv4 blocks that are no where near depletion.  Some of them have small experimental IPv6 subnets, but no plans to migrate their existing legacy IPv4 networks.  Companies with smaller IPv4 blocks that need to migrate to IPv6 sooner may not have the clout to force a migration outside of their own network.  Also, there is no benefit from the Internet end-user's perspective to drive IPv6, and end-user's in general don't know what IPv6 is.  Of course, all of us are Internet end-users (individually and as companies), however few of us are driving IPv6 outside of this forum.

The technology to implement IPv6 on existing networks is there (however many companies may not have that equipment, or more likely not be able to support the increase in processing on their aggregated networks, etc).  Some solutions for supporting IPv4 and IPv6 may not be viable, but the solutions are there.  IPv6 has support for IPv4 built in, the hangup is in the translation between the two in cases where dual-stack isn't feasible.  (These cases may just need to be re-engineered for a dual-stacked network).

I agree that there needs to be a deadline, instead of the impending doom of IPv4 depletion.  Perhaps the deadline should be focused on one aspect of the Internet, rather than all IPv4 usage.  After all, we aren't talking about HDTV, MSDOS, or other similar migrations.  We are talking about IPv4/IPv6.  IPv4 to IPv4 communication needs to continue to survive transparently on an IPv6 network, and the IPv4 networks will continue to increase in size.  A deadline can be proposed that forces the exchange points between networks to migrate to IPv6 first.  Internal networks and networking equipment can initiate the migration, leaving the end-points (web servers, workstations, etc) on IPv4 networks.

By initiating a migration between networks, and on traffic internal to a network (traffic aggregation between access routers and the core of networks), then many IPv4 subnets will be freed and can be used on the nodes left in (non-RFC1918) IPv4 space.  More importantly, the framework for IPv6 on the Internet between peers, and within networks will be in place.  The nodes left in IPv4 space will then eventually follow the migration.  It seems that if a blanket deadline is put in place, no one will accept it and nothing will get done.  But perhaps there can be more support for a deadline that phased certain traffic to IPv6.

I'm not sure how a deadline can be limited to such traffic.  Since once a company is issued IPv4 addresses, they are free to use them as they wish.  However, once a few larger legacy networks begin such a migration on their internal networks and exchange points, it would gain momentum.  Company A that peers to companies B - Z would be able to force the router to router communication at that exchange to IPv6 easier than a smaller company that peers with only a few networks.  Once you are forced to use IPv6 for router to router communication on one part of your network, a lot of the investment is done and migrating all of your router to router/internal traffic to IPv6 is that much easier.

*** I may be totally out of left field on all of this, and possibly just came out of hibernation.  So, if none of this makes sense, or if I am behind on the discussions, let me know.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cliff Bedore
Sent: Thursday, September 04, 2008 10:41 AM
Subject: [arin-ppml] IPv6 Heretic thoughts

Having been reading this group for approaching a year or so now, I think I've seen the problem with adopting IPv6.  Nobody really wants it.
There is no CEO in the world sitting around saying "Boy I can't wait to get us on IPv6" and there is no Joe Sixpack sitting at home who gives a rats a** about IPv6 vs IPv4.  They want to get to Google or ESPN or their favorite porn site or their favorite gaming site or gambling site.

The problem:  There is no compatibility bit in IPv6 that says I'm just like IPv4 but I have 96 more address bits.  Lacking this, I think the only way to get IPv6 going is to develop a transparent IPv6 to IPv4 translator and convert the entire "Internet backbone" to IPv6.  If I'm reading stuff correctly, something like NAT64 is a good starting point but there is more required.  The backbone for the Internet will have to be IPv6, DNS will have to be IPv6 and IPv4 will be treated as IPv6 on the Internet and translated through the "converter box (CB)".  This means that the CB will have to do both translation and DNS lookups for the v4 hosts.  Since there are 64 bits per subnet in IPv6, there will never be a subnet that can't split off IPv4 addresses through the CB for translation.

That's a short summary of a big problem but I think it's obvious that there has been little real adoption of IPv6.  We really need a program that accomplishes what the US HDTV program did.  Tell people that "on MM/DD/YY, the Internet backbone will be IPv6 only.  If you want to run IPv4, you will need one(or more) of the converter boxes for your IPv4 addresses.  If you don't do this, you will lose Internet connectivity"

Advantages to this include

1.  All IPv4 space effectively becomes PI space since you can tuck your
IPv4 into any IPv6 subnet and not have to change anything but the address of your CB(s).

2.  Routing tables should shrink since IPv4 can be removed and there should be better aggregation.

3.  You don't throw out all the old IPv4 only systems/software.  Old games work.  Old PCs work

4.  IPv4 local networks can still talk to IPv4 local networks across the world "transparently". Any IPv4 browser should be able to go through the CB and get to Google or any other web server.

5  Those who want to take advantage of the fancy parts of IPv6 can still do so.

6.  No tunneling only translation.

7.  As time goes by, more and more of the Internet will become native
IPv6 and the conversion boxes can be retired but it should always be possible to have that converter box to allow running some oddball old software.  (I still have a 386 in my basement that runs DOS with packet drivers and can telnet to any host that lets me have an account.)

I'm sure people can come up with  all kinds of reasons why this won't work but let's face it; right now IPv6 is a dud.  Sure it works but it can't talk to IPv4 simply and transparently and if the converter box discussed above is technically impossible, IPv6 doesn't deserve to be the next generation of IP addressing.  If the converter box works (and it has to work with all of IPv4) then the only way to get people to IPv6 is to do something similar to what is discussed above.  I'm not particularly pro or con re IPv6, I just see it not working in the present method of rolling it out.  The U. S. government mandate of using
IPv6 is very reminiscent of the great GOSIP debacle of the 1990s and if something doesn't change in how we do this, I frankly see IPv6 dying out and a smaller group of good engineers will come up with something that works instead of a protocol designed by an overly large committee that wants everything but the kitchen sink.

Look at the successful conversions of the past.  The latest Pentium will run MS DOS.  I can watch HDTV on my old TV, I believe it was IBM 360s which ran "an older machine"(somebody here will remember) in emulation mode.  The latest DVD drive can still play a CD.  People will adopt something because it works for them without a lot of fuss or it is a disruptive technology that offers something worth the conversion to something new (think iPod).  I don't see IPv6 as ever being a disruptive technology so it is going to have to be backward compatible in some way or it will die.


You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
Please contact info at arin.net if you experience any issues.

More information about the ARIN-PPML mailing list