Present Location: News >> Blog >> IPv6 Musings


> IPv6 Musings
Posted by prox, from Charlotte, on October 20, 2013 at 20:41 local (server) time

Warning: Soapbox.

It's almost the end of 2013.  World IPv6 Launch was over 15 months ago.  However, it appears we still have some organizations and protocols that just aren't getting with the program.  Even more shocking, we still have some that are taking measures to indirectly inhibit IPv6 development.

I've made a short list.

Get With The Program!

MPLS.  draft-george-mpls-ipv6-only-gap goes over many of the problems that need to be overcome to operate an MPLS network that is free of IPv4.  The short story is that it may be awhile before this is possible.  I can see many new ISPs deplying RFC 6598 (possibly erroneously) or RFC 1918 space on their backbones just to meet the IPv4 requirements for MPLS, in the short term, unfortunately.

Twitter.  Twitter owns 2620:fe::/40 but has not announced it into BGP, yet.  The least they could do is provide something like on a proxy server to show their interest in keeping up with technology.

Debian GNU/Linux bug #592539 for isc-dhcp-server.  The isc-dhcp-server package has both IPv4 and IPv6 functionality but the init scripts to start the IPv6 version of the daemon don't exist.  Yes, this means that you can't use DHCPv6 on Debian without writing your own init script or starting it manually.  The bug was opened in August of 2010 and has yet to be resolved.  Get with the program, folks!

Amazon EC2.  This is a sore subject.  The only AWS service that supports IPv6 is ELB, unfortunately.  EC2 doesn't support it in any region or availability zone, at the moment.  This is preventing lots of organizations from correctly deplying IPv6.

Google Compute Engine.  GCE is a very poor competitor to Amazon EC2 for a variety of reasons.  Google could have actually made one feature more attractive than EC2 by offering IPv6 on it.  Unfortunately, they didn't.  Fail.

Skype.  We all know about this one, so let's just move on.

Why do you hate IPv6?

FreeBSD.  A change in the defaults for the IPv6 address selection algorithm in FreeBSD 9.x leaves users with an OS that always prefers IPv4 connectivity when both A and AAAA RRs exist for a particular label.  There are two knobs that can be put in /etc/rc.conf that change this behavior (ipv6_activate_all_interfaces and ip6addrctl_policy).  That being said, versions of FreeBSD prior to 9.x defaulted to always preferring IPv6 over IPv4 when both RRs exist.  It's very backward-thinking of the FreeBSD folks to introduce such a drastic change in the operating system's defaults after supporting IPv6 for so long.  Apparently, FreeBSD 4.0 introduced support for IPv6 back in 2000.

Carrier Grade NAT.  Unlike traditional NAT, CGN is often deployed on residential networks as a second layer of NAT (the customers' home routers being the first layer).  This second layer of NAT breaks end-to-end connectivity even worse than a single layer of NAT, rendering a variety of peer-to-peer applications useless.  Even though the problems with CGN are numerous, it helps ISPs push back the deployment of IPv6 for a little while longer, unfortunately.

> Add Comment

New comments are currently disabled for this entry.