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).