World of Warcraft over IPv6

I’ll preface this by stating that I’m still under NDA with Blizzard regarding their IPv6 deployment, so there are details I cannot get into.

For World IPv6 day in June 2011, Blizzard committed themselves to making their extremely popular MMO, World of Warcraft, available over IPv6. The only catch was that if their client detected that your only IPv6 connectivity was from either 6to4 (2002::/16) or Teredo (2001::/32) automatic tunnel methods, the option to use IPv6 would be made unavailable. This was because of the potential for a poor playing experience because of overloaded or poorly managed relays. However if you used a statically configured tunnel, from either HE.NET/Sixxs/etc., there was no distinction between those tunnels or native IPv6.

They also made it incredibly simple to enable IPv6 for their game. So if you play, and have native IPv6 or one of the statically configured tunnels from a provider, here is how you enable it with a few clicks. Fire up the game, and select Options on the log in screen:

On the options screen, select Network and you should see a check-box for enabling IPv6, as long as you aren’t connecting from either 6to4 or Teredo. Go ahead and check the box and save by clicking on Okay:

At this point, if you log into the game, and your server is part of the IPv6 enabled shards/servers/etc., you’ll be connected over IPv6. In-game, if you mouse over the Game Menu button/icon, it will display your connection information in the ToolTip window. Below you can see that it is preferring to connect over IPv6. Latency was high since the game was still installing. However retesting after a completed install, I’ve got on average 36-42ms over IPv6 to the realm server:

So that is it. That is how easy it is to enable WoW to use IPv6. Kudos to the Blizzard team for taking this important step into bringing some major content onto IPv6. Now if they would just do this with their patcher. Maybe they will for World IPv6 Launch 🙂

IPMI over IPv6

One of the great server technologies for Out-of-band management is IPMI (Intelligent Platform Management Interface),  and more importantly version 2.0. This version allows for a true IP/KVM experience for the user to manage their server remotely. My preferred server hardware is from Supermicro for cost and features. For this example of IPMI available on IPv6, I’ll use their X7SPA-HF Atom based server board using the ATEN IPMI chipset.

Let me start by saying this IPv6 implementation is far from perfect, but who to blame: ATEN or Supermicro? First, you cannot configure IPv6 in the BIOS menu at all. You’ll need to configure it via the web software after you can reach it over IPv4. So log in and select Network under the Configuration menu.

So on this page, you’ll see all the network configuration options, most importantly IPv6. This implementation appears to support configuration either using SLAAC (autoconfiguration) or DHCPv6. You can also add a static IPV6 address. HOWEVER: you cannot manually configure an IPv6 default gateway/router. This means you are relying on the availability of Router Advertisements on the network to autoconfigure the gateway/router address.

So that is pretty much it. Not terribly hard to get up and running on IPv6, but could be done a little bit better in my opinion. It would be nice to see IPv6 configuration at the BIOS level.

IPv6 SIP Phone: Moimstone IP215

So on the hunt to leave softphones behind, I went looking for a hardware phone that could work with IPv6. I found Moimstone based out of Korea. A lot of what they show online about their phones looked promising. Getting a phone proved to be a real challenge, and I had to rely on a co-worker to have his family in Korea order the phone, and then ship it to me here in California. I went with their entry level model, the IP215, which was also the cheapest 😉

So first things first with a phone on a network using DHCP, log into its webserver as the admin account. If you don’t read or speak Korean, stumble around the menus a bit to change the language setting. When you log in, you’ll see the phone’s network and SIP status:

Click on Phone Setup and then its sub-menu Network. You’ll see a check-box to enable IPv6, so go ahead and check that off:

After checking that off, the page will update and let you have IPv6 auto-configure, or you can set a static IPv6 address, prefix length, and gateway on the phone:

Scroll down to the bottom of the page and click on Save Settings. The phone will report that the configuration has been saved, and will take effect after the next reboot:

So click on the Maintenance tab, and reboot the phone.

After the phone has cycled and starts running the new configuration, you should see your IPv6 address in the phone’s status page:

Now you are ready to use SIP over IPv6. Obviously the next step is telling the phone what server to use. Click on the Call Setup tab and the Server sub-menu. Sadly you only get to specify IPv4 or IPv6 not both. So select the IPv6 radio button. One of the issues I noticed was that the phone didn’t like parsing IPv6 addresses, so I use a valid hostname for the server settings:

