ipv6 at home, part 2.5: Google, DHCPv6, speed tests, troubleshooting, various

This blog post is part of a series on ipv6. In part 1, I provided an overview of ipv6 and looked at Teredo, the technology built into Windows Vista; in part 2, I looked at AYIYA tunnels through aiccu, using sixxs net as a tunnel broker. I also got stuck for a very long time on trying to use Windows as a router for an ipv6 subnet on that setup, and ultimately failed to make that work.

Part 2.5 is going to be an in-between – a collection of ipv6-related tidbits that will, hopefully, be useful, but have no particular cohesion.

Google services on ipv6

Back in January, Google announced that they had moved a number of their services to be multi-homed. To avoid causing issues for people with Vista that didn’t have functioning ipv6 connectivity, this is an opt-in service. That is achieved by using a DNS server that peers with Google for ipv6 addresses.

Unless you work for an ISP, you are not going to peer your own servers with Google. However, several tunnel brokers, including Hurricane Electric and sixxs, offer DNS servers that can serve up Google ipv6 addresses.

Here’s an example nslookup:

> www.google.com
Server:  UnKnown
Address:  2001:470:20::2

Non-authoritative answer:
Name:    www.l.google.com
Addresses:  2001:4860:b002::68
 74.125.91.103
 74.125.91.104
 74.125.91.147
 74.125.91.99
Aliases:  www.google.com

As you can see, both A (ipv4) and AAAA (ipv6) records are being returned. In order for Vista to use the ipv6 address, you need to use the ipv6 address of the DNS server. If you query DNS over ipv4 and get both A and AAAA records, Vista will prefer an ipv4 address.

You can test which address is going to be used by running “ping http://www.google.com”, which will show the numerical address that the OS is trying to reach.

DHCPv6

If you are using a software tunnel such as AYIYA over aiccu, then you can set the DNS server to be used manually, through the Control Panel. If you are using an ipv6-capable router or firewall, however, you can send out that information over DHCPv6.

Cisco has a clear and concise paper on DHCPv6. From an implementation standpoint, it is very simple: Decide whether DHCPv6 is only going to serve DNS addresses, or whether it is going to handle all ipv6 address assignment, too. Then set flags for your RA (Router Advertisement) Configuration: “O” (“Other Parameters”) if RA handles addresses and DHCPv6 handles DNS, or “M” (“Managed”) if DHCPv6 handles addresses and DNS.

An RFC draft dated July 2005 suggests to expand RA to be able to hand out DNS server addresses without the need for DHCPv6. That draft has not yet been adopted, and I have yet to see an implementation in a major vendor’s routing OS.

[Update 2008-08-02] Jeremy points out that the above statement about implementation being “very simple” is rather brash. He’s correct, and explains the differences between Windows and Linux/Unix in this regard in his company blog. With lots of references to “dueling RFCs”, fun. For a broader view of ipv6 and its real-world applications, and a much more in-depth view than “okay how do I get this to work at home anyhow”, definitely do follow his blog.

Speed Test

If you’d like to compare your ipv6 speed to your ipv4 speed, you can do so through an ipv6 speed test offered by the University of Maine. The test can actually run in both ipv6 and ipv4, which makes it useful for comparison.

ftp.isc.org is reachable through ipv6 as well – if you can find a suitably large file there, it could serve as a measure of download speed over ipv6.

Troubleshooting

This may have to be a “paragraph-in-perpetual-progress”. A few of the tools I found useful are:

Wireshark, in case you need to see what is happening to your ipv6 packets – are they leaving on the interface you think they should be leaving on, do you see return packets?

netsh is full of useful commands in its “interface ipv6” context, among them:

show route – does that just, shows you the ipv6 routing table

show siteprefixes – you’ll get a list of all the ipv6 prefixes (networks) configured on your machine

show prefixpolicies – you’ll see a list of which prefixes are preferred in which order. This is explained in more detail at ipv6 Day. Note that my own attempts to “fiddle with” prefix policy left me in a state where Vista would not function for ipv6 traffic at all.

reset – resets all ipv6 settings to default. Really useful if you’ve done a little too much fiddling. Needs a reboot.

show addresses – will show you the ipv6 addresses and their lifetime

show interfaces – configured interfaces and their up/down state

ipconfig /release6 and ipconfig /renew6 can be used to release/renew RA or DHCPv6 addresses

Turning off unused tunnel interfaces

Windows comes with built-in Teredo, ISATAP and 6-to-4 tunnel interfaces. These can become a distraction when configuring an alternative way to access ipv6, such as through your router or a third-party tunnel application.

Courtesy of ipv6 Day comes a description of registry settings to turn these off. There are a lot of possible combinations, including some that will turn off ipv6 entirely, which can come in handy in corporate environments.

The TL;DR for turning off all Windows built-in tunnels is:

  • In regedit, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\
  • Create a DWORD called DisabledComponents
  • Set it to “1”
  • Reboot

ipv4 exhaustion counters

Hurricane Electric, my preferred tunnel broker, offers a number of widgets and applications to keep track of ipv4 address space exhaustion. That includes Vista / Win 7 gadgets, Google Desktop and iGoogle gadgets, iPhone/iPod touch apps, and a web widget.

