Black Raven Dragoons

[Zancarius]

I know we have some techie types in-guild, and since I'm something of an advocate for IPv6 I'd like to direct your attention here:

http://www.tunnelbroker.net/

Tunnelbroker is Hurricane Electric's free (as in beer) IPv6 tunnel with a large number of servers around the globe. It's also quite fast. If you've been interested in trying out IPv6 and want to be a part of the IPv6 Internet (and your ISP isn't offering IPv6 access quite yet), this is a great way to get started. Hurricane Electric has instructions posted for almost every OS out there, so it should be relatively easy to get up and running.

Bear in mind that this depends largely on how you connect to the Internet. If you're currently behind a NAT at the ISP level (such as Large-Scale NAT), you won't be able to use the tunnel. Furthermore, some routers may cause you grief either because they don't support forwarding IPv6 packets (most only forward IPv4 packets) or because they lack configuration facilities that allow you to perform certain activities. You do essentially require a direct means of connecting to the tunnel endpoint hosts, and for some routers that probably means using the DMZ (dangerous!). The good news is that routers supported by the DD-WRT replacement firmware can be used to to connect to a tunnel endpoint, and you can configure them to hand out IPv6 addresses to any machine on your network, typically via autoconfiguration. DHCP6 support is still pretty flaky.

I'm a Gamer, WTF does this matter to me?

It doesn't matter right now because IPv6 tunnels currently use 6-in-4 encapsulation which serves to reduce throughput slightly and increase latency. However, when IPv6 finally rolls out, you won't need to configure port forwarding under a properly configured IPv6 network.

Yes, that's right. Port forwarding will ideally become a thing of the past. All IPv6-capable hosts will be able to connect directly to the Internet without using NAT, and this means that neither you nor your friends will need to jump through hoops to get your favorite games working.

The downside is that your machines will still need a firewall, or at the very least, you'll need a firewall at the network boundary.

Why do we need IPv6?

Because of this. By next summer--possibly before--all IPv4 address ranges will have been allocated. No new ranges can be created. Period. In other words, the Internet as we know it will have immediately become a much smaller place. New organizations will have to wrestle away addresses from established ones, and a whole host of broken solutions will crop up--and none of them will solve the fundamental problem. If we don't switch to IPv6 soon, we risk placing ourselves in an uncomfortable situation where every single one of these interim solutions is progressively worse and the cost to switch becomes much more expensive. Not all hardware is capable of IPv6, either, which means that the sooner the eggheads at network operation centers worldwide come up with a migration plan, the more prepared we'll be for IPv4 exhaustion. The plus side is that most software doesn't need to change--as long as you're at least running Windows XP or some fairly recent version of Linux/Unix/Mac OS X, you have support for IPv6. (You do need to add the adapter for XP, however.)

Of course, the ideal is that you won't notice when the day comes that the Internet finally switches over to IPv6. It should just work.

What is IPv6?

IPv6 is a new 128-bit addressing scheme for Internet addresses along with a few other extensions to the current (antiquated) IPv4 protocol such as autoconfiguration and autodiscovery, fundamentally better multicast support, and more (though comparatively unimportant) features. The most important aspect of IPv6 is that it introduces 2^128 addresses or 3 followed by 38 zeros. That's about 667 quadrillion addresses for every square millimeter on the planet. Or, to put it another way, there's enough addresses in IPv6 to travel from here to Andromeda (about 2.5 million light years away) fifteen thousand quadrillion times or 1.5x18^19--or if every address were a mile, there'd be enough to go from one end of the universe to the other more times than I have fingers to count with. It's a really big number. Compared to IPv4's 2^32 addresses (~4.2 billion), it's decidedly very huge.

