Is the glass half full or half empty? The human reflex of selective deafness to information or arguments countering  one’s established believes lives on.  The ISOC organized lunchtime IPv6 panel (1) at IETF 74 in San Francisco   illustrates the point. The half full perception is exemplified by one write-up (2) on the event, the half-empty by another (3). A third write-up (4) seems to be the closest to what constitutes objectivity,  uncorrected for any confirmation bias of my own. 

Natural pessimists continue to hide behind lack of business case, ROI, lack of customer demand, cost, complexity.  Mention lack of backward compatibility and it appears under title of “fatal flow for IPv6” (5), mention a “broccoli approach to IPv6 implementation” and the bias will depend on whether or not one likes broccoli.   When forced  to swallow, they will probably go on a diet of hard to digest transition technologies and NATcho’s.

Natural optimists see a new world of applications and phenomenal opportunities stirring under the surface of the internet.  They integrate IPv6 as part of their network equipment and service upgrade cycles and consider new application domains to satisfy humanity’s insatiable hunger to  search, consume, produce and exchange information anytime, anywhere .  When Google turned on AAAA’s for Google Maps, IPv6 traffic tripled within days. Trapped underground IPv6 lakes start to break the surface of an increasingly arid and parched IPv4 internet. 

Maybe there are is a genetic base and evolutionary benefit for our confirmation bias (6)? 

Yves Poppe
April 2009

1. http://www.isoc.org/isoc/conferences/ipv6panel/
2. http://arstechnica.com/web/news/2009/03/internet-society-promotes-ipv6-ietf-extends-ipv4-lifetime.ars
3. http://www.networkworld.com/news/2009/032009-ipv6-business-case.html
4. http://www.zdnetasia.com/news/internet/0,39044908,62052667,00.htm?scid=rss_z_nw
5. http://www.cw.com.hk/content/fatal-flaw-ipv6-its-not-backwards-compatible
6. http://en.wikipedia.org/wiki/Confirmation_bias

The IPv6 killer application has finally been found, making sure Internet continues to run. The general consensus at Google’s IPv6 implementors conference was that the reason to deploy IPv6 is to ensure business continuity for your Internet services. The survival of the Internet is the killer app of IPv6 as one of the participants put it. The approach to achieve this is different from case to case. For ISPs the shortage of IPv4 addresses is the main decider in how the deployment of IPv6 will be done. Doing dual stack is not an option as it won’t save addresses, instead many operators are looking at different ways to rid themselves of IPv4 at same time as maintaining their IPv4 service to the end user. For content providers IPv6 deployment is way of keeping up with IPv6 rollout to ensure that users don’t run into problems by having to go through multiple NATs.

Now the question is when the Internet needs saving. There seems to be a common understanding that IPv6 will not be deployed in time to take care of the IPv4 shortage by its own existence. Instead it has to be used as a tool to extend the life of IPv4 services. This will become a reality within a next year or two when the ISPs will start to feel the pain of adding IPv4 customers in a traditional manner. At that point IPv6 will become an important part of the Internet even though a lot of users will continue to run IPv4 on their old Windows XP machines or PS3s.

Having IPv6 become a tool to keep the Internet running isn’t a bad thing, it is what IPv6 was created to do. The only thing that has changed is the way it is being done.

Anything to be aware of on layer 2 when activating dual stack ? IPv4 and IPv6 should after all peacefully and safely coexist on the same network as each version has a specific layer 2 ethernet type, 0×0800 for IPv4 while IPv6 responds to 0×86dd. The value of this field tells the node which layer 3 protocol follows in the ethernet frame. Is this new? Not really, this was defined in RFC 2464 (1) in December 1998, more than a decade ago. The IEEE Ethernet Field Registrar (2) issues and maintains the list (3) of allocated Ethernet types. And 0×0800, the IPv4 ethernet type, result of the venerable RFC894 (4), will be a quarter century old next month! This RFC defines a standard protocol for the ARPA – internet community (sic).

Remarkable how Ethernet has evolved and been widely adopted over this period extending its reach from LAN to MAN to WAN and from 10meg to 10gigE. One has to credit the IEEE for quite an efficient job as a standards body.

Over in the IP world, this month of March will see IETF 74 (5) meet in San Francisco and continue to ponder transitions, address translations, double translations, even carrier grade translations. In the meantime the IPv4 pool has shrivelled to 32 /8’s in IANA’s free pool and in Manila last week the policy session (6) at the APNIC meeting further looked at ways to cut the remaining IPv4 address pool in ever smaller pieces and even allocating them for shorter time frames to somehow delay the inevitable. The Regional Internet Registries now even have a mechanism to equitably share recovered, reclaimed and returned pieces of IPv4 address property. APNIC has even adopted a proposition on how to parcel out crumbs of the very last /8 they will get allocated.

A modern day Géricault might start painting the “Radeau du IPv4” . I felt reassured however by the growing number of IPv6 address allocations by RIR’s to local registries and ISP’s as we saw in the NRO update (7). Let’s just start using them a bit faster and pity the poor souls who will be left on the IPv4 raft .

Yves Poppe

March 2009

1. http://www.ietf.org/rfc/rfc2464.txt

2. http://standards.ieee.org/regauth/ethertype/type-tut.html

3. http://standards.ieee.org/regauth/ethertype/eth.txt

4. http://www.ietf.org/rfc/rfc894.txt

5. http://tools.ietf.org/agenda/74/calendar

6. http://www.apnic.net/policy/proposals/index.html

7. http://meetings.apnic.net/program/amm/pan-nro-stats.ppt