IPv6 on BT FTTC or:

How I Learned to Stop Worrying and "Love" the ISP

How it all started

I wanted to have a 6to4 tunnel running on my home BT FTTC connection. But the anycast address used to set it up was strangely uncooperative.

In the begining there was chaos

On 15 of July 2012 I have opened a call with BT Technical support regarding BT Infinity and 6to4 tunnels. On this page I am documenting the progress of this call and my attempts to work around the problems I have encountered when trying to use 6to4 functionality on the BT FTTC connection.

BT Technical Support

It took 18 working days for BT front-line support to finally forward this case to the BT technical team. In that time I was called every day by first line call centre and asked if my 'broadband is still faulty', have I 'rebooted my router' and told that 'there is a fault in my area and BT engineers are working on it right now'.

I was called on the morning of September 9th (Sunday) and advised that a) BT does not support IPv6 and b) the engineer on the case will be in touch within the next 48 hours. I have requested that this page is added to the call log and pointed out that although BT may not support IPv6, they seem to be actively interfering with a transitional mechanism.

In my understanding, BT operates a 192.88.99.1 (anycast) relay which is reachable from within the BT wholesale network that I am on. It is an address specifically reserved for 6to4 provision. This system is located on BT network and my guess is that is serves its purpose within BT. Unfortunately, for reasons unknown to me, that system does not respond to traffic from BT wholesale network, specifically FTTC. Because of this, it is actively breaking the 6to4 provision for its customers as I don't think there is a way to choose which anycast target the packets are routed to. There is a significant difference between 'not supporting IPv6' and 'actively breaking it'.

It is sad that lack of understanding of the problem, the dreaded "we don't support [...]" mantra, and the enormous corporate latency are in the way of resolving this issue. For premium products like FTTC, IPv6 provision should be standard and transparent to the user. It's been more than a decade now and IPv6 is still a curiosity at the edge.

September 26th. Two months and eleven days since my original problem report. There was no contact from BT since September 9th.

It is possible that I'm wrong with this whole 6to4 tunneling but at no point BT attempted to set things straight or even made efforts to sound competent on the subject. Perhaps it's against company policy to be helpful to the customer, perhaps engineers within BT are not allowed to make contact with those pesky users. I'm not sure I'll ever find out.

Bottom line is, and searchbots, do take note: 6to4 tunnelling on BT infinity doesn't work. Most likely by design. I did contact BT and gave them the opportunity to explain things but they chose to hide behind 'IPv6 is not supported'.

Taking stock

As far as I'm aware, BT does not offer IPv6 provision to its 'retail' customers. Despite a presentation from October 2000, and the fact that internally BT is well equipped and prepared for IPv6 deployment, no effort has been made to deliver a v6 prefix to the end-user.

I have heard rumours that the paid-upgrade BT HomeHub3 is supposed to have native IPv6 via prefix delegation available but a quick test with my neighbour's device revealed that it's not the case. I could not find any IPv6-related options in the administrative interface and no Router Advertisement packets were seen on my LAN.

I tried an Apple AirPort Express 2012. This unit promises 6to4 functionality. Unfortunately, despite the technical prowess of Apple engineers, Apple AirPort Express was unable to establish a 6to4 tunnel or obtain IPv6 prefix over any other method. The device was returned to the shop.

Next step was to try one of the Free router firmwares. Having had negative experiences with DD-WRT in the past, I have decided on a version of TomatoUSB by Shibby, release 093. This firmware supports 6to4 and offers the ability to ssh into the router to carry out some debugging. I have set up the 6to4 tunnel on it but it didn't work.

Traceroute to the anycast address 192.88.99.1 over IPv4 seemed to work:

The last hop (166.49.224.18) belonging to BT-IGNITE-GLOBAL-BACKBONE made me believe that the anycast relay is indeed on the BT network. Unfortunately, any traffic heading into the v6to4 interface remained unanswered:

MTU pitfalls

Since BT Infinity operates using PPPoE, the biggest MTU for the router's external interface is slightly smaller than the default 1500. Since PPPoE headers take 8 bytes, this makes the ppp0 interface's MTU 1492:

Consequentially, the Maximum Transmission Unit for a 6to4 tunnel needs to be 20 bytes smaller (according to RFC 2473 on Proto-41 encapsulation). The MTU for a 6to4 tunnel on a PPPoE link should not exceed 1472.

Anecdotally, the BT OpenReach (Huawei) modem supports RFC 4638 which should allow it to accept MTU of 1500 but the version of pppoe on TomatoUSB doesn't seem to support that. Furthermore, I have found a BT Business customer forum post that described apparent issues with BT's MSS clamping implementation. I was not able to confirm or disprove those findings.

Partial solution