At this point, with valid user and server settings, and IPv6 enabled, the phone should be registering and able to take and make calls. One issue is that the phone doesn’t handle IPv6 literals in the address/hostname fields. This means it absolutely needs an IPv4 based recursor for performing DNS lookups.

IPv6 Toys: Axis Cameras

Probably one of my favorite IPv6 enabled devices are the cameras made by Axis. On many of their newer models, IPv6 support is now in the RTSP software they use, so you aren’t limited to watching just their MJPEG streams over IPv6. This will be a super simple walk-through for enabling IPv6 on the cameras, and even setting a static IPv6 address.

First and foremost, make certain your camera is running the latest firmware. If not, upgrade before changing any settings. So lets log into your camera. I’m using a M1011, but the menus we’ll use and options we’ll set were similar if not exactly the same for my 215PTZ and 210. Under Basic Setup select the TCP/IP submenu, which should look like the following:

On this page, You should see a check-box for enabling IPv6. Selecting this and saving the setting both enables IPv6 as well as auto-configuration if that is available on your network.

If you want to set a specific static IPv6 address, you need to go into the more detailed configuration settings area. Under the System Options menu, you’ll find the Advanced sub-menu. Select Plain Config as shown below:

After entering the Plain Config, it will be a very minimalist page, and there will be a pulldown menu. Select Network and proceed to view the settings. Scroll down to the section covering the network interface. For just a static IP configuration, uncheck “Accept IPv6 router advertisements” and set DHCPv6 to “off”. Make certain that “IPv6 Enabled” is checked off 😉 In the network interface manual setting section, you can set your static IPv6 address as well as its default IPv6 gateway. Save the settings and the system will be available on that static IPv6 address.

Once back out into the standard menu system, you can verify your network settings  under the TCP/IP settings sub-menu and clicking on the “View” button to bring up current settings:

So doing this static IPv6 configuration, I have two cameras online:

 

World IPv6 Day: Round 2!

Announced today: http://www.worldipv6launch.org/

[Washington, D.C., USA and Geneva, Switzerland] – 17 January 2012 –
Major Internet service providers (ISPs), home networking equipment
manufacturers, and web companies around the world are coming together to
permanently enable IPv6 for their products and services by 6 June 2012.

Organized by the Internet Society, and building on the successful
one-day World IPv6 Day event held on 8 June 2011, World IPv6 Launch
represents a major milestone in the global deployment of IPv6. As the
successor to the current Internet Protocol, IPv4, IPv6 is critical to
the Internet’s continued growth as a platform for innovation and
economic development.

“The fact that leading companies across several industries are making
significant commitments to participate in World IPv6 Launch is yet
another indication that IPv6 is no longer a lab experiment; it’s here
and is an important next step in the Internet’s evolution,” commented
Leslie Daigle, the Internet Society’s Chief Internet Technology Officer.
“And, as there are more IPv6 services, it becomes increasingly important
for companies to accelerate their own deployment plans.”

ISPs participating in World IPv6 Launch will enable IPv6 for enough
users so that at least 1% of their wireline residential subscribers who
visit participating websites will do so using IPv6 by 6 June 2012. These
ISPs have committed that IPv6 will be available automatically as the
normal course of business for a significant portion of their
subscribers. Committed ISPs are:

●      AT&T
●      Comcast
●      Free Telecom
●      Internode
●      KDDI
●      Time Warner Cable
●      XS4ALL

Participating home networking equipment manufacturers will enable IPv6
by default through the range of their home router products by 6 June
2012. Committed equipment manufacturers are:

●      Cisco
●      D-Link

Web companies participating in World IPv6 Launch will enable IPv6 on
their main websites permanently beginning 6 June 2012. Inaugural
participants are:

●      Facebook (www.facebook.com)
●      Google (www.google.com)
●      Microsoft Bing (www.bing.com)
●      Yahoo! (www.yahoo.com)

Content delivery network providers Akamai and Limelight will be enabling
their customers to join this list of participating websites by enabling
IPv6 throughout their infrastructure.

As IPv4 addresses become increasingly scarce, every segment of the
industry must act quickly to accelerate full IPv6 adoption or risk
increased costs and limited functionality online for Internet users
everywhere. World IPv6 Launch participants are leading the way in this
effort.

For more information about World IPv6 Launch, products, and services
covered, as well as links to useful information for users and
information about how other companies may participate, visit:

http://www.worldipv6launch.org

