Good article on how improperly implemented 6in4 tunnels are holding back the v6 content providers and giving IPv6 a bad rap.
I’m seeing an annoying issue with Ubuntu 8.10 and IPv6. It appears that the Linux OS is sending packets larger than 1500 bytes out of a gigibit Ethernet interfaces which is configured for a 1500 byte MTU.
This is easy to reproduce with a dual stack machine. Just SCP/FTP a file down via IPv4 and one via IPv6. You will only see about 10% of the IPv4 throughput on the v6 transfer. A tcpdump or wireshark will confirm that packets sourced from the Linux machine are larger than 1500 bytes….sometimes 10x the size. When the network connecting these two machines only supports 1500 bytes, all these oversized packets get dropped.
I’ve opened a case with the ubuntu guys — https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254622
However, I’m seeing similar results on CENTOS 5.2 so I’m thinking it’s less distro specific.
I haven’t really heard of anyone else noticing this which makes we wonder if I’m missing something painfully simple in the configuration, or nobody is really serving any IPv6 content off a server with 2.6 kernel.
Anyone else seeing this?
Looks like we will be moving our domain registrations to another provider shortly. We are currently with Dotster for cost and ease of administration (mostly cost), but when I inquired about adding IPv6 glue for our nameserver records they were without clue. After repeated requests I finally got through to a tech who proclaimed that nobody is using IPv6 and they have no demand.
SIXXS.net confirms this. Looks like Network Solutions might be getting a little more business.
Now if only a few thousand other people moved their registrations for this reason we might pop up on the radar.
When we began planning the upgrade of our corporate infrastructure to fully support IPv6 in a dual-stack configuration, one of the earliest stumbling blocks came from an unexpected source – our Cisco ASA security appliances. By the time we’d begun our changes Cisco ASAs and PIXes had already been supporting IPv6 for a full three years (since release 7.0 in mid-2005), so I was expecting a feature-complete IPv6 product.
Initial configuration went smoothly (via the CLI, as the ASDM does not currently support IPv6 commands), but IPv6 connectivity through the ASA was spotty at best. Digging into the problem, we discovered that the Primary and Standby ASA were both transmitting router advertisements with the same priority, and that most of the hosts were sending their non-local packets to the link-local address of the Standby ASA, which was duly discarding them. A Cisco TAC request confirmed that IPv6 failover configuration will not be supported until 8.2. Timeframe for release of 8.2? Unknown.
How could IPv6 and critical enterprise functionality such as Failover be mutually exclusive, especially after three years and one full major release (IPv6 functionality was introduced in 7.0 – as of this writing the current version is 8.04)? This tells me that NO enterprises (0.000%) running Cisco ASAs have deployed IPv6 in their existing production environments. Since Cisco is the market share leader in the firewall segment, one has to wonder what percentage of North American companies have even begun planning for the approaching IPv4 exhaustion.
Just as a little experiment tonight I disabled my IPv4 stack on Vista and went entirely IPv6 native (no tunneling). Of course I got what I expected, a completly unusable system.
Windows domain and Exchange - Thanks to recent upgrade of our company to Server 2008 and Exchange 2007 everything worked internally. File sharing, DNS, authentication…all worked like a charm.
ipv6.google.com - Loaded right up and I was able to search. Also if you edit your host file and add a record for mail.google.com pointing to 2001:4860:0:2001::68 (at least for right now) you can access Gmail. I’m pretty sure that this works for MAPS and DOCS. Doesn’t work for TALK however.
www.arin.net - For all your IPv4/IPv6 needs…at least until they run out.
www.kame.net - Love to see that turtle dance.
What didn’t work:
Basically everything else.
If IPv4 is going to run out in 2-3 years, the content providers have a long way to go.
If you didn’t notice, Ubuntu 8.10 was released today. As usual the mirrors and torrents were flooded with eager downloaders.
Canonical was nice enough to setup an IPv6 only tracker (http://ipv6.torrent.ubuntu.com:6969)
Unfortunately it looks like only 27 downloads have completed in the 12+ hours it’s been released.
It’s a start, but when the first response to any networking problem on the support forum is to "DISABLE IPv6" I tend to think we have a long road left to travel.
While working through an internal deployment at the company where I work something pecurlier started to happen when we lit up an IPv6 DHCP service.
What happened was the DHCP client on Vista had trouble parsing the DNS Suffix Search List which was sent by the DHCP server. The DNS suffix of corp.company.com was sent but the OS showed
DNS Suffix Search List:
So, instead of searching on corp.company.com it tried each of them in succession — first com, then company, then corp.
I sent an email to Sean Siler who is the Microsoft IPv6 program manager (IPv6 Blog) and he has confirmed that this is a known bug which will be fixed in SP2…possibly sooner.
I have confirmed this is fixed in the latest SP2 Beta (10/29/08)
According to Geoff Huston’s IPv4 Address Report there are approximately 774 days until there are no more IPv4 addresses for the IANA (Internet Assigned Numbers Authority) to assign. This means that the last 5 remaining /8’s will have been assigned to the RIRs (such as ARIN). Of course this is just a projection and the actual date could come sooner if there is a rush on the last remaining addresses out there.
So, if your company was unable to get any more IPv4 address after December 08…where would you be?
It’s time to start asking your vendors if they support IPv6, and if they don’t then ask when it will be supported. Most vendors are currently citing no demand and thus they aren’t pushing development. It’s time to start demanding IPv6 support in all your hardware and software…vote with your checkbook. It’s time.