IPv6 with Tunnel Broker Configuration Example
From DocWiki
Common info
Tunnel brokers are something that you can put into the "tunnel destination" command on your config, and have the IPv6 working.
Do not try to split the /64 that they give originally - it most probably would not work! They give out the /48s for the purpose of putting the real devices on them.
The basic config using IOS is the same for both tunnelbrokers, here it is (taken from SixXS FAQ and modified to add the basic firewalling part):
ipv6 unicast-routing ipv6 cef ipv6 inspect name V6-INSPECT tcp ipv6 inspect name V6-INSPECT udp ipv6 inspect name V6-INSPECT ftp ipv6 inspect name V6-INSPECT icmp ! interface tunnel0 description IPv6 uplink to SixXS / HE no ip address ipv6 enable ipv6 nd suppress-ra (<12.4) ipv6 nd ra suppress (>=12.4) ipv6 address [Your IPv6 Endpoint]/[Prefix Length] ipv6 mtu 1280 (or other MTU value, depending on what you configured the tunnel to) tunnel source [Your IPv4 Endpoint or 'dialer' interface] tunnel destination [PoP IPv4 Endpoint] tunnel mode ipv6ip ipv6 traffic-filter V6-FILTER in ipv6 inspect V6-INSPECT out ipv6 virtual-reassembly ! ipv6 route 2000::/3 [PoP IPv6 Endpoint] ! ! Some folks filter some ICMPs here. ipv6 access-list V6-FILTER permit icmp any any deny ipv6 any any log !
SixxS
For SixXS, the IOS should work either with "static" or "heartbeat" type tunnels. They have a funny point scheme, whereby they take away your points for changing the tunnel type - so in the end you might not have enough. If you are 100% sure you have the fixed IPv4 address - then you can pick "static" when requesting. Else - take the "heartbeat" one - you can use it with either static or dynamic IPv4 endpoint. The config is as per above.
The tricky part is who is going to send the "heartbeat" described in the draft
Luckily they publish a sample shell script that does this, albeit it has a little bug ("-c" in the argument of netcat) that cost me 30 points in debugging mistakes before I figured it out :-)
Here's a bug free version:
#! /bin/sh
# written by Oliver Walter <owb@gmx.de>
localv6="$1"
password="$2"
remotev4="$3"
remotev6="$4"
while [ 1 ]
do
hb="HEARTBEAT TUNNEL `echo -n $localv6|cut -d '/' -f 1` sender `date +%s`"
echo -n "$hb `echo -n $hb $password|md5sum|cut -d ' ' -f 1`"|netcat -w 1 -u $remotev4 3740
ping6 -s 8 -c 1 -q $remotev6 >/dev/null 2>&1 &
sleep 60
done
As they point at the Heartbeat page - your clock has to be NTP-synced, as they have pretty stringent requirements for it, and will drop the heartbeat packets otherwise.
(Still open question: where to find the heartbeat password - it is not the same as your login. I'll put something here if I hear from the SixXS folks). Or if you find it - edit it here in-place.
Once you start the heartbeat, your tunnel will automagically come up.
Hurricane Electric
Same setup as on the SixXS for the IOS 'forwarding' part. Their way to update your endpoint is different:
Please use the format "https ://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$IPV4ADDR&pass=$MD5PASS&user_id=$USERID&tunnel_id=$GTUNID" Where: $IPV4ADDR = The new IPv4 Endpoint (AUTO to use the requesting client's IP address) $MD5PASS = The MD5 Hash of your password $USERID = The UserID from the main page of the tunnelbroker (not your username) $GTUNID = The Global Tunnel ID from the tunnel_details page
NB: I have added the space after 'https' to prevent the auto-linkage of the nonsensical URL by the wiki. You obviously should not have the space. Also, HTTP (not "HTTPS") seems to work for now too.
Basically, if you use "AUTO" in place of IPv4 address (and you are requesting from behind your router - so your source IPv4 address will be the same as the one assigned to you) - then to update the address, you just need to retrieve a statically computed URL, specific to your tunnel. Obviously do this only when the address changes.
I suspect for this the dynamic DNS support in IOS should work pretty well - but did not test it since I have not enough memory on my home box to use the software that supports the dynamic DNS.
