IPv6 Hour at NANOG: A Follow-Up

I wrote in the previous post about IPv6 hour at NANOG, in which the dual-stacked wireless LAN would be shut down and all access would be via the IPv6-only wireless LAN; getting IPv4 destinations outside the LAN would be via NAT-PT.

It started off a little rough. Throughout the conference I had IPv4 turned off on my MAC and had been working just fine on the IPv6-only LAN. Admittedly I didn’t try many different online applications, just the things I use on a regular basis: Web browsing and e-mail. An I FTP’d some files to my editor at Cisco Press – all without difficulty.

But when the dual-stack LAN was shut down everything stopped working. Apparently when a few hundred people suddenly jumped to the IPv6-only LAN the Linux-based NAT-PT could not scale.

After a bit of “tweaking,” however, (I haven’t yet found out just what sort of tweaking was done), access came back up.

As Randy Bush announced at the beginning of the event while the NAT-PT was still down, sometimes a failure is more educational than a success. While overall the IPv6 Hour was not a failure, it did serve its intended purpose of helping to reveal problems at scale, problems that can then be taken back to vendors for resolution before you try implementing IPv6 on your own production network.

Among the problems revealed:

-       NAT-PT was supposed to be supported over both the Linux-based NAT-PT and Cisco’s NAT-PT. I’m told that the implementers could not get the Cisco NAT working, although that might have just been a configuration issue.

-       Windows XP, while supporting IPv6 packets, does not support IPv6 DNS. Therefore an RFC 1918 address and a local IPv4 DNS resolver had to be given to XP users for them to get online.

-       As I mentioned in the last post, MAC OS X does not support DHCPv6, so the IPv6 DNS addresses had to be entered manually.

-       IPv6 must be turned on in Thunderbird and Firefox browsers; it’s off by default.

All in all this was an enlightening event because any transition must, as a measure of success, be transparent to the end-users. In the case of IPv6, no one wants to hear that they need to do some special configuration on their PCs to get the same access they previously had without those special configurations.

For me, being a dedicated MAC user, I hope Mr. Jobs and Co. release a DHCPv6 patch or at least get it on the OS X roadmap real soon.

The IPv6 Hour will be tried again at APRICOT next week, and at the IETF in Philadelphia the week of March 10.

Rocky Mountain IPv6 Summit

The Rocky Mountain IPv6 Task Force will be holding its first Rocky Mountain IPv6 Summit in Denver on April 9^th. We’re lining up a good group of speakers and a very informative agenda; if you’re in the Colorado-Wyoming-New Mexico region and want to know more about IPv6, I hope to see you there!

You can get more information, and sign up, at:

http://www.rmv6tf.org/SpringEvent.htm