I recently obtained a new router, a Mikrotik RB751G-2HnD and wanted to test the IPv6 capabilities in their operating system. My previous router, a Linksys Cisco WRT160N (revision 1) running DD-WRT had an issue where IPv6 connectivity would randomly die even though all routes and interface settings were correct.
Basic LAN connectivity
To test basic IPv6 operations (SLAAC, ND etc.) in the RouterOS operating system, I used a ULA range generated randomly from here.
This was simple as adding a “router” address to the bridge-local interface and setting it to advertise the prefix on that interface.
That is it. We now have basic inter-LAN IPv6 connectivity with stateless auto-configuration.
IPv6 Internet Connectivity
Just LAN connectivity is no fun so we bring in a HE 6in4 tunnel into the picture to give us access to the wider IPv6 internet. I added another tunnel to my tunnelbroker account with an endpoint in Toronto (my last tunnel had an endpoint in NYC; gotta get that low latency!).
This is actually the easiest part of the whole process, HE gives you most of the instructions:
/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=173.35.229.49 mtu=1480 name=sit1 remote-address=216.66.38.58
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:1c:96b::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:1c:96b::2/64 advertise=yes disabled=no eui-64=no interface=sit1
At this point, we have v6 internet connectivity on the router itself but not on the hosts behind it:
[admin@Overlord] > /ping 2600:3c03:e000:1f:feed:beef:70:babe
HOST SIZE TTL TIME STATUS
2600:3c03:e000:1f:feed:beef:70:babe 56 55 31ms echo reply
2600:3c03:e000:1f:feed:beef:70:babe 56 55 21ms echo reply
2600:3c03:e000:1f:feed:beef:70:babe 56 55 23ms echo reply
sent=3 received=3 packet-loss=0% min-rtt=21ms avg-rtt=25ms max-rtt=31ms
Now we need to advertise the routed prefix that HE gives us to the bridge-local interface (as we did for the ULA prefix). Voila! Devices in my network now have IPv6 internet connectivity:
Pinging google.ca [2607:f8b0:400c:c01::5e] with 32 bytes of data:
Reply from 2607:f8b0:400c:c01::5e: time=40ms
Reply from 2607:f8b0:400c:c01::5e: time=41ms
Reply from 2607:f8b0:400c:c01::5e: time=42ms
Reply from 2607:f8b0:400c:c01::5e: time=41ms
Ping statistics for 2607:f8b0:400c:c01::5e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 42ms, Average = 41ms
At this point, we are actually done, traffic immediately starts flowing via v6 (<3 Google for turning on v6 on most of their properties) but I am not quite satisfied yet.
DNS
Our current DNS setup is as follows:
host machine -> local caching forwarding resolver running on router (v4)
I want to be like this:
host machine -> local caching resolver (v6)
This brings us to a dilemma, there are currently two ways of auto-configuring DNS servers for hosts via IPv6:
- DHCPv6 (Stateful auto-configuration, by setting the “Managed” flag on RA packets)
- RDNSS (Still stateless, sends resolvers in the RA packet itself)
I decided to go with RDNSS for now as I was already using SLAAC for address distribution.
I proceeded to fire up the Raspberry Pi with my new Class 10 SDHC card. We will be using unbound as our resolver software.
I finish configuring unbound (very easy, sample config file has sane defaults mostly) and set it listen on an address in our /64 and respond to queries only from that /64.
I set the RA config on the router to advertise DNS.
Now we run into an issue: operating system support for RDNSS. Most of the computers in the house run Windows 7, with one Windows 8 laptop, one Linux laptop, one iOS device, and 3 Android devices.
None of the Windows versions running in the network support RDNSS, the Android devices don’t either. The only systems that supported and picked up the RDNSS information was the iOS device and the Linux laptop.
So, we have most of the devices in the network not auto-configuring DNS resolvers. I decided on a compromise. The recursive forwarding caching resolver on the router allows me to specify the resolvers I want to forward queries too. I just add the IPv6 local resolver address as the first one in the list of forwarding destinations.
Final Thoughts
If you have IPv6 capable equipment (if you bought a router in the last couple of years, it likely supports IPv6 OOTB, an older router can probably have v6 support added via CFW) you should probably set up IPv6 connectivity in your network.
If your ISP doesn’t provide native connectivity yet, you can easily obtain and set up a HE tunnel like I did.