IPv6 addresses look a little different from their IPv4 counterparts. IPv4 addresses, as you may be familiar with, have the notation xxx.xxx.xxx.xxx--or four octets, expressed in decimal notation, separated by dots. By virtue of this addressing scheme, sites like google.com might resolve to 66.102.7.99. IPv6 changes this around and separates each group of two octets with a colon such that an address might look like 2001:470:d:407:f1f7:4b4:bd4:35d1 (that's my workstation's current IPv6 address obtained via autoconfiguration). However, unlike IPv4, IPv6 addresses can also be condensed if they contain one or more leading zeros for each octet, so my workstation's current address could also have been written as 2001:0470:000d:0407:f1f7:04b4:0bd4:35d1. It gets more complex if you wind up with an address like 2001:0470:000d:0407:0000:0000:0000:0001, because compressing the address will remove all inner zeros, replacing them with a double colon, thus transforming the address into 2001:470:d:407::1 instead.

Confused yet? If you are, that's normal. IPv6 isn't vastly different from IPv4, but it's a big enough implementation change that it takes time to learn. But basically--the days of being able to memorize a handful of IP addresses are gone. Oh, and good luck telling your friend over the phone what your address is. "Sure, it's--hang on, got some paper? It's 2c01:77:ba:cc0d:101:87d:33c1:a11b. No, no. c-c-0-d. 'D' as in 'delta.' No, 'C' as in 'charlie.' Two of 'em. Yes, then a colon. No, not after the 'C'. It's after the 'D'. Ugh. Can I just e-mail this to you?"

One humorous side effect with having (visible) hexidecimal in address ranges is that you can do funny things with them. I've assigned the address 2001:470:d:407:0:baad:beef:cafe to one of my domain names, for example. See if you can spot the pun.

[Grimblast]

</nerdrant>

I'm Turus, and I approve this message!

[Zancarius]

I hate to bump an old post, but Sno successfully got IPv6 working on his router (he used the DD-WRT replacement firmware), and it works great:

Code: Select all

[sagittarius:~]$ ping6 -c 1 2001:470::[REDACTED]
PING 2001:470::[REDACTED](2001:470::[REDACTED]) 56 data bytes
64 bytes from 2001:470::[REDACTED]: icmp_seq=1 ttl=57 time=172 ms

--- 2001:470::[REDACTED] ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 172.127/172.127/172.127/0.000 ms


(For privacy's sake, I have redacted the entirety of his IP address except for the Hurricane Electric prefix.)

172 ms isn't bad for pinging through a tunnel over IPv4, to his IPv6 endpoint, and back!

[Zancarius]

If you're going to give DD-WRT a try, here's what eventually worked for Sno. Make sure to swap in the appropriate addresses:

Code: Select all

iptables -I INPUT -s 66.220.2.74 -j ACCEPT # This is only for HE's probe server to determine if you're reachable.
iptables -I OUTPUT -d 66.220.2.74 -j ACCEPT
iptables -I INPUT -s 209.51.161.58 -j ACCEPT # Swap this IPv4 address with the SERVER IPv4 ADDRESS
iptables -I OUTPUT -d 209.51.161.58 -j ACCEPT # Same

insmod ipv6 && sleep 2 # Sleep here to ensure the module has been added to the kernel

# You'll need to swap out YOUR_IPV4_ADDRESS with your public IPv4 address.
# Replace 209.* with the SERVER IPv4 ADDRESS HE gives you.
ip tunnel add he0 mode sit remote 209.51.161.58 local YOUR_IPV4_ADDRESS ttl 255

ip link set he0 up

ip addr add CLIENT_IPV6_ADDRESS/64 dev he0
ip route add ::/0 dev he0
ip addr add ROUTED_SLASH_64_ADDRESS/64 dev br0

Note that the Tunnelbroker CLIENT_IPV6_ADDRESS is provided on the tunnel information page. The ROUTED_SLASH_64_ADDRESS is an address (that you pick) from the routed /64 pool HE has delegated to you. This may not be necessary, but I've found that you usually have to pick an IPv6 address from your routed prefix before routing IPv6 traffic. It's usually handy to set this to something like 2001:470:d:407::1 or similar. Obviously, you don't want to use that address, because that's my prefix, but you do want to pick something from the prefix delegated to you.

You can also enable radvd support for autoconfiguration and neighbor discovery. I would recommend enabling radvd after you have successfully configured your IPv6 connection and can ping IPv6 addresses (ping6 -c 1 ipv6.google.com). You can add this to your radvd.conf:

Code: Select all

interface vlan2
{
    AdvSendAdvert on;
    AdvLinkMTU 1280;
    MaxRtrAdvInterval 300;

    prefix YOUR_IPV6_PREFIX/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };


};

