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!

IPv6 Only Domain Controllers:

The installation didn’t cause any trouble but after initially logging on and running a DCDiag we see this:

It turns out that the install of the DNS Server had set the NIC’s properties to be ::1 but the DNS Server was only listening on the Static Site Local address FEC0::2 and its self assigned Link Local. This of course caused all DNS reliant checks to fail and cause a whole world of pain.
 
 
 
 
 

Changing the NIC DNS properties to FEC0::2 resulted in a different set of errors:

There were actually 10′s of the System Log errors which made me panic for a bit till I remembered that this is expected behaviour. The expected behaviour is that if there are any Warnings or other bad apples in the Event logs DCDiag will throw some unfriendly errors.

These errors appear to be even more unfriendly owing to a bug in how the Event Viewer copes with IPv6 address.
 
 
 
 
 
 

A quick purge or the Event logs later and we are back in business:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Preparing the Exchange Server

Exchange 2007 has several prerequisites that need to be installed before Setup can be successfully launched. First I’ll add the prerequisites that don’t affect / require a machine to be bound to a domain, if they install correctly then I’ll bind it to the domain (and see how that goes) and finish off with the prerequisites that require a machine to be bound to the domain.

Installing the non-domain related roles / features went smoothly:

 
 
 
 
 
 
 
 
 
 
 
 
Unfortunately binding to the domain was not as smooth:

The first issue to resolve is whether Windows Server 2008 actually wants a A record or whether someone just hasn’t got round to updating the error dialog.
 
 
 
 
 
 
 
Firing up the NSLookup tool we see that [despite some timeouts (??)] DNS is working as expected. Although this was evident because the SRV lookups for the domain resulted in the name of the Domain Controller.

 
 
 
 
 
 
 
 
So I did what every curious Windows Admin knows might fix the problem, do it again. And who’d have guessed it?

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Hmm, well with that sorted and following a quick reboot its time to see if the final prerequisite piece of the puzzle works:

Excellent!

There are a few errors but these may not be show stoppers.

Onto the next stage!
 
 
 
 
 
 
 
 
 
 

Installing Exchange 2007 on an IPv6 Only 2008 Server

Well unfortunately we’ve stumbled at the first hurdle:

 
 
 
 
 
 
 
 
 
 
 
 
 
The link the error mentions tells us the following:

IPv6 is only supported in Exchange 2007 SP1 when it is installed on a Windows Server 2008 computer that has both IPv4 and IPv6 enabled. If you disable the IPv4 protocol, Exchange 2007 SP1 can't support IPv6.

Well screw that, the Install button hasn’t greyed out so onwards to Victory!

 
 
 
 
 
 
 
 
 
 
 
 
 
Setup claims to have installed, lets see if the SMTP element is contactable:

 
 
 
 
 
 
 
 
 
 
 
 

Using Exchange 2007 in a Native IPv6 Environment

OWA worked without any major hassles and sending internal email worked fine. Unfortunately trying to send email to an ‘external’ host resulted in a “451 4.4.0 DNS Query Failed”.

Looking through the Event Logs I found this:

 
 
 
 
 
 
 
 
 
 
 
Running the suggested powershell command did indeed show that no DNS Servers were set:

 
 
 
 
 
 
 
 
No matter what I did using netsh or the NIC GUI the error remained, I resorted to setting the DNS entries in the Hub Transport server properties:

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
We now get another error but hey at least its progress:
451 4.4.0 primary target IP address responded with "421.4.4.2 unable to connect."attempted failover to alternate host, but that did not succeed.Either there are no alternate hosts, or delivery failed to all alternate hosts.

Turns out I forgot to make the Postfix server listen on its IPv6 address :/ A few quick config changes later and Victory is mine!

 
 
 
 
 
 
 
 
 
 
 

Conclusion

Well its a bit painful to get going but it appears to work once setup. I’ll keep this going with some scheduled in and out email to see if it dies after a week or so.

Armed with a [now depreciated] netblock I set about the practise run for the Plan O’ Doom.

Configuring the scopes is easy and so doesn’t really need to be covered but in order to split my /48 [SixXS subnets are /48] into more usable subnets I cheated on the calculations and used Rhys Koedijk’s IPv6 Subnet calculator.

A word of caution, despite setting up the Scopes and binding static IPv6 addresses on the relevant interfaces the clients were not getting any leases because the Interfaces on the relevant subnets were not configured correctly. You will need to run the following command to get leases working:
netsh interface ipv6 set interface advertise=enabled manageAddress=enabled












Unfortunately a day later I had a quick look at the leases on my ‘test’ subnetwork and was greeted by the following:

Thinking that this could be due to my previous experiments I deleted the leases and then logged onto each machine that should have IPv6 enabled and did a release6 & renew6.

Unfortunately there was still one left:















A.J. Anto has an old post which details why these BAD_ADDRESS’s should be showing up but that doesn’t seem to be the case here.

A bit more research found a Hyper V’d Vista machine that I’d forgotten about which had a 12 day lease.

Interestingly even if you assign a static IPv6 address to an interface Windows Server 2008 (and probably Vista too) still request an IP from DHCP:










The next IPv6 experiment is a SixXS tunnel to a Juniper Netscreen 5GT with the LAN and Wireless segments having ‘real’ IPv6 addresses. – Keep an eye out for the “NetworksAreMadeOfString IPv6″ SSID.