I think IPv6 might not have so much bandwidth at Zen.. but will need this confirmed by them.....
That's very unlikely. What's much more likely that IPv4 and IPv6 take different traffic paths.
The topologies of the IPv4 and IPv6 Internets are different: some networks peer on IPv4 but not IPv6, and vice versa; some transit providers offer v4 but not v6 and vice versa. These differences could be at Zen's side, at TBB's side, and/or at the intervening networks (aka Autonomous Systems or ASes). You would need traceroute and traceroute6 from you to TBB's speedtest servers, and also from them to you, to be sure.
If you want to dig a bit further:
* Go to
https://bgp.he.net/
* Enter your own IPv4 address, see what AS number it is being announced from. Ditto for your IPv6 address. They should be announced from the same AS; if not, something odd is going on (e.g. IPv6 tunnelling)
* Use the AS number to see the BGP topology, i.e. which other ASes your provider is announcing their routes to, and which ASes in turn re-announce those routes to other ASes ("transit")
Zen has several UK AS's, but let's say your addresses are being announced from AS13037. You can see what peer AS's they announce their v4 and v6 routes to here:
*
https://bgp.he.net/AS13037#_graph4
*
https://bgp.he.net/AS13037#_graph6
So their main IPv4 transit is AS2914 (NTT) and AS3257 (GTT) . They also have direct peering with a number of other ASes (presumably at the LINX)
IPv6 is only announced to AS6939 (Hurricane Electric), AS2914 and AS3257. I don't see direct peering with any other ASes (or perhaps they simply prefer the route via one of those, over direct peering). This also depends on how accurate he.net's collection of BGP data is. However it could mean that IPv6 traffic between Zen and another UK ISP is going to go via one of those three transit providers, instead of taking a direct path.
So now let's look at TBB's servers. When I run a TBB speedtest the v4 traffic comes from 80.249.103.8 and the v6 from 2a02:68:1:4::2. Those are both announced from AS21396 (NetConnex Broadband).
Their v4 and v6 topologies are similar:
https://bgp.he.net/AS21396
You'll notice that AS6939 (Hurricane Electric) transits their IPv6 routes to other ASes, but not their IPv4 routes. I won't go into the details here, but there's a lot of politics and history going on with Hurricane Electric. In essence, Hurricane Electric has been trying to position itself as a tier 1 backbone on IPv6, by offering free IPv6 transit at various peering points, in order to pick up as many routes as possible to make itself attractive as a peer to the other tier 1's. Because of this, often you'll find v6 traffic between smaller networks going via Hurricane Electric's backbone, even though neither network is a customer of Hurricane Electric.
Anyway, the RIPE database says that AS13037 and AS21396 announce all their routes to each other:
| Text |
1
23
45
67
89
1011
| $ whois -h whois.ripe.net AS21396 | grep AS13037
import: from AS13037 accept AS-ZENexport: to AS13037 announce AS-NETCONNEX
$ whois -h whois.ripe.net AS13037 | grep AS21396remarks: # AS21396: NETCONNEX
mp-import: afi ipv4.unicast from AS21396 195.66.224.240 at 195.66.224.158 accept AS-NETCONNEX;mp-export: afi ipv4.unicast to AS21396 195.66.224.240 at 195.66.224.158 announce AS-ZEN;
mp-import: afi ipv4.unicast from AS21396 195.66.236.240 at 195.66.236.158 accept AS-NETCONNEX;mp-export: afi ipv4.unicast to AS21396 195.66.236.240 at 195.66.236.158 announce AS-ZEN;
mp-import: afi ipv4.unicast from AS21396 5.57.80.142 at 5.57.80.48 accept AS-NETCONNEX;mp-export: afi ipv4.unicast to AS21396 5.57.80.142 at 5.57.80.48 announce AS-ZEN; |
However I can't tell whether they are actually peering on v6 to each other or not, and indeed there's a suspicion from this that Netconnex peers only on v4.
If that's true - and I couldn't be sure without access to the relevant routers or at least looking glasses (*) - then that could mean the IPv6 traffic takes a longer path.
You can see at least the possibility that it could be TBB's upstream Netconnex who is to blame, rather than Zen; or it could be both of them. Adding that v6 peering is extra configuration work, and sometimes people just don't bother or it gets forgotten, or there's an error in how their route filters are configured (either the routes they announce or the routes they accept).
Since you are a customer of Zen, you are certainly within your rights to ask them whether they peer with AS21396 on IPv6; and similarly, the people who run the TBB forum could ask Netconnex whether they peer with Zen on IPv6.
(*) A looking glass is a website hosted at an ISP which exposes their view of the Internet, letting you see their BGP tables and run traceroutes. However I can't find one at either Zen or Netconnex.
There is one other thing worth mentioning in passing. IPv4 headers are 20 bytes; IPv6 headers are 40 bytes. So even if the v4 and v6 network topologies were identical, you should expect IPv6 to be slightly slower. If you are sending a TCP stream with 20 byte TCP headers (no TCP timestamp option), then the payload size for IPv4 is 1460 and for IPv6 is 1440. This means that in the best case, the achievable throughput on IPv6 is 1.37% less than IPv4.
If your ISP gives you full gigabit then the local ethernet framing on the cable into the ONT also comes into play. On a speedtest which measures the TCP payload, you'll achieve 942Mbps on IPv4 but 928Mbps on IPv6.
Sorry if this long ramble is either not understandable or not interesting. It's just not as simple as "IPv6 might not have so much bandwidth at Zen"
Regards... Brian.
Pages in this thread: 
Print Thread
I think IPv6 might not have so much bandwidth at Zen.. but will need this confirmed by them.....
