How I Learned to Stop Worrying and "Love" the ISP
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.
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.
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'.
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:
root@router:/tmp/home/root# traceroute -nI 192.88.99.1 traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 38 byte packets 1 217.32.144.163 7.837 ms 7.583 ms 7.646 ms 2 217.32.144.206 8.480 ms 8.100 ms 8.450 ms 3 213.120.181.58 10.474 ms 10.095 ms 10.189 ms 4 217.41.169.191 10.010 ms 10.101 ms 10.141 ms 5 217.41.169.109 10.677 ms 10.087 ms 9.901 ms 6 109.159.251.233 25.654 ms 9.837 ms 9.664 ms 7 109.159.251.175 19.673 ms 24.108 ms 24.135 ms 8 194.72.17.194 16.405 ms 16.337 ms 16.401 ms 9 166.49.168.33 16.667 ms 16.354 ms 16.883 ms 10 166.49.208.254 17.444 ms 17.075 ms 17.154 ms 11 166.49.195.106 43.437 ms 43.080 ms 43.394 ms 12 166.49.141.102 46.146 ms 46.334 ms 46.145 ms 13 166.49.224.18 46.422 ms 46.326 ms 46.699 ms 14 192.88.99.1 46.360 ms 46.572 ms 46.693 ms
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:
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)
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:109.156.163.121 P-t-P:217.32.144.163 Mask:255.255.255.255
UP POINTOPOINT RUNNING MULTICAST MTU:1492 Metric:1
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 that described apparent issues with BT's MSS clamping implementation. I was not able to confirm or disprove those findings.
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.
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
Other devices, such as Apple's discontinued routers and time capsules, Unifi EdgeRouter devices, Mikrotik routers will also work just fine.
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: 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.
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.
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:
https://he-username:he-password@ipv4.tunnelbroker.net/ipv4_end.php?tid=he-tunnel
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.
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:
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.
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:
zone "x.x.x.x.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa" {
type master;
file "x.x.x.x.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.hosts";
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/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:
$ORIGIN x.x.x.x.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
$TTL 604800
@ IN SOA x.x.x.x.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. hostmaster.example.com. (
2344933355 ; Serial
60 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum
IN NS ns1.example.com.
IN NS ns2.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR ipv6-router.example.com.
2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR my-server.example.com.
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.
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.
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.
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.