This is an old revision of the document!
The following article is intended more as personal write up on the deployment, the experiences we had with it and the discussions, it also gives a hint about the future there, although as usual, the future is… future :P
The first test deployment we did involved basically setting up a tunnel endpoint on the router so we could try IPv6 from there. Back then the router was a repurposed desktop Pentium 4 with 3 Fast Ethernet interfaces on which we installed Gentoo Hardened.
The idea behind it was testing a few things:
Once that was done the thing amounted to picking a 6in4 provider. We chose Hurricane Electric for their niceness and because I had been using them at the xiscosoft network for some time over SixXS with whom I have already had some trouble.
So well, I registered the account for GbgHackerspace and did the tests so I could enable IRC passthrough (which is an important service for us).
The tests were (as you can suppose) very successful. We discovered we needed to enable icmp ping traffic to the router Internet address to register the tunnel (as we were on this we enabled it too for icmpv6 as it simplifies network checking). We also discovered that protocol 41 packets may be dropped at times even if using a ESTABLISHED,RELATED catch all rule so we allowed them to pass through when coming from our tunnel remote endpoint,
Finally I had to set up a small script that would update the endpoint ip address on Hurricane's server as we had a dynamic IP address then, I made it to run every 5 minutes in a cron job, although I was considering setting it up as a dhcpcd hook so it would be called automatically when our ip was set by Bredbandsbolaget's DHCP server.
Once this was done, it was time to do the testing. The tests we made (ping6, wget -6, Gentoo portage tree syncs and even running a znc server) were quite successful and worked as well as we expected over a few weeks, so with this, we were ready to deploy IPv6 on the whole Hackerspace network.
One of the problems we had was that the line we installed provides 250/100 connectivity over a gigabit ethernet line to the router. We had prepared for this and both the core switch and the wireless APs we set up support both IPv6 and Gigabit Ethernet, but our router has only Fast Ethernet Interfaces (before getting the line with Bredbandsbolaget we were using a 3G modem so we didn't need more) and the replacement was not going to come any time soon. But then, an anonymous person (we keep him anonymous for obvious reasons) came with a procera packetlogic pbs (with a nice Silicom card with two bridgeable gigabit ethernet ports and stuff).
The Procera box has some fun problems, the first is that it refuses to start up (unless you short the power pin in the powersource) unless you have something connected on the administrative LAN. The second is that the Silicom cards aren't supported by recent kernels (trying to integrate their GPL drivers with the original ones is on my TODO list). The third is that it takes a long time to boot thanks to its SCSI card. But well despite all we installed Gentoo Hardened on it and it seems to work well so far, although having to connect to a Raspberry PI to access the Serial port is a little bit painful.
Once we had installed Gentoo Hardened on it and migrated the tunnel config, the dnsmasq config and the network config (and figured out some strange problems involving Netgear's Green Ethernet support) we got the whole thing working with dynamic IPv4 addresses.
Since we are using /16 private pools assigned based on MAC addresses lease conflicts weren't a big problem and after fixing some minor problems with the firewall, the house made initrd and damned udev we got the thing up and working and did a seamless handover.
My original intention was setting up a completely unfiltered (other than port 25 done by Hurricane by default) network so people on the Hackerspace could easily connect to whichever IPv6 they wanted to set up from the outside. Thus as the planning was deploying full IPv6 by 17 of February I announced this into the appropriate medium so people could set up their firewalls to filter ipv6 traffic too if they hadn't already done so.
Of course things didn't go as planned and this basically sparked a big discussion over how networks should have opt out security and a fight for the providing a secure by default implementation. The discussion delayed us as we tried to reach a compromise solution and after some more discussion we agreed on the following implementation:
Sadly our access switches aren't managed so we can't use 802.1x to provide VLAN assignment at port level nor do so based on the device MAC address. But as you can expect, I'm going to separate the secure VLAN used for WLAN devices from the one used for cabled devices as we do with the other networks so they can't directly see each other, if you want security you get it with all its consequences so if you want to be able to see wireless devices directly or you need to have an internal name assigned to your device you go to the unsecure network which was planned with hacking in mind and not with the idea that users would be kids needing to be protected from themselves.
Well that's mostly it for the ranting, so back to technical stuff on the 20 we did the deployment.
As said we did the deployment later, basically we have dnsmasq running on the router providing appropriate IPv4 addresses depending on the device being used and providing also DNS caching services, so it was only logic to also use it for RA and DHCPv6 services too. The setup was quite easy and just required to add a single line to add support on the hackerspace VLAN:
dhcp-range=tag:lan.40, 2001:470:dc07:40::1:0, 2001:470:dc07:40::1:ffff, slaac, ra-names, 64, 15d
Finally I had to update the ip6tables FORWARD table to add connection filtering (I allowed ping though as it can be useful for testing). The relevant parts of the tables as it's now looks like this:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 Internet_fwd_in all he6 * ::/0 ::/0 0 0 Internet_fwd_in all in1 * ::/0 ::/0 Chain Internet_fwd_in (2 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all * * ::/0 ::/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 128 0 0 DROP all * * ::/0 ::/0
You probably can notice that two interfaces (he6 and in1) are affected. he6 is the tunnel interface and needs to be firewalled as the Internet ipv6 traffic is expected to come from there. The reason why in1 (Bredbandsbolaget connection) is filtered too is that they may decide to provide IPv6 connectivity at some point of time and I don't like the idea of people being able to access our systems in that way.
But of course deployments usually come with problems, in this case I thought I had set up IPv6 routing on the machine but I hadn't done so. After looking around in the sysctl (as the option wasn't documented on the sysctl.conf file) I found the required option and enabled it. The IPv6 related sysctl now looks as follows:
#Config for ipv6 routing # Enables packet forwarding net.ipv6.conf.all.forwarding = 1 net.ipv6.conf.default.forwarding = 1 #Disable ipv6 autoconfiguration net.ipv6.conf.all.autoconf = 0 net.ipv6.conf.default.autoconf = 0 #Except on in1 (Internet interface) net.ipv6.conf.in1.autoconf = 1 #Disable source routes before they byte us (pun intended) net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.default.accept_source_route = 0 #Disable redirects to avoid MITM (at least for now) net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0
And with that IPv6 came to life and started working, I'll report on any issues we find on the way and update this page.