About the need for IPv6
IPv4 has approximately four billion IP addresses (the sequence of
numbers assigned to each Internet-connected device). The explosion in
the number of people, devices, and web services on the Internet means
that IPv4 is running out of space. IPv6, the next-generation Internet
protocol which provides more than 340 trillion, trillion, trillion
addresses, will connect the billions of people not connected today and
will help ensure the Internet can continue its current growth rate
indefinitely.

About the Internet Society
The Internet Society is the world’s trusted independent source of
leadership for Internet policy, technology standards and future
development. Based on its principled vision and substantial
technological foundation, the Internet Society works with its members
and Chapters around the world to promote the continued evolution and
growth of the open Internet through dialog among companies, governments,
and other organizations around the world. For more information, see:
www.internetsociety.org

Akamai Technologies, Inc.
Jeff Young
jyoung@akamai.com

AT&T
Jenny Bridges
jenny.bridges@fleishman.com

Cisco
Marc Musgrove
mmusgrov@cisco.com

Comcast
Jorge Alberni
jorge_alberni@comcast.com

D-Link
Denise Keddy
denise.keddy@dlink.com

Facebook
Nisha Gulati
ngulati@fb.com

Google Inc.
press@google.com

Internet Society
Wende Cover
cover@isoc.org

Internode
John Harris
jharris@impress.com.au

Limelight Networks
[TK]

Microsoft Bing
Bill Hankes
bhankes@microsoft.com

Time Warner Cable
Justin Venech
justin.venech@twcable.com

Yahoo!
Christina Scharrenberg
cscharr@yahoo-inc.com

HE.NET IPv6 Certification Program; a history & its importance

Even though I’m no longer with HE.NET, I still take pride in what we did for IPv6 during my time there. One of the things I was happy to help create was the IPv6 Certification Program. In fact, I’m the first Sage, and not just because we had to make sure the tests worked 😛 I did it with one of my personal domains.

History: The program was born from the critical mass of two things going on at HE.NET

  • The CEO pushing staff to get more accredited certifications completed
  • The CEO asking to get 80-100 links to tunnelbroker.net while Sam and I rebuilt the front and backends

On one of those random 2AMs where I was looking at stuff to tweak for the broker, I was also updating various wikis on the internet with updated instructions for using it. A quick way to update and get fresh links to the site. I started thinking that we needed something else, that you could put on your website like a seal of approval or something, that linked back to the broker. I started thinking about proving that your site was IPv6 accessible. I came up with some random seals of approval over at Says-It. Here are some of the first ideas I had come up with:

I made a quick and dirty Perl CGI that took a domain, ran some DNS queries against it, and spat out Yes/No for the results. Tests were AAAA record, MX with AAAA record, NS with AAAA record. Took this to the CEO and he liked it so much, it became the next project after we finished revamping the broker.

So Sam and I began working on the Certification Program. We only had 3 titles to start:

  1. Enthusiast: could browse IPv6 enabled websites
  2. Professional: could host IPv6 websites and email
  3. Guru: proven ability to create PTR records and had nameservers available over IPv6

It was a bit rough around the edges at first, but eventually matured to where the project met the requirements set out before us, and eventually other people in the company contributed some great code and fixed bugs. Although we never really worked out the “Organization” side of the program, the “Individual” side had taken off with great interest. I had even started toying with the idea of swag, like a mug!

Now for the last 2 years they’ve been mailing out SAGE certified users t-shirts:

(me in my shirt!)

Why it is important: Even though not accredited (since that would require fees, offline testing, etc.), the program absolutely helps people test their IPv6 configuration skills regarding Web Servers, Mail Servers, and DNS servers & records. The idea isn’t to spoon-feed users step-by-step instructions, but rather set them with a task or goal to accomplish. The first level of “Newbie” isn’t that challenging. Read some text about IPv6, and answer some questions about what you just read.

The first challenge is the “Explorer” rank. To get this, you need IPv6 connectivity from the machine you view the site from. This is “eyeball”, or end-user, connectivity; usually provided over some sort of tunnel when native isn’t available. What this proves is that either: you knew to set up a tunnel, or didn’t know that your NAT appliance was secretly using 6to4 and pushing out RAs for auto-configuration, or teredo was enabled on your Windows machine, or you have native IPv6.

