← Revision 1 as of 2007-09-02 14:02:30
Size: 8747
Comment: tasty recipe for multiple IPv6 unicast address soup
|
← Revision 2 as of 2007-11-17 11:26:08 →
Size: 5559
Comment: trouble in paradise
|
Deletions are marked like this. | Additions are marked like this. |
Line 13: | Line 13: |
== Status == | == Production == |
Line 15: | Line 15: |
The CoreServer systems are all configured for 6to4 support; see ["IPv6Addresses"]. | 6to4 has previously been used in production on CoreServer systems and test nodes. |
Line 17: | Line 17: |
Although it might seem appealing, 6to4 is probably not a good solution to provide IPv6 connectivity to nodes. It would work well for a few systems, but those unfortunate successes would then be saddled with yet another burden of inconsistency. |
* Production deployment of ["6to4"] connectivity to CoreServer systems was completed 2007-09-02. * Initial deployment of ["6to4"] connectivity to test nodes was completed 2007-09-23. * All publication of ["6to4"] addresses ended 2007-11-17. Initial testing yielded positive results, but continued deployment soon revealed that most current IPv6 stack implementations do not yet provide adequate support for hosts with multiple IPv6 addresses. Essentially, ["6to4"] only works correctly if it is being used exclusively. As time goes on, IPv6 software will continue to improve and eventually all of the important implementations will have reliable support for hosts with multiple addresses. At that point, continued production deployment of ["6to4"] might be worthy of consideration. See '''Address selection''' below for more information about multiple address support. |
Line 31: | Line 37: |
The following lines should be added at the end of `/etc/network/interfaces`. Replace `my:pre:fix::` with the 6to4 IPv6 prefix you calculated - do not remove the trailing `1`. | The following lines should be added at the end of `/etc/network/interfaces`. Replace `my:pre:fix::` with the 6to4 IPv6 prefix you calculated. |
Line 36: | Line 42: |
address my:pre:fix::1 | address my:pre:fix:: |
Line 67: | Line 73: |
== Prefixes == For each global-scope IPv4 address that is assigned to a host, 6to4 allows a valid 48-bit IPv6 prefix to be constructed for use by that host. It is tempting to make use of these prefixes - a `/48` gives up 2**80 (1,208,925,819,614,629,174,706,176) addresses, although generally large prefixes like that are divided into `/64` subnets, each containing 2**64 (18,446,744,073,709,551,616) addresses. To put this in perspective, IPv4 (ie. the Internet) has ''only'' 2**32 (4,294,967,296) addresses total. At this point, this space is not generally being used, beyond the selection of a single address for each 6to4 host. The reason for this is the possibility of being forced to renumber some 65 thousand subnets due to the loss of a single IPv4 address. |
|
Line 83: | Line 82: |
If you are a beginner or a casual IPv6 user, 6to4 just might give you everything you need. It's not perfect but it also isn't half bad. That said, if you find yourself using a 6to4 gateway frequently, you're probably going to want something better. | If you are a beginner or a casual IPv6 user, 6to4 just might give you everything you need. It's not perfect but it does work. That said, if you find yourself using a 6to4 gateway frequently, you're probably going to want something better. |
Line 97: | Line 96: |
[http://www.ietf.org/rfc/rfc3484.txt RFC 3484] defines a pretty nice default address selection policy. In this section, we'll look at how it works and how we can take advantage of it. | [http://www.ietf.org/rfc/rfc3484.txt RFC 3484] defines a reasonable default address selection policy. |
Line 99: | Line 98: |
This policy does a couple of specific things we're interested in: 6to4 destination addresses are always contacted via 6to4 source addresses if possible, and native IPv6 destination addresses are always contacted via native IPv6 source addresses if possible. The idea is to take full advantage of 6to4 support when it is appropriate, and avoid it entirely when it is not appropriate. | |
Line 100: | Line 100: |
=== Caveats === OS support for RFC 3484 is not quite ubiquitous just yet. I've tested a few systems to figure out the details. This part is included before the parts describing the related cool stuff in hopes of saving you from the frustration of setting it all up only to realize that your operating system doesn't support the features you actually want. Whether you have good luck or bad, please update this list accordingly if you go all the way through the process with a system which is not yet listed. Positive results: * Mac OS 10.4.10 works * Linux with glibc 2.5+ works - http://people.redhat.com/drepper/linux-rfc3484.html Negative results: * Linux with glibc pre-2.5: round-robin, evidently no address selection policy support It is worth pointing out that the worst-case scenario for a host without address selection policy support would be that some traffic might end up going through a 6to4 gateway. Everything will still ''work'', it just won't be optimized in the same way. === Default policy === The default address selection policy defined in RFC 3484 does a couple of specific things we're interested in: 6to4 destination addresses are always contacted via 6to4 source addresses if possible, and native IPv6 destination addresses are always contacted via native IPv6 source addresses if possible. Also, 6to4 addresses are preferred if it's possible to use them on both sides. Essentially, the idea is to take advantage of an IPv4 network if and when it's appropriate, while avoiding those 6to4 gateways at all costs. === Configuration === Follow these steps on your local network router with native IPv4 connectivity. This assumes that the router has no IPv6 support to begin with; simply skip any steps which have already been done. * Enable 6to4 support. * Assign a 6to4 address with a `/64` prefix to your local network interface. * Establish IPv6 Internet connectivity via TunnelBroker; you need at least a `/64` prefix delegation. * Assign a tunnel-delegated address with a `/64` prefix to your local network interface. * Configure `radvd` (or something similar) to announce both prefixes over your local network interface. Before long, IPv6-capable hosts on your local network will set themselves up with a unicast address for each prefix which is now being announced. === Outgoing connections === Once you've got those unicast addresses, you're done. Go ahead, try it out. You'll probably want to use something simple, such as `traceroute6` or `ping6`. An ideal tool for this job will tell you the ''source'' address being used. Connect to a couple of 6to4 sites and a couple of native IPv6 sites. It should be telling you that it is automatically selecting the best possible source address to reach each destination; 6to4 for 6to4, native for native. === Incoming connections === With all of these perfectly good addresses hanging around, why list only one in DNS? To allow other hosts the opportunity to consider more than one of your IPv6 addresses during address selection when connecting to you, simply add an `AAAA` record to your DNS zone for each unicast address you plan on accepting connections with. For example, `donk.personaltelco.net` has two IPv6 addresses, `2001:4830:1500:e8::2` and `2002:cea3:7a62::1`: {{{ donk AAAA 2001:4830:1500:e8::2 donk AAAA 2002:cea3:7a62::1 }}} |
Unfortunately, software implementations of RFC 3484 tend to be incomplete. Any report of a complete, successful implementation would be appreciated... |
6to4
Overview
6to4 is a system that allows ["IPv6"] packets to be transmitted over an IPv4 network (ie. the Internet) without the need to configure explicit tunnels.
One of the most attractive aspects of 6to4 is the potential for experimentation. With nothing more than a single global-scope IPv4 address and a few minutes of free time, you can get a nice chunk of IPv6 Internet to play with.
Production
6to4 has previously been used in production on CoreServer systems and test nodes.
Production deployment of ["6to4"] connectivity to CoreServer systems was completed 2007-09-02.
- Initial deployment of ["6to4"] connectivity to test nodes was completed 2007-09-23.
- All publication of ["6to4"] addresses ended 2007-11-17.
Initial testing yielded positive results, but continued deployment soon revealed that most current IPv6 stack implementations do not yet provide adequate support for hosts with multiple IPv6 addresses. Essentially, ["6to4"] only works correctly if it is being used exclusively.
As time goes on, IPv6 software will continue to improve and eventually all of the important implementations will have reliable support for hosts with multiple addresses. At that point, continued production deployment of ["6to4"] might be worthy of consideration. See Address selection below for more information about multiple address support.
Configuration
In terms of basic setup, 6to4 is an icon of simplicity.
Debian GNU/Linux
DebianLinux breaks it down to 5 lines of configuration.
First, you must [http://www.ip-calc.com/ calculate your 6to4 IPv6 prefix] based on the IPv4 address which is being used. (The web-based calculator refers to the relevant value as the Compressed 6to4 Address.)
The following lines should be added at the end of /etc/network/interfaces. Replace my:pre:fix:: with the 6to4 IPv6 prefix you calculated.
auto sit0 iface sit0 inet6 static address my:pre:fix:: netmask 64 gateway ::192.88.99.1
After these lines have been added, 6to4 support will be automatically started at boot. The following command will enable it immediately:
sudo ifup sit0
That's all there is to it.
Apple Mac OS X
OS X makes 6to4 configuration a matter of a few clicks in Network Preferences.
http://www.cs.utk.edu/~moore/hints/howto-6to4-macosx.html
Apple AirPort Extreme
Rumor has it that the latest generation of Apple AirPort Extreme 802.11n base stations are configured by default to advertise an IPv6 prefix to clients configured with 6to4.
Everything else
Most major operating systems include 6to4 support. Additional documentation is always welcome!
Gateways
Routing traffic through 6to4 gateways is easy but not necessarily optimal. Related issues are discussed in this section.
6to4 gateways are great
The performance and reliability of communications between 6to4 hosts and native IPv6 hosts are better than ever before; a good 6to4 gateway can sometimes outperform a mediocre link to a TunnelBroker.
If you are a beginner or a casual IPv6 user, 6to4 just might give you everything you need. It's not perfect but it does work. That said, if you find yourself using a 6to4 gateway frequently, you're probably going to want something better.
6to4 gateways are evil
Two sites which are both running 6to4 can communicate via IPv6 encapsulated directly over the IPv4 Internet. This type of communication will almost always provide the best possible performance. Similarly, two sites which are both using TunnelBroker configurations can usually communicate effectively over the IPv6 Internet. In counterpoint, two native IPv6 sites might be capable of even better IPv6 performance than 6to4 sites, although they face another set of challenges when trying to reach the IPv4 Internet.
These examples all optimize performance by avoiding the use of 6to4 gateways; traffic is always directed over a consistent path. When using a 6to4 gateway, your router is sending IPv4 packets to a magic anycast address, which is eventually picked up by a router and transformed into an IPv6 packet.
Unless you specify a 6to4 gateway explicitly, there is no guarantee of any consistency in the routes your traffic will take. The opposite sequence occurs for each packet sent back to you, once again using a different set of routes. Worse, it is even more difficult to specify the 6to4 gateway being used by the host you are communicating with, and even if you manage to do so, other problems can then result.
Address selection
[http://www.ietf.org/rfc/rfc3484.txt RFC 3484] defines a reasonable default address selection policy.
This policy does a couple of specific things we're interested in: 6to4 destination addresses are always contacted via 6to4 source addresses if possible, and native IPv6 destination addresses are always contacted via native IPv6 source addresses if possible. The idea is to take full advantage of 6to4 support when it is appropriate, and avoid it entirely when it is not appropriate.
Unfortunately, software implementations of RFC 3484 tend to be incomplete. Any report of a complete, successful implementation would be appreciated...
Links
CategoryGlossary CategoryDocumentation CategoryEducation CategoryNetwork CategoryDamnYouKeegan