Adventures in IPv6

So I was having a discussion on one of the boards I lurk on some weeks ago around IPv6, and that spurred me to finally pull my finger out and actually DO something about it (up until this point I’d been basically taking the “Ostrich” path of sticking my head in the sand and pretending it didn’t exist).

My current provider has not deployed dual-stack to the edge, and all indications are that there will be significant costs involved in doing so (and they’ve recently been purchased by the biggest cheapskate in the ISP game, so I’m not going to see native IPv6 any time soon), and I’m rather attached to my extremely lightly contested HFC connection, so switching to another provider for native IPv6 is not an option, time to do some fishing.

A bit of looking around reveals the existence of “Tunnel Brokers” who provide 6in4 tunneled connectivity, awesome, let’s go find one of them…

The largest tunnel broker in the world (and also arguably the “centre of the IPv6 internet” because they were basically the first major IPv6 deployment on the internet) is Hurricane Electric and their service which offers up to 5 free 6in4 tunnels (and optionally a routed /48 for each), signed up there, created a tunnel, followed this (now rather antiquated, but still usable) document to get the tunnel up and running on my border router.

Configured DHCPv6 to start serving the routed /64 provided by HE, et voila, IPv6 on my LAN. Surprisingly straight forward. The hardest part was needing to remove the “REALLY REALLY disable IPv6” regkey from my Windows box (because that meant I needed to reboot it 😉 ).

So at this point I’ve got IPv6 connectivity working on the LAN, time to go deeper (I’ve got several subnetworks for different purposes), and dig into the world of Prefix Delegation.

Log into HE, click button that says “assign /48”, /48 allocated, woo!

Update DHCPv6 config on pfSense, set “Prefix Delegation Range”, set “Prefix Delegation Size” to something sensible (I used 62, so I can have 4 networks behind each of my routers, realistically I could’ve used 56 and still not been remotely in danger of running out of prefix…).

Enable IPv6 WAN interface on (one of several) Wireless router, router pulls prefix and starts assigning to clients. Well shit that was easy…

Throw in an inbound rule to allow ICMP from one of my VPSes with IPv6 connectivity into one of the addresses on my wireless network, ping address, lo and behold, it “just works(tm)”…

All in all I was surprised at just how painless it was to get up and running, the nicest thing about this is I don’t have to bend over backwards to renew the LE certs I use on my internal services anymore 🙂

Unfortunately it’s not all roses though;

IPv6 in and of itself is pretty straight forward and more or less “just works(tm)”, the major ugliness comes in when you start looking into stuff like NAT64 and DNS64 which are dirty hacks intended to get us through the transition between “getting everything on IPv6” and “getting everything off IPv4”.

All in all, this setup works pretty well but there is one major issue with it. HE do not have any PoP’s in Australia, the closest PoP (routing-wise) I could find was Tokyo, which is not a major issue (though it adds 300ms of latency) in and of itself, but it is problematic in some situations because I have an IPv4 address which geolocates to Australia, where my IPv6 address geolocates to Japan. CloudFlare in particular does not like this, I’ve had a large increase in the incidence of “prove your human” type prompts out of it when I access CloudFlare protected sites. I’ve also had one attempt at purchasing something online being flagged as fraudulent because my IP address geolocates to a country that doesn’t match my CC billing address.

I’m presently working on resolving that issue, and once I get that working I’ll write a post on that.

Morgan / 2017-01-24 / Uncategorized / 0 Comments