With the initial tests over it was time to actually move over to ‘real’ IPv6 addresses.

After applying for a tunnel from SixXS it was time to set it up. Unfortunately none of my JUNOS or Cisco IOS images have IPv6 support so rather than buying another 2600XM I decided to use the Windows Server 2008 server that performs IPv6 DHCP as the router.

The advice for setting up a tunnel on the Wiki only covers up to Windows Server 2003 and is below:

netsh interface ipv6 install
netsh interface ipv6 add v6v4tunnel SixXS [Your IPv4 Endpoint] [PoP IPv4 Endpoint]
netsh interface ipv6 add address SixXS [Your IPv6 Endpoint]
netsh interface ipv6 add route [Tunnel Prefix]/[Prefix Length] SixXS
netsh interface ipv6 add route 0::/0 SixXS publish=yes


The first line is redundant as IPv6 is already installed on 2008, the second to last command results in a warning that the object already exists and the last command needs to be:

netsh interface ipv6 add route ::/0 interface=SixXS nexthop=[PoP IPv6 Endpoint] publish=yes


In order to ‘prove’ your tunnel is alive it has to be pingable the advice on the SixXS site is to run the following command:

netsh firewall set icmpsetting SixXS enable all


Unfortunately Windows Server 2008 now has the ‘Windows Firewall with Advanced Security’. In order to allow pings you need to set the ‘Public’ profile to allow “File and Printer Sharing (Echo Request – ICMPv6-In).
You could add your own rule for ICMPv6 (Protocol type 58) but this was the easiest option at the time.
 
 
 
 
 
 
 
 
 
 
 
 
With all that done we now have an IPv6 (in IPv4 tunnel) up and running on Server 2008:

 
 
 
 
 
 

Windows Server 2008 – IPv6 Routing

To get packets moving through the network you need to configure forwarding on both interfaces. Then on the internal interfaces (the SixXS side of the Network has a static route) enable advertising which will help IPv6 enabled hosts to configure their routes. Once this is done the interfaces should look like this:
WAN [Tunnel] Interface

 
 
 
 
 
 
 
LAN [Internal] Interfaces
 
 
 
 
 
 
 

Its now time to see if all this is working, a quick renew on a machine on the LAN and we see this:

 
 
 
 
 
 
 
 
The first thing that struck me about that output is that the Default Gateway is a Link Local address. It turns out that for indirect delivery of packets (in which the destination is not on a local link) the next-hop address is typically the link-local address of the neighboring router.

Trusting that the Autoconfiguration has done its thing I fired off a traceroute and it works!

 
 
 
 
 
 
 
 
As a quick check I disabled the Firewall on the test box and it was publically available (which is good) but then leaving the local firewall disabled I added a rule on the Router to block ALL IPv6 packets but it carried on pinging which is because the Windows Firewall with Advanced Security is only for the Host itself not forwarded interfaces.

So how do I protect my precious IPv6 beer fridge from attackers?

Windows Server 2008 IPv6 Tunnel Security

I went through the Microsoft Press Understanding IPv6 book, hammered the hell out of my ? key in the netsh environment and then just as I started to read the Technet netsh command reference (is stubborness a virtue?) I remembered that you can add filters to any interface within netsh once the RRAS role feature has been installed!

Unfortunately even with the RRAS role features installed Windows still couldn’t address the SixXS tunnel. So, I bit the bullet and decided to secure the Network a different way.

Even though I can’t stop packets coming in from the SixXS tunnel I can prevent them getting forwarded to interfaces. The following netsh commands block all packets except pings, those that originate from the LAN or are for port 80:

set filter name="LAN Zone" filtertype=OUTPUT action=DROP
add filter name="LAN Zone" filtertype=OUTPUT srcaddr=:: srcprefixlen=0 dstaddr=:: dstprefixlen=0 proto=ICMP type=255 code=255
add filter name="LAN Zone" filtertype=OUTPUT srcaddr=:: srcprefixlen=0 dstaddr=:: dstprefixlen=0 proto=TCP srcport=0 dstport=80
add filter name="LAN Zone" filtertype=OUTPUT srcaddr=2a01:348:18e:1:: srcprefixlen=64 dstaddr=:: dstprefixlen=0 proto=ANY
set filter name="LAN Zone" fragcheck=disable


This is by no means perfect so I’ve subsequently added a lot more rules to the router. (No port scanning please, the text message sound for netflow alerts is rather jarring!)

Conclusions

IPv6 is an exciting new area to explore, the IPv6 Internet isn’t quite there yet (IPv6 sites are still few & far between) but it is nice to see applications out there and its a refreshing change to not have to worry about NAT.

With Christmas fast approaching I think I’ll reward myself with a shiny ‘new’ 2600XM with the IPv6 stack to handle the routing between my various zones and an ASA or two for the LAN segment. If I do then I’ll probably do another quick follow up regarding IPv6 subnetting, experiences with the Cisco IPv6 stack and whatever else I’ve stumbled upon in the mean time.

Interesting Notes

During the course of this little experiment I found a few random quirks that might amuse:

• The Windows Server 2008 DHCP Server can bind to a 6 in 4 tunnel but the DNS Server cannot!
• A very petty observation but theres a typo in the Interface Properties!