The next step is where more configuration is done on the hosting, or “content”, side. Here you need to have gotten IPv6 connectivity configured and working on a machine that will serve webpages, and configured a AAAA record for that server’s hostname/FQDN. After you put up a file that the program fetches, you’ll be awarded the “Enthusiast” title.

The following rank is “Administrator”, which you get after associating a AAAA record with your MX, and having an email sent to an account at that domain with a code you paste back in on the site, confirming the test.

Setting up a working Reverse DNS entry (PTR record) is the next step to complete in order to be rewarded with the title of “Professional”. The PTR record you must create is for that MX record.

Originally “Guru” was the last stage in testing. This requires two things of the participant:

  1. nameservers with AAAA records
  2. bring able to query those nameservers over IPv6, on their IPv6 address, for the AAAA record of the FQDN submitted for the “Enthusiast” webserving test.

Once a user had passed those two steps, they were done. Then after some more tinkering, we decided to add one final stage of testing: IPv6 glue for your domain.

Obtaining “Sage” means your domain has IPv6 glue submitted by your registrar, to the TLD nameservers. There are two ways to really accomplish this: either properly with host records set at the registrar, or using out of bailiwick nameservers (like .cc domain records served by nameservers in .net).

So that is it. A brief history of the program I co-created, and how it is designed to test one’s mettle with IPv6 configurations.

A quick NAT64/DNS64 setup

So you want to play around with an IPv6-only network! Great! One problem, lots of content is still on IPv4 🙁 A possible solution or workaround? Using NAT64 & DNS64 to let IPv6-only hosts communicate with IPv4 hosts. The gist of it is that you send your DNS lookup requests to a caching DNS recursor that forges (or rather creates) AAAA records for hosts that do not naturally have them configured. That DNS server creates the AAAA records using an IPv6 range will be configured on the NAT64 portion. That NAT64 machine is going to handle the translation of IPv6 to IPv4.

I’ll use ISC’s BIND9 for the DNS64 component, and Tayga for the NAT64. Because Tayga is designed for Linux, this will cover setting up a Linux based NAT64/DNS64 system. Start by installing the latest stable BIND9 daemon on your target machine. Next, pick a range of IPv6 addresses to generate the AAAAs from. We’ll go with our standard documentation prefix and specify 2001:DB8:1:FFFF::/96. Assuming you have proper routing control over your network, you’ll statically route the /64 you carved it from to the NAT64 machine. A very simple BIND9 named.conf.options can look like this:

options {
        directory "/var/cache/bind";
        auth-nxdomain no;
        listen-on-v6 { any; };
        allow-query { any; };
        dns64 2001:db8:1:ffff::/96 {
                clients { any; };
        };
};

You’ll want to lock down allow-query to whatever ranges/networks you plan on allowing DNS64 looksups with, as well as any specific IPv6 address you want it listening on. In the meantime, the above configuration will let any range query so you can test quickly. Start up the DNS daemon, and start making some queries against it for IPv4-only hostnames, they aren’t hard to find. Then try some queries for hosts you know have AAAA records. You’ll find that it doesn’t mangle them and will give you their proper AAAA record.

Next step is configuring Tayga. I’ve been installing both NAT64 and DNS64 components on the same machine, because I found that for a small network the load and traffic isn’t that much. So on the same machine, install Tayga from a package or source. Configure the tayga.conf file with:

tun-device nat64
ipv4-addr 192.168.0.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.0.0/24

Next thing I did after reading the Tayga READMEs and FAQ on their site, was set up a quick shell script to fire off, eventually called from rc.local and called it start64.sh:

#!/bin/bash
tayga --mktun
ip link set nat64 up
ip addr add 192.168.0.1 dev nat64
ip addr add 2001:db8:1::1 dev nat64
ip route add 192.168.0.0/24 dev nat64
ip route add 2001:db8:1:ffff::/96 dev nat64
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT
tayga
/etc/init.d/bind start

So from an IPv6-only host, set your resolver to 2001:db8:1::1 (for this example), and try reaching an IPv4 only hostname with pings, traces, or connecting to the services run on it.

Now, to cover things that will need editing and additional configuration:

  • IPv6 address(es) that BIND9 listens on
  • IPv6 ranges that BIND9 will allow queries from
  • actual IPv6 range used for NAT64
  • adding ip6tables rules to restrict which IPv6 ranges are even allowed to use the NAT64 portion

Advanced tricks: BGP Anycast