(But make sure to replace YOUR_IPV6_PREFIX with the "Routed /64" on your tunnel information page.)

You can then enable radvd:

Code: Select all

radvd -C /tmp/radvd.conf

And client systems on your network should begin to accept IPv6 addresses from the router.

There's a few scripts available on the DD-WRT site that provide automatic updates of your tunnel if you lack a static IP address. I've posted this exclusively to help anyone else who might want to try the firmware replacement themselves for the purposes of testing IPv6.

[Zancarius]

If you have a Gentoo box set up as a router, configuring it to automatically attach your IPv6 tunnel from Hurricane Electric is pretty easy. Be sure to use the instructions for "linux-route2" first just to verify that it works.

Once your IPv6 tunnel is working, edit /etc/conf.d/net and add the following (this assumes you have two network interfaces--if you don't, how can you be using it as a routing box?):

Code: Select all

# This configuration makes several assumptions:
#
# 1) You have your kernel correctly configured to support IPv6.
# 2) You have all the appropriate configurations set to enable your box to route traffic for your
# network.
# 3) Your EXTERNAL interface (the one with your public IPv4 address) is eth0
# 4) Your INTERNAL interface (the one with your non-routable IPv4 address) is eth1
# 5) You have iptables set up to filter traffic. If you don't, you can't blame me for mean people
# on the interwebs breaking your stuff.

# DHCP is typically in here by default depending on how you configured your network initially.
# If you configured your network statically, ignore this line.
config_eth0=("dhcp")

# Don't accept DNS, NIS, or NTP updates from the DHCP server. This is useful if you're running
# your own DNS and NTP server, and you don't want your ISP's DHCP server to provide these
# values for you.
dhcp_eth0="nodns nonis nontp"

# INTERNAL interface configuration. Notice that the IPv4 address of your internal interface
# must be supplied first.
config_eth1=(
    "192.168.0.1 netmask 255.255.255.0"
    "2001:470:1111:2222::1/64" # Replace this with an address in your routed /64 pool.
    )

# Replace 66.220.18.42 with the SERVER IPV4 ADDRESS.
# Replace PUBLIC_IPV4 with your EXTERNAL IPV4 ADDRESS.
iptunnel_he0="mode sit remote 66.220.18.42 local PUBLIC_IPV4 ttl 255"

# Dependency for the he0 interface; make sure eth0 is brought up first.
depend_he0="net.eth0"

# Replace this address with your CLIENT IPV6 ADDRESS.
config_he0=("2001:470:1110:2222::2/64")

# Replace this IPv4 address with the SERVER IPV6 ADDRESS.
# (optionally, using "::/0 dev he0" here may work instead; I don't
# recall specifically why I used the IPv6 server address)
routes_he0=("default via 2001:470:1110:2222::1 dev he0")

# Set device MTU.
mtu_he0="1280"


Similar to the DD-WRT configuration, if you want to enable autoconfiguration and neighbor discovery of clients on your network, install the radvd package:

Code: Select all

emerge radvd

Then edit the /etc/radvd.conf file to include this:

Code: Select all

interface eth1
{
    AdvSendAdvert on;
    AdvLinkMTU 1280;
    MaxRtrAdvInterval 300;

    prefix YOUR_IPV6_ROUTED_64/64
    {
        AdvOnLink on;
        AdvAutonomous on;
    };
};


(Replace eth1 with your internal interface and YOUR_IPV6_ROUTED_64 with the "routed /64" provided by the tunnel broker.)

There's nothing to stop you from putting your IPv6 stuff on your external interface, of course. It would probably work. I chose instead to segregate the network by keeping the IPv6 routables on a different interface from my external interface containing the tunnel endpoint. You don't have to do this; you could create an entirely different interface (eth2 perhaps?) to deal with IPv6 traffic instead.

These instructions should be adaptable to Ubuntu (server, not desktop--NetworkManager is a worthless piece of garbage) if you edit /etc/network/interfaces appropriately. Be sure to read the man pages.