Despite of all the above, I have found a way to get IPv6 working on my BT FTTC connection. Since 6to4 (although the easiest solution available) was not an option, I have turned to Hurricane Electric Tunnel Broker. Interestingly enough, as far as I can make out, it uses the same encapsulation method (proto-41) as 6to4, yet contrary to the BT-maintained 192.88.99.1, the he.net tunnel broker is working for me.

HowTo

> NOTE: As of 2020, this is probably hopelessly outdated. These days most routers will happily set up a HE tunnel, a 6to4 anycast tunnel, or proper ISP-provided IPv6 prefix delegation. But I'm leaving this here for posterity.

Also, TomatoUSB (Shibby's version) is no longer maintained, currently replaced by

FreshTomato

Other devices, such as Apple's discontinued routers and time capsules, Unifi EdgeRouter devices, Mikrotik routers will also work just fine.

TomatoUSB IPv4 setup

The following documents version 093-EN of the TomatoUSB Shibby build. Newer versions have not been tested. Tested up to versions published in late 2016 and working fine.

The choice of router and flashing it are beyond scope of this document. There's quite a few routers that are supported, some of them can be obtained refurbished or used for less than the shipping costs. I strongly recommend getting a router with at least 4MB of flash. I have tested this firmware with the following routers:

Note, K26RT-N builds on E4200 were frequently freezing for me. The firmware quoted above for E4200 is stable but does not support the 5GHz radio.

When choosing build to flash, please consult Shibby's feature matrix and use the build that has IPv6 support (MiniIPv6 being the baseline).

Once you have set up your router for normal IPv4 operation (PPPoE username: bthomehub@btbroadband.com, password: password), enable the 'Respond to ICMP ping' option in the Advanced/Firewall menu. Without it you won't be able to set-up the tunnel.

The Tunnel Broker account

Head to HE.net IPv6 Tunnel Broker Registration page and create the account. Please read the Tunnelbroker Terms of Service, they're short and to the point. Once your account is active, log in and create a regular tunnel. The IPv4 Endpoint needs to respond to ICMP echo requests (ping). Before you choose a tunnel server, take a moment to check (using ping and traceroute) if the server geographically closest to you is indeed best choice from the network topology point of view. Remember, the latency/number of hops to that system will affect all your IPv6 traffic so it's worth to take a moment and pick the fastest one.

Once you create the tunnel, you will be presented with a tunnel detail page. Head to the Advanced tab and set the MTU depending on your IPv4 connection MTU. For Ethernet-based connections (LAN, Cable, FTTP) that have native MTU of 1500, you need to use the default 1480 (as 20 bytes are used for the encapsulation). If you are using PPPoE, the connection MTU will be smaller, usually 1492 (8 bytes for PPPoE header) which takes the tunnel MTU down to 1472. The fail-safe setting (and the minimum that IPv6 connection must support) is 1280. Use it only if everything else fails. On the BT Infinity (FTTC) link, it's 1472.

Keep the IPv6 Tunnel tab open, the information will be needed in the next step.

TomatoUSB IPv6 setup

Since BT Infinity does not use a static IP allocation (the IPv4 address will change with each PPPoE session), the router needs to inform the tunnelbroker about its current address (otherwise anyone could establish your tunnel and intercept your traffic). This is configured on TomatoUSB in Basic/DDNS section. Version 093 wasn't able to register correctly with HE.net IPv6 Tunnel Broker ('Error -1') but it was possible to get it to work using 'Custom URL' service (newer firmware releases may fix the HE.net IPv6 Tunnel Broker support).

From the drop-down Service menu, choose 'Custom URL'. In the URL field, enter:

replacing he-username and he-password with your Hurricane Electric Tunnel Broker credentials and he-tunnel with the numeric Tunnel ID from Tunnel Details page. Select 'Force next update' and save the settings.

On the Basic/IPv6 page, select IPv6 Service Type as 6in4 Static Tunnel. Put contents of 'Routed /64:' field from the Tunnel Details page into Assigned / Routed Prefix field in TomatoUSB (note that /64 needs to be placed in the Prefix Length field below without the leading slash). Once this is done, the Router IPv6 Address field should auto-fill with the same address as the Routed /64 but with 1 at the end.

There is no need to enter Static DNS. As a matter of fact, it interferes with the router's operation. The v6 addresses are placed before the v4 ones in /etc/resolv.conf and DDNS process times out.

Tick Enable Router Advertisements and put the contents of 'Server IPv4 Address:' field from Tunnel Details page into Tunnel Remote Endpoint (IPv4 Address) field in TomatoUSB. The Tunnel Client IPv6 Address on your router should be filled with 'Client IPv6 Address:' field on Tunnel Details page. Lastly, Tunnel MTU is 1472 (the same as in the Advanced tab on Tunnel Details page). Save the settings, wait 1 minute, reboot the router.

Once the router boots, establishes a PPPoE link, you will see IPv6 information on the Status/Overview page. At this point the IPv6-enabled clients on your LAN should obtain IPv6 addresses automatically and ping6 google.com should work.

Secure by default

IPv6 means 'open Internet' and lack of the safety blanket that IPv4 NAT provides. Your LAN is no longer isolated from the Internet using your gateway, all the IPv6-enabled systems are now reachable. This requires specific approach to service security.

To avoid nasty surprises, TomatoUSB is 'secure by default'. Its firewall will drop all incoming traffic over IPv6 (with the exception of ICMP ping). This provides a similar level of isolation as a IPv4 NAT gateway would. At this point you have two options:

Be brave and let all incoming connections in (and better have solid service-level security on all the systems on your LAN!) or

Whitelist certain services (like SSH) while continuing to block others.

You can amend the firewall rules on the Administration/Scripts/Firewall page:

will allow all traffic to be routed into your network, while:

will only allow remote systems to connect to all SSH and HTTPS services on your LAN. Save and restart the router for the changes to take effect.

Configuring firewall and security policies are beyond the scope of this document.

Reverse DNS and static allocation

Hurricane Electric can delegate the Reverse DNS zone to a DNS server of your choice. If you would like to put some of your systems on static IPv6 addresses, it may be a good idea to provide them with RevDNS entries. This is done on the Tunnel Details page by filling 'rDNS Delegated NSx' entry/ies.

To service a ip6.arpa zone in bind, add:

where x.x.x.x is to be replaced with your tunnel's Routed /64 last 4 digits (0-padded if required in reverse order. The zone file (/var/lib/named/master/x.x.x.x.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.hosts for example) should look like this:

Replace 'example.com' with a forward domain that you control and 'hostmaster' with a working email contact (spam-proof!). The slaac.example.com. wildcards will give some rev-dns to all the stateless IPv6 addresses handed out by Router Announcements.

In the above example, 2001:470:1f09:xxxx::1 will resolve to ipv6-router.example.com and 2001:470:1f09:xxxx::27 to my-server.example.com.

Privacy Extensions on clients

IPv6 auto-configured address is derived from the system's MAC address. This can raise some privacy concerns and has been addressed in Privacy Extensions for SLAAC document.

Systems that don't provide services to the Internet can use auto-configured address with privacy extensions enabled. This is the case for Mac OS X and Windows 7. On GNU/Linux, depending on the distribution, it may require enabling by adding:

to /etc/sysctl.conf and issuing sysctl -p /etc/sysctl.conf as root. Note that wlan0 may be called differently (ath0, eth1) depending on the specific setup, driver and hardware. If in doubt, use ifconfig to get more information.

Some speculation

Since both 6to4 and 6in4 are using the same type of encapsulation (RFC 2473), I don't think there's any filtering going on on the 'customer' part of BT's network. My suspicion is that the 6to4 relay managed by BT is refusing to service non-business IPv4 ranges. This could be for 'security' reasons or perhaps BT's censorship system doesn't work over IPv6 and they are trying to limit their legal exposure. It is worth noting that Windows 8 will prefer IPv6 addresses on dual-stack systems, GNU/Linux can be configured to prefer IPv6 and Mac OS X does something clever instead. It may be a business decision to minimise support costs but my experience with front-line BT support makes me think that it doesn't really matter what sort of issues customer experiences, the medicine is always 'reboot computer, reboot router, make an openreach engineer appointment'.

Conclusion

Over a decade since its inception, IPv6 remains a domain of butique ISPs. Despite IPv4 exhaustion, ISPs that hoarded enough IP real estate have no incentives to get their customers connected using pure v6 or dual-stack solutions. Even though the OS support for IPv6 has improved dramatically, there's still perceived fear of increased support costs and added complexity. The fact that IPv6 requires network professionals to change a lot of their ways doesn't help.

BT FTTC aspires to be a premium product targeted towards IPTV and other bandwidth-hungry services but 'ubiquitous' connectivity (that v6 is part of) seems to be unattractive from the marketing point of view. I think decreased ability to shape, filter and invigilate transmissions over IPv6 and the fact that once v6 gains popularity, so will IPsec makes it a tough nut to crack for the ISPs that are operating in the thin space between copyright enforcement, new technologies, and shareholders.

Unless we see a tectonic shift in the three mentioned areas soon, I'm afraid the tech-savvy users are forced to limp along using v6 tunnels.

2017 update, case closed.

After 5 years of using Hurricane Electric tunnel broker for (excellent) IPv6 provision, I have noticed that BT was finally assigning native IPv6 to FTTC CPE. They are, however, handing out a dynamically assigned /56 which completely negates the point of having IPv6. It's actually worse than NAT as my RFC1918 addresses were static and suddenly I was stuck with a mess of static RCF1918 and dynamic v6 prefix in my home LAN.

Since BT has no intention of fixing this idiocy I have migrated to Zen Internet. They have provided a static /32 IPv4 and /48 IPv6 allocation at no extra charge, I was able to keep the FTTC and my BT line and all my CPE.

Goodbye BT. Hello Internet.