So let us assume you want to try and blanket a network with these boxes for whatever reason, but perhaps the best of all: just to do it 🙂 Set aside a /48 to use for the NAT64/DNS64. Add on either BIRD or Quagga to the machine, and configure that to announce the /48 specific to an upstream router, ideally as part of your iBGP mesh and as a route-reflector client. Configure both BIND9 & Tayga to use a /96 out of that /48. Use the same config on all the machines that will act as anycast nodes. I’ve tested this between two locations by running a wget of an ISO from an IPv4-only hostname, and pulled the /48 announcement from the node I saw the traffic going over. The wget didn’t even hiccup, and instead reported “Read error at byte 504296054/4312793088 (Connection reset by peer). Retrying.” and then kept pulling down the file without issue. Perhaps more failover testing could be done, but I was happy with the results.

Caveat: IPv4 literals will not work since they aren’t hostnames with A records that can have AAAA records created.

IPv6 and Google Analytics

So rather than rely on Webalizer 2.23 with proper IPv6 parsing support (yet all addresses end up being designated as sourcing from Montenegro?), I’m trying out Google Analytics. One of the first things I noticed is that all IPv6 hits/views end up being listed as “(not set)”. Since I control and access my logs I can get specifics, however I’d like a little more detail.

That is when I happened upon the APNIC Labs IPv6 Capability Tracker. Just had to follow their directions for adding the JS code, with some minor tweaks to work with my Google Analytics WP plugin. Now I’m seeing a bit more detail on the types of IPv6 visitors exactly how APNIC Labs promised 😀 Still need to read up on “events” to figure out what the negative values I’m seeing mean.

Ebay: no longer IPv6 single-homed!

Ebay for a while was stuck single-homed to Cogent (AS174). They finally added another IPv6 transit (Tinet, AS3257), which means the majority of IPv6 users can now reach their auctions over IPv6.

So go forth and buy crap! http://ipv6.ebay.com

Configuring RA on routers or RADVD with Linux

Ok, so in an ideal world, you have 2 allocations: 1 allocation for your server/router’s uplink, and 1 allocation that is a statically routed subnet (either a /64 or /48) to your side of that uplink allocation. For example:

2001:DB8:0:1::/64 = uplink allocation
2001:DB8:0:1::1 = upstream router IP (gateway)
2001:DB8:0:1::2 = customer configured IP (your WAN uplink interface to provider)
2001:DB8:2::/48 = statically routed subnet pointing at 2001:DB8:0:1::2

If you are using a hardware router like a Cisco or a Brocade and you want a LAN segment to have the hosts auto-configure IPv6 addresses, then you simply add the following to that LAN facing interface:

ipv6 enable
ipv6 address 2001:DB8:2::1/64

If hosts on that LAN segment have auto-configuration enabled, then they will do just that: auto-configure IPs on their LAN interfaces using EUI-64/SLAAC.

To use a Linux machine to act as your IPv6 gateway, you’ll need a little help from the RADVD package. First and foremost, you will need IPv6 packet forwarding enabled on the Linux machine that will act as your IPv6 router. Edit /etc/sysctl.conf and add the following line:

net.ipv6.conf.all.forwarding = 1

Then run: sysctl -p to apply changes made to the config file.

Next you will need an IP out of one of the /64s, from your statically routed /48, that you want to use for auto-configuration configured on your LAN facing interface. Let us assume that eth0 is your WAN interface and eth1 is your LAN interface. IP configurations for those interfaces should look like:

eth0 = 2001:DB8:0:1::2/64
eth1 = 2001:DB8:2::1/64

You’ll need to install RADVD either from source or your preferred Linux distro repository of packages. Then edit the radvd.conf file for your prefix and any options you want to enable. What follows is my generic sample configuration. This hasn’t failed to work for me yet:

interface eth1
{
     AdvSendAdvert on;
     AdvHomeAgentFlag off;
     MinRtrAdvInterval 30;
     MaxRtrAdvInterval 100;
     prefix 2001:DB8:2::/64
     {
          AdvOnLink on;
          AdvAutonomous on;
          AdvRouterAddr on;
     };
};

Now you should be able to fire up the RADVD daemon, and hosts on the LAN set to auto-configure should begin to do so. You will find that on the LAN host, their default route and gateway point to the Link-Local address of eth1 on the Linux machine acting as the IPv6 gateway/router. This is entirely normal and expected.

Congrats! Now you should have proper IPv6 access from behind either a hardware router or a Linux machine acting as the gateway/router.