Skip to main content Skip to navigation

IPv6 on BT FTTC or:

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 dynamic DNS. Hello Internet.

Disclaimer: my employer is not endorsing this.

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

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'.

Since then, I have been in contact with a BT engineer and I will do my best to get to the bottom of this. I'd like to understand why 6to4 is not working on BT FTTC. Expect updates in this section.

Update: 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 disabling it. We'll see how this progresses. I'm expecting a call on Tuesday.

In my understanding, BT operates a (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.

Update: 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 Google 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 the 6to4 functionality 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. The device was returned to the shop for a full refund.

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 over IPv4 seemed to work:

root@router:/tmp/home/root# traceroute -nI
traceroute to (, 30 hops max, 38 byte packets
1  7.837 ms  7.583 ms  7.646 ms
2  8.480 ms  8.100 ms  8.450 ms
3  10.474 ms  10.095 ms  10.189 ms
4  10.010 ms  10.101 ms  10.141 ms
5  10.677 ms  10.087 ms  9.901 ms
6  25.654 ms  9.837 ms  9.664 ms
7  19.673 ms  24.108 ms  24.135 ms
8  16.405 ms  16.337 ms  16.401 ms
9  16.667 ms  16.354 ms  16.883 ms
10  17.444 ms  17.075 ms  17.154 ms
11  43.437 ms  43.080 ms  43.394 ms
12  46.146 ms  46.334 ms  46.145 ms
13  46.422 ms  46.326 ms  46.699 ms
14  46.360 ms  46.572 ms  46.693 ms

The last hop ( 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:

v6to4     Link encap:IPv6-in-IPv4  
          inet6 addr: 2002:6d9c:a379::1/16 Scope:Global
          inet6 addr: fe80::6d9c:a379/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:26982 (26.3 KiB)

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:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:  P-t-P:  Mask:
          RX packets:15872 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13821 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:16314265 (15.5 MiB)  TX bytes:1247017 (1.1 MiB)

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 (warning, intrusive tracking cookies) 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, the tunnel broker is working for me.


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:

Router model Firmware Image Flash size
Linksys WRT160N v1 tomato-K26-1.28.RT-MIPSR1-093-MiniIPv6 4MB
Linksys WRT320N v1 tomato-K26-1.28.RT-MIPSR2-093-MiniIPv6 8MB
Linksys E2000 v1 tomato-E2000-NVRAM60K-1.28.RT-MIPSR2-093-IPv6-VPN 8MB
Linksys E3000 v1 tomato-E3000USB-NVRAM60K-1.28.RT-MIPSR2-093-Big-VPN 8MB
Linksys E4200 v1 tomato-E4200USB-NVRAM60K-1.28.RT-MIPSR2-093-AIO.bin 16MB

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:, password: password (sic!)), 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 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 IPv6 Tunnel Broker ('Error -1') but it was possible to get it to work using 'Custom URL' service (newer firmware releases may fix the 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 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. 1) Be brave and let all incoming connections in (and better have solid service-level security on all the systems on your LAN!) or 2) Whitelist certain services (like SSH) while continuing to block others.

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

/usr/sbin/ip6tables -P FORWARD ACCEPT
/usr/sbin/ip6tables -F FORWARD

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

/usr/sbin/ip6tables -I FORWARD -p tcp --dport 22 -j ACCEPT
/usr/sbin/ip6tables -I FORWARD -p tcp --dport 443 -j ACCEPT

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. Some further reading is strongly advised.

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 zone in bind, add:

zone "" {
     type master;
file "";
     notify yes;

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/ for example) should look like this:

$TTL 604800
@ IN SOA (
         2344933355 ; Serial
         60 ; Refresh
         7200 ; Retry
         604800 ; Expire
         86400) ; Minimum

         IN     NS    
         IN     NS 3600    IN        PTR 3600    IN        PTR
*                               3600    IN        PTR
*.0                             3600    IN        PTR
*.0.0                           3600    IN        PTR
*.0.0.0                         3600    IN        PTR
*.                       3600    IN        PTR
*.                     3600    IN        PTR
*.                   3600    IN        PTR
*.                 3600    IN        PTR
*.               3600    IN        PTR
*.             3600    IN        PTR
*.           3600    IN        PTR
*.         3600    IN        PTR
*.       3600    IN        PTR
*.     3600    IN        PTR
*.   3600    IN        PTR
*. 3600    IN        PTR

Replace '' with a forward domain that you control and 'hostmaster' with a working email contact (spam-proof!). The 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 and 2001:470:1f09:xxxx::27 to

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:

net.ipv6.conf.wlan0.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

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.

A little bit 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'.


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.

* Opinions expressed on this page are mine only and not my employer's

Please send comments and corrections via the contact form.