The “days remaining” are to be taken with a grain of salt. 676 days to complete ipv4 exhaustion! (As of August 2nd 2009) Actually, what is likely to happen is that we’ll see ipv4 space become more and more expensive, to the point where it is no longer economically feasible to own large portions of it just for access purposes – we’ll see hosting companies running it for decades, and your typical office running on v6 with a way to reach v4 over a tunnel. The reverse of today’s situation – eventually.

ipv6 certification

[Update 2009-08-06 – More detail on DNS requirements for this cert program]

Hurricane Electric also offers a fun ipv6 certification. What’s interesting about it is that it’s almost completely results-based. The first few levels (“Newbie” and so on) are just a questionnaire, but to reach the coveted “Sage” level, it’ll be doing real tasks, such as sending/receiving SMTP email over ipv6.

Achieving this entirely from home has one more than one challenge – you need a DNS server that will let you set AAAA records, will act as delegation for ipv6 PTR records, has its own AAAA entry and will respond to ipv6 queries, and you will need ipv6 glue for your DNS server at the TLD. There are a number of free ones available. These will let you set AAAA records, and usually also function for RDNS delegation. None of them are reachable over ipv6. A combination of afraid.org, v6ns.org and a BIND server on your machine will get you all the way to “Guru”, but you won’t get “Sage” that way, as you’ll be missing the TLD glue.

The certification tests use the same domain you start out with throughout, or a subdomain thereof. If you want “smooth sailing”, choose a domain you own on a registrar that supports ipv6 glue.

It’s a worthwhile exercise in that you’ll find that ipv6 connectivity itself is really not the issue – finding real-world applications that support ipv6 is the larger challenge. You’ll also learn more about ipv6 DNS than you truly ever wanted to know.

ipv6 address space – think about registering yours

If you are involved in a corporate networking group, you may want to think about how you are going to handle ipv6 space. Traditionally, you get your address assignments from your ISP. This creates an amount of pain when moving ISPs. In ipv4, that’s public-facing addresses, while the internal network can stay untouched. In ipv6, everything uses public addresses – no more NAT (pending discussion, there are address translation efforts underway for ipv4/ipv6 translation – which doesn’t change the situation w/ regards to your ipv6 space). That means an ISP move could potentially require you to renumber everything, down to the last printer and desktop.

You can plan for this, by avoiding static assignments wherever possible, and always thinking about “how would I switch this to an entirely different subnet if I had to?” every step of the way.

Or, if you qualify, you can get a direct assignment of ipv6 space from ARIN. This used to be trivially easy as an “early adopter”, but that policy has been discontinued. Now, you need to be either a) eligible for direct ipv4 assignment (that’s getting tougher and tougher by the month) or b) already have a direct ipv4 assignment, and show that you use it efficiently.

It’ll be interesting to see how this policy evolves as ipv4 space becomes ever scarcer – will ARIN just stop assigning v6 space directly to end users, or will we see policies that are not tied to v4 eligibility?

[Edit 2009-08-02]

As Jeremy points out in a comment, ULA space (Unique Local Address as per RFC4193) is a the solution to receiving address space from your ISP, but wanting to avoid the pain of needing to re-do addressing of your entire network when moving ISPs. As long as the devices you give these addresses to do not need connectivity to the Internet, that is: As per the RFC, “They [the ULA addresses] are not expected to be routable on the global Internet”. In practice, that translates into a requirement to filter out ULA space at the BGP border router. SixXs has a page to register ULAs. As they point out, while there is no requirement to register ULAs, collisions (which are not very likely but can happen) can be dealt with by registering ULAs anyway.

Advertisements

3 thoughts on “ipv6 at home, part 2.5: Google, DHCPv6, speed tests, troubleshooting, various

  1. Good blog, but I found a few things you were a little off on:

    1. DHCPv6 from a client-side works a bit different for Linux than it is with Windows. Windows requires the managed flag set in the router’s RA. Only the Managed, not the Other flag. The Linux “dhcp6c” or “dibbler-client” will automatically send out a DHCPv6 solicit message without this being set in the RA.

    2. You should add the link about registering for ULA space at SixXs..

    1. I can add the SixXs link, sure.

      As for DHCPv6 – I currently run with the O flag set, to pass out DNS, and leave addressing to RA. It works with Windows Vista64 that way. Do you have some reference to show in what circumstances Windows requires the M flag? I’d expect that Windows would require M (M only and not O) if DHCPv6 handles address assignment – and would call such client behavior “adherence to the standard”, actually.

      As for Linux: I don’t use it for day-to-day tasks, and therefore I don’t cover it in this blog. If you have some writings on Linux and ipv6, I’d be happy to track back to it.

      1. you are right, Vista does require at least the M flag for it’s cue to make an all nodes multicast DHCPv6 solicit.. However, there’s been a debate in the IETF for a few years now on which behavior is correct.. If you go by RFC 4862, then the Windows behavior is correct. However, if you go strictly by RFC 3315, it’s not as explicit.

        I wrote about this in our blog:
        http://www.commandinformation.com/blog/?p=103

        Here’s the SixXs link:
        http://www.sixxs.net/tools/grh/ula/list/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s