IPv6 exceeds 1% of google search traffic (continuously)

In the ongoing march towards an IPv6 only Internet, IPv6 is not a speedy traveller but it did reach a mini-milestone this week.  Google reported that IPv6 traffic was greater than 1% of it's total traffic all week, on a regular ordinary week (well the week has the same basic shape as most non-holiday weeks).  Usage continues to edge higher and higher:

http://www.google.com/ipv6/statistics.html

Do I hear 2%?  (Probably not for a little while.)  Yes I know it is sad to be interested in this graph but hey, one has to be into something.

IPv6 hits 1% of google search traffic

There has been much talk as to how IPv6 would only be credible when it reached 1% of overall traffic. Today we hit that milestone, at least for Google search traffic:

http://www.google.com/ipv6/statistics.html

Ok, it is not an overall number by any means but the upward trend is undeniable.  Awsome.

ARIN enters IPv4 exhaustion phase two

This week we saw another step towards IPv4 address exhaustion.  The American Registry for Internet Numbers (ARIN) reached 3.00 /8s of space remaining, this triggers phase two of its exhaustion planning.  This sees requests move to a first in first out model and overall criteria for allocations tightening.  Not exhaustion, but considering just how quickly addresses dissappeared this week (from 3.02 /8s to 2.89 /8s over night) we will be there soon enough.  For more details on what this really means:

https://www.arin.net/resources/request/countdown_phase2.html

RIPE IPv4 pool exhausted

September 14th 2012 was another big day for IPv6.  Today the RIPE Regional Address Registry (RAR) exhausted its IPv4 pool:

http://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8

This triggers section 5.6 of its IPv4 Address Allocation and Assignment Policies.  While these procedures do allow RIPE members to allocate IPv4 addresses still but only in very tiny allocations and only if they already have an IPv6 allocation.  In particular they are limited to a single allocation:

1a. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.

With two of the five RARs now essentially out of IPv4 addresses this has to help spur on the adoption of IPv6.  One can hope.

IPv6 and dovecot

For my mail server I use dovecot.  By default this only binds its sockets in IPv4.  It is however trivial to enable binding of IPv6 as well.  Simply change the "listen = *" entry in its configuration (/etc/dovecot/dovecot.conf) as below:

listen="*, [::]" 

With that done and the service restarted my email if now available over IPv6 too.  This should become the default most likely.

IPv6 and weechat

With my bip proxy IPv6 enabled it is time to look at my IRC client.  I am a 'weechat' user so that is my target.  It seems that weechat has some support for IPv6 via its 'ipv6' option on the server configuration block.  You can set this option for connection 'freenode' as below:

/set irc.server.freenode.ipv6 yes

This certainly switches the connection over to IPv6, but it does not seem to fallback to IPv4 automatically.  Some additional support will be required to handle this, though the changes look minor.  I guess we can call this half enabled.

IPv6 dual-stack listeners?

As alluded to in my previous post "IPv6 and bip" when a service creates its network endpoint as an IPv6 socket it is actually able to  communicate with both IPv6 clients and IPv4 clients interchangeably.  But how does this work?

This compatibility mode is defined in one of the foundation Request For Comments (RFC) documents, specifically RFC3493 which defines how the socket() interfaces should behave with respect to IPv6 (see section 3.7 for the gory details).  This defines a reserved area of IPv6 address space which maps 1:1 to IPv4 addesses.  Essentially the IPv4 address may be translated into a unique reserved IPv6 address by concatenating the 0:0:0:0:0:FFFF prefix with the existing IPv4 address.  As this address is unique the underlying socket implementation can directly infer the correct physical protocol to use for this connection from the address alone, allowing connections to safely coexist.

The great thing about this compatibility mode is it works for any socket, server or client.  This allows an application to support only IPv6 and yet remain compatible with addresses of either type.  We no longer have to care which they are, nor does a service have to bind sockets to each protocol and handle the complexity that entails.  Magic.

IPv6 and bip

As a keen IPv6 advocate I have been playing around with the various applications and services I use on a regular basis and have been trying to enable IPv6 use; today it was my IRC proxy 'bip'.  bip turns out to be very simple to convert indeed.  Simply requesting bip bind on the IPv6 unspecified address (::) triggers it to switch to IPv6 and (through the magic of the Linux dual-stack IPv4 handling) this enables either IPv4 or IPv6 clients to connect to the proxy.

To change the default bind address in bip simply change the ip configuration in your .bip/.bip.conf to use the IPv6 unspecified address as below:

ip = "::";

As simple as that.  Probably the default behaviour of bip should be to bind :: (IPv6) and on failure bind 0.0.0.0 (IPv4).

World IPv6 Launch Day -- 6th June 2012

The 6th of June 2012 is an interesting day, World IPv6 Launch Day.  On this day a swathe of influential web-sites will be enabling IPv6 addresses for their services by default and not turning them off.  Why is this interesting?  For the most part it is not! For most people nothing should happen, things should continue working probably using IPv4, fine.  For those of us with working IPv6 again nothing will change other than we will be producing more IPv6 traffic, great.  It is those who have unused broken IPv6 who will start having fun, they will likely lose connectivity to the participating sites until they sort out their issues.

So why is this a good thing?  This is a key step towards IPv6 adoption, and we really do not have any other choice but to adopt IPv6.  Adoption will only be driven by need, and this move creates exactly that need.  Such ISP and client issues need to be identified and solved, before the end users lose connectivity to even greater swathes of The Internet, those parts which only will exist on The IPv6 Internet.

For more information see: http://www.worldipv6launch.org/

IPv6 at home?

The Internet has been alive with doom saying since the IPv4 global address pool was parcelled out.  Now I do not subscribe to the view that the Internet is going to end imminently, but I do feel that if the technical people out there do not start playing with IPv6 soon then what hope is there for the masses?

In the UK getting native IPv6 is not a trivial task, only one ISP I can find seems to offer it and of course it is not the one I am with.  So what options do I have?  Well there are a number of different types of IPv4 tunnelling techniques such as 6to4 but these seem to require the ability to handle the transition on your NAT router, not an option here.  The other is a proper 6in4 tunnel to a tunnel broker but this needs an end-point.

As I have a local server that makes a sensible anchor for such a tunnel.  Talking round with those in the know I settled on getting a tunnel from Hurricane Electric (HE), a company which gives out tunnels to individuals for free and seems to have local presence for their tunnel hosts.  HE even supply you with tools to cope with your endpoint having a dynamic address, handy.  So with an HE tunnel configuration in hand I set about making my backup server into my IPv6 gateway.

First I had to ensure that protocol 41 (the tunnelling protocol) was being forwarded to the appropriate host.  This is a little tricky as this required me to talk to the configurator for my wireless router.  With that passed on to my server I was able to start configuring the tunnel.

Following the instructions on my HE tunnel broker page, a simple cut-n-paste into /etc/network/interfaces added the new tunnel network device, a quick ifup and my server started using IPv6.  Interestingly my apt-cacher-ng immediately switched backhaul of its incoming IPv4 requests to IPv6 no configuration needed.

Enabling IPv6 for the rest of the network was surprisingly easy.  I had to install and configure radv with my assigned prefix.  It also passed out information on the HE DNS servers, prioritising IPv6 in DNS lookup results.  No changes were required for any of the client systems; well other than enabling firewalls.  Win.

Overall IPv6 is still not simple as it is hard to obtain native IPv6 support, but if you can get it onto your network the client side is working very well indeed.