.
![[ Powered by Fedora Core ]](/icons/powered_by_fedora.png){kind=icon}
This is a quick HOWTO for bringing up an ipv6 tunnel under FC6 (Fedora Core 6). There is some good background reading in /usr/share/doc/initscripts-*/, but those notes are incomplete. This HOWTO is meant to fill in the gaps. (Note: Fedora 7 is now out and this is the companion F7 IPv6 HOWTO.)
First one needs to create a new ifcfg file for the tunnel interface "sit1" (/etc/sysconfig/network-scripts/ifcfg-sit1). Do not use "sit0", that interface is already assigned to a different task. If your ISP assigns you a /48 IPv6 net-block you should reserve one of the /64 nets for your internet-facing sit1 address. The other nets can be reserved for routing to your internal ethernet, if you have one.
If your ISP assigns you two IPv6 addresses for the IPv6 tunnel itself but these addresses don't have a valid rDNS (reverse DNS) then you are probably best off trying to ignore them. The tunnel addresses are not strictly needed unless you are running OSPF, RIPNG or some other routing protocol. It is highly unlikely that any home user with only one network connection needs to (or will be allowed to) supply link and network status to their ISP using these protocols. The disadvantage to using any broken assigned tunnel endpoints is that IPv6 connections from your tunnel machine will show up as coming from an anonymous IPv6 address with no hostname associated. If you've ever tried to send email or ftp from a machine with no hostname in DNS you already know why one doesn't want to do that. (The remote machine will most likely reject your connection and tell you to fix your forward and reverse DNS entries before trying again.) This advice, of course, assumes that your tunnel broker assigns you a /48 that either already has valid rdNS or lets you handle the rDNS for it via a DNS delegation. (If you don't understand this paragraph, don't worry that much. Correct hostnames are a nice thing to have but won't effect the IPv6 packets themselves. You can still test and run IPv6 without it setup correctly.)
# /etc/sysconfig/network-scripts/ifcfg-sit1 DEVICE=sit1 BOOTPROTO=none ONBOOT=yes IPV6INIT=yes IPV6TUNNELIPV4=XXX.XXX.XXX.XXX # the IPv4 addres of your ISP's tunnel server IPV6TUNNELIPV4LOCAL=XXX.XXX.XXX.XXX # your host's public IPv4 address IPV6ADDR=YYYY:YYYY:YYYY:0::1/64 # your host's public IPv6 address
Next, modify your main network config file (/etc/sysconfig/network) to include the missing ipv6 bits.
# /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=yes HOSTNAME=myhost.example.com # your host's name. (optional) IPV6_ROUTER=yes IPV6FORWARDING=yes # This doesn't work and ends up being redundant after our workaround. # IPV6_DEFAULTDEV=sit1
In theory, FC6 will automatically bring up this tunnel at boot time. In practice there is currently (as of 2007-5-11) a bug in the networking init scripts that prevents them from bringing up any sitN automatically. One has to manually type (or have some script execute) "ifup sit1" to bring up sit interfaces. I added some lines to the end of /etc/rc.local to do this for me in case the computer ever reboots when I'm not around.
This addition to the end of /etc/rc.local checks if the tunnel interface "sit1" came up correctly and if not brings it up "by hand". This is only needed until Fedora fixes the networking init scripts. It shouldn't hurt anything once they do fix the problem.
# tail end of /etc/rc.local # # sit1 doesn't seem to come up correctly, give it a kick if needed. # We need to do this with an external script, since any errors # in this rc.local seem to abort the whole scripts execution. # This causes problems with the "ifconfig sit1" test. /usr/local/sbin/sit-bringup # # end #
This is the script that does the work for the above rc.local. This file should be mode 755.
#!/bin/sh
# /usr/local/sbin/sit-bringup
#
# sit1 doesn't seem to come up correctly, give it a kick if needed.
#
ifconfig sit1 > /dev/null 2>&1
if [ $? != 0 ]
then
logger -i -t rc.local "bringing up sit1 by hand"
ifup sit1
fi
#
# end
#
We need to add a default route so that our machine will know what to do with non-local ipv6 packets. The default route added by FC6 (::/0) is non-functional. One needs to add a slightly more specific route, a /3, before things start working.
# /etc/sysconfig/static-routes-ipv6 # adds routes through dedicated tunnel interface sit1 sit1 2000::/3 # end
Final touches: We need to add an anti-looping route for our unmapped networks. This file will add a route for the whole /48 assignment and send a "network unreachable" icmp6 message for packets addressed to any of our unused networks. Without this route, an attacker could easily chew up all of our bandwidth with a flurry of packets destined for one of these unused networks. Our machine would send these packets back to our default router (the ISP's tunnel server), which in turn would send the packet right back to us. The attacker could arrange for this packet to loop back and forth up to roughly 250 times. That would chew up 250 times more bandwidth on our side than it would chew up on theirs, so even an attacker with a slow connection could do quite a bit of damage. Unfortunately we can't add this route to the static-routes-ipv6 file above, since it won't let us specify the "unreachable" keyword. Linux also doesn't have any interfaces set aside for packet rejection, so we cant just route the unwanted packets to "rj0" as one can in some routers. This is the simplest way of making that unreachable route.
# /etc/sysconfig/network-scripts/route6-sit1 # # prevent routing loops by accepting all packets for # our ipv6 networks. Without it an attacker could use up all of our # bandwidth by sending packets to an unused network assigned to us and # have our machine and the upstream router repeatedly forward the # packet back to each other. # # "ip route add unreachable" for the whole /48 assignment. # This route is only used if none of the /64 entries in one's routing # table match. # # substitute our IPv6 /48 assignment for the placeholder YYYY's. unreachable YYYY:YYYY:YYYY::/48 # # end #
The default ip6tables that comes with FC6 is worthless. It assumes an attacker will be truthful in choosing the source port for an attack. Any attacker's packet coming *from* a port number that we also have open on our machine will be accepted, even if it is destined to a closed port on our machine. How dumb is that??? The file below is largely copied from the default filter file with every occurrence of the "--sport" lines removed.
You may comment out lines for services that you don't run or don't want exposed to the net at large. If you don't run an smtp mail server, you may comment out the "--dport 25" line. (Leaving it in won't really create any problems. It will just add a bit of clutter, which is normally frowned upon in security-sensitive files.) Similarly if you don't run a dns server comment out the "--dport 53" lines. For beginning sysadmins, it might be easiest to use the /etc/sysconfig/iptables file as a guide as to which services you need to keep open. The most important thing to remember is never use "--sport" as the only restriction in an ACCEPT rule. From a security standpoint, it is equivalent to accepting every packet.
# /etc/sysconfig/ip6tables # wsrcc ip6table. You may comment out lines for services # that you don't run or don't want exposed to the net at large. # eg if you don't erun an smtp mail server, comment out the # "--dport 25" line. # *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT # if you have an internal ethernet eth1 that you trust, uncomment # this next line to accepet packets from it unconditionally # -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT -A RH-Firewall-1-INPUT -p icmpv6 -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 8080 -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m udp -p udp --dport 123 -j ACCEPT # allow all traffic to ephemeral ports -A RH-Firewall-1-INPUT -m udp -p udp --dport 32768:65535 -j ACCEPT -A RH-Firewall-1-INPUT -m tcp -p tcp --dport 32768:65535 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-port-unreachable COMMIT
I'm feeling lazy, so I didn't yet write up the DNS setup info. Needless to say, you do need to make sure your forward zone file includes the AAAA IPv6 address records for your hostnames and your reverse zone file includes a mapping of your IPv6 addresses to the respective hostnames.
The radvd.conf file configures IPv6 autoconfiguring server. This server will tell any IPv6 clients plugged into the second, local ethernet NIC (eth1) what their address prefix (ie. the network part of their address) is. This will allow IPv6 clients to automatically configure themselves. As an added bonus if one has a bridged WIFI access point plugged into the local ethernet, one will also be able to autoconfigure any IPv6 WIFI clients.
# /etc/radvd.conf
#
# This file advertises part of our iv6 assignment to clients plugged
# into our second ethernet (eth1) or the bridged wifi also
# connected via that ethernet.
interface eth1
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix YYYY:YYYY:YYYY:0000::/64 # advertise net 0 of 65536
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
#
# end
#
This is an example eth1 file for an (optional) second local ethernet that we will route IPv6 packets to. In this way any IPv6 capable machine plugged into this ethernet will have full access to the IPv6 internet.
DEVICE=eth1
BOOTPROTO=none
HWADDR=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ # the MAC address (autofilled in)
DHCP_HOSTNAME=
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=no
IPADDR=XX.XX.XX.1 # our local network IP, usually 192.168.x.1
NETMASK=255.255.255.0
# ipv6 bits added by hand.
IPV6INIT=yes
IPV6ADDR=YYYY:YYYY:YYYY:0000::1/64 # our first ipv6 network. Same net
# as radvd above.
# end
If you get service from a US telco or cable company, forget it. These folks usually can't even be bothered to get the rDNS (reverse DNS) entries for their mail servers right. Don't expect them to even know what IPv6 is, no less provide it. Your best bet is to find a kindly IPv6 tunnel broker. In the past he.net (Hurricane Electric) and IIJ have provided such services to WSRCC. Currently we have Service from the next 5 tunnel brokers below. Thanks guys!
My ISP, Sonic.net, offers DSL services, mostly around the San Francisco area. They also offer a free IPv6 tunnel server for their customer's use. The one weirdness is that they only assign a /60 net instead of the recommended /48. (IPv4-think is hard to break, I guess.) Sonic customers using one of their /60 assignments will need to change all the /48 occurrences above to /60. Sonic also doesn't provide rDNS on the two IPv6 tunnel addresses. For this reason it is best to not configure the tunnel using these addresses.
Sixxs offers standard IPv6 over IPv4 (protocol 41) tunneling. Setup of this second tunnel was identical to the setup for the first one (only using sit2 instead of sit1). Sixxs has a performance-based system that requires you to keep the tunnel up and running for a week or two before they give you a /48 assignment. They also have an extensive set of web-based forums for helping ipv6 users get up to speed. Check them out even if you don't need a tunnel from them.
Hurricane Electric (aka he.net / tunnelbroker.net) also offers standard IPv6 over IPv4 (protocol 41) tunneling. Setup was identical to the two above tunnels (except for using sit3).
Dolphin (aka as8758.net) also offers standard IPv6 over IPv4 (protocol 41) tunneling. Setup was identical to the three above tunnels (except for using sit4). Dolphin does require you to use their web page to renew the tunnel each month.
British Telecom (aka Bt.net / btexact.net) also offers standard IPv6 over IPv4 (protocol 41) tunneling. Setup was identical to the four above tunnels (except for using sit5). BT does require you to pass traffic over the tunnel each month in order to renew it.
Obviously, one only needs one of the above tunnels. The only reason I setup more than one was to test the connectivity from the various tunnel-brokers.
Go6 (aka hexago.com) does not appear to support the OS's normal infrastructure for running the IPv6 over IPv4 tunneling. They require you to run their proprietary client to get connected. The client does come as source code, but has some non-GPL non-BSD license. WSRCC will not be testing any nonstandard/proprietary solutions.
Earthlink also seems to require one to run their proprietary tunneling client. WSRCC will not be testing this one either.
Singnet in theory offers IPv6 tunnel service with sign-ups via their web server. Errors in the signup part of the web pages causes Firefox/Mozilla to display the web pages as HTML source. This is not very encouraging.
See other tunnel broker lists at the Wikipedia, Google Directory.
If there are other ISP's or tunnel brokers I should be listing here please send mail to my gmail address below. I'll add them here.
Once you have your IPv6 set up the question is how to test it? Well, there is a nice list of approximately 150 IPv6 accessible WWW servers at the University of Leipzig courtesy of their IPv6 statistics counter. If you run a WWW server and want the IPv6 to be listed just add this code to one or more of your web pages (with the URL=www.wsrcc.com edited to reflect the your WWW server's preferred name).
<a href=
"http://6bone.informatik.uni-leipzig.de/ipv6/stats/stats.php3">
<img width="88" height="31" src=
"http://6bone.informatik.uni-leipzig.de/ipv6/stats/log.php3?URL=www.wsrcc.com"
alt="IPv6 Ready" /></a>
FC6 also has a provision for using the automatically configured 6to4 (RFC-3056) style tunnels. The advantage of these tunnels is that one doesn't need to pre-arrange anything with a tunnel broker. The IPv6 address is generated algorithmically from the IPv4 address and the far end doesn't need to configure anything. To configure this type of tunnel one simply adds "IPV6TO4INIT=yes" to /etc/sysconfig/network-scripts/ifcfg-eth0. There is no need to create any ifcfg-sit1 file. Instead of "sit1" in the /etc/sysconfig/static-routes-ipv6 file, one uses the interface name "tun6to4". One then needs to add the IPv6 network prefix to the various other config files from above. The simplest way to do that is to bring up the tunnel and cut-and-paste the IPv6 address from the tun6to4 interface. Remember the IPv6 0-th /64 network (XXXX:XXXX:XXXX:0000::/64), is already spoken for by the tunnel interface. If you need to route IPv6 to a local ethernet, use XXXX:XXXX:XXXX:0001::/64.
Unfortunately the tun6to4 interface initialization is also broken under FC6 (as of 2007-05-25). This interface's bringup will throw an error during initialization and you have to do an "ifdown eth0; ifup eth0" in order to bring up the tunnel. A further bug appears to cause all IPv6 routes over this 6to4 tunnel to be less preferable than IPv4 routes. It isn't clear why this is happening. Old style sitN static tunnels cause programs to prefer IPv6. Auto 6to4 tunnels cause the programs all to prefer IPv4. It is probably best to avoid this type of tunnel till both of these issues are fixed.
.
wolfgang.rupprecht+web@gmail.com
(Wolfgang S. Rupprecht)
WSRCC Home Page || Up One
Level
..