IPv6 support on Virgin media

The imposition of ds--lite woulld be sufficient for me to abandon my 500Mb VM for whatever I can get on 4g. I am 6 miles from the exchange with aluminium cable from the hole in the ground to the house.  No FTTP so about 1.9Mb. Hence 4g is my next bet after VM.

My home is about 50% dual stack. with my v6 tunnel from HE from my pfSense firewall giving me a /64 on the LAN.. I have about 15 devices running Tasmota which are IPv4 only. But they are all internet exposed through a reverse proxy with SSL encryption. So GC-NAT is no good for me. I work in locations that are IPv4 only. I need to be able to connect to my home resouces byIPv4.

I have a Nord VPN, so perhaps their static end point is my other option to guarentee my IPv4 conectivity.

4G would be a sideways move though, because all mobile carriers will be using CGNAT, so similar to the proposed DS-Lite implementation, IPv4 will not be directly routed to you, same problem. 5G with good coverage can absolutely smash a lot of fixed line providers (up to 300Mbps) but it's new, expensive and coverage is lower (much like 4G in the early days). Equally CGNAT is still in play. Most mobile carriers also inbound firewall IPv6 as well, so you'll not have much luck there.

Similar to you, FTTP is unlikely to be in my area anytime soon and FTTPoD will cost a small fortune. There would be ways to essentially do the reverse and provide native IPv4 under DS-Lite, but it would be the same solutions, VPN, GRE tunnel etc.

One option would be VM Business. I doubt they'd do DS-Lite for their business lines. You'd probably also get a static /56 or maybe even a /48, but given the consumer IPv6 rollout has taken this long, I have no idea about what plans for VM business. Ironically though, I hear their IPv4 static solution uses a GRE tunnel and it's temperamental, so much so I've seen various stories about VM business customers reverting back to dynamic IPv4, just so they get better performance. I could live with a dynamic IPv4, with a fixed IPv6 prefix. Most of us have likely been doing it with DDNS for years. 

I just switched to VM Business (500 Mbit/s) from a regular VM residential (350 Mbit/s) connection in the hope I could avoid their terrible throttling of protocol 41 traffic. Sadly, nothing has changed. Interestingly my 'Business' connection seems to be just the same connection as before but with a different router; even my dynamic IPv4 address did not change after the switchover...

I'm now trying to pursue the protocol 41 issue with VM; wish me luck (I am not optimistic)!

Good luck - that is what I did, but I gave up with asking about the throttling (that was a good few months ago). I am wondering if there is some kind of rate limiting directly on the peering connection, and if so, which side it is.

It has quite a detrimental impact on software and services that rely on CDNs for me.

I cannot fault the service other than that.

From doing a bit of research this on myself. I believe the performance bottleneck may be due to the Intel Puma 6 SoC in the CPE. I believe the Hitron router uses this as well as the Super Hub 3 and the performance bottleneck is actually the modem. Which could explain a lot of things, given the Puma 6 SoC is infamous for issues with just about anything to do with latency and performance and not necessarily the network itself.

I've had a couple of VM residential customers who have a Hub4 confirm that they had better performance with 6in4 with a Hub4, so it might be the issue here. The Hub4 still uses Arris and the Puma chipset, but its the 7 series, so they seemed to have fixed or ironed out some of the bugs.

Further evidence from another ISP in Czech Republic shows very similar CPE hardware having the exact same problems here with 6in4, so it is now looking like CPE problem.

I don't know if there are plans to have a business version of the Hub4, whatever it might be.

Good luck and thanks! Having an account manager does have its advantages at times.

I did my bit back in the day (3-4 years ago) along with the IT manager at my work at the time. We had a substantial VM Business connection through the business park's fiber network. They were really not interested but we kept plugging away and the issue was escalated. Sadly we both moved on in our careers before anything happened...

---

jamesmacwhite wrote:

From doing a bit of research this on myself. I believe the performance bottleneck may be due to the Intel Puma 6 SoC in the CPE.

---

Don't believe that is the case. I had experience of the issue with an SH1 and my current SH3 (both in modem mode). These devices have quite different architectures and the SH1 didn't used to have problems and (AFAIK) the firmware version didn't change. It looks to be something deeper in the VM network doing the throttling/de-prioritisation.

It is possible it is deeper than that, but if there is throttling, Virgin Media refuse to acknowledge it and have continually denied it for years. So taking that at face value, going on the basis they aren't in fact doing this, that makes me look at other potential elements, but of course it is only guess work.

The cases of other reports of the same issues with 6in4 all seem to point back to the Intel Puma 6 SoC. Equally, from a few customers that tested it, the change of modem to Hub4 seemed to improve things, so while it might not be the only problem, why the performance difference? If if was the network you'd expect that to be constant. The main changes with the Hub4 would be the Intel Puma 7 SoC and DOCSIS 3.1, although I don't see how DOCSIS is really related to this specific issue.

Perhaps there is a CPU bound requirement for 6in4. The SH1 and SH2 were Netgear if I recall, then the SH3 and newer Hub4 are both Arris Intel Puma SoC. Typically ISP provided kit is under powered or "just enough" to the basic job as per a contract, so there may be merit to it, but who knows.

It seems unlikely that the SH3/Hitron hardware/firmware is an issue in my case because:

1.   In modem mode (which is how I run) the SH3 (or in my case the Hitron) should just be dealing with the minimum needed to allow packets to flow. It certainly should not be doing any protocol related processing and so all IPv4 traffic should be treated the same by the SH3/Hitron.

2.   If I create a VPN connection to my VPN provider (over VM IPv4 of course) and then create a 6in4 tunnel over that then I can get much, much higher IPv6 speeds (over 100 Mbit/s, despite the significant overhead of the OpenVPN VPN). In this case the VM network only 'sees' a VPN connection and does not 'see' the 6in4 traffic.

This second point seems quite definitive to me. I have tried with several different VPN endpoints in the UK and elsewhere and also several different tunnel servers and all show this far higher throughput when the VM network cannot see that the traffic is protocol 41.

I do agree with you. I have also tested a IPv6 enabled VPN (Mullvad) and got much better speeds. If the 6in4 tunnel terminates on a VM connection the speed is horrible if it is encapsulated over UDP i.e. Wireguard or OpenVPN then the performance is much better, so yes you'd think it is VM throttling, but I then don't understand why they'd deny it all this time or why customers with the Hub4 saw much better performance, without doing anything other than swapping the CPE with different hardware specification, doesn't make sense and contradicts both theories.

Even their traffic management page says nothing, of course they define that so they can say whatever they like and even perhaps hide behind the "other traffic measures", which could be anything. Maybe a formal complaint to the higher authority or an FOI request on specific treatment on 6in4 traffic in their network is one way to confirm it.

It makes me think there are multiple parts to this and it's not just straight throttling of a protocol, you'd like to think if it was it could have been fixed maybe several years ago. This problem isn't exactly secret and is fairly well known across different communities, even if it is niche.

Given you're a VM Business customer you'll at least have some form of SLA response, so maybe you'll have more luck. Best of luck!

---

ChrisJenkins wrote:

This second point seems quite definitive to me...

---

That would also be explained perfectly by the hub theory though, because all the hub would see is the VPN connection and it wouldn't be able to tell that protocol 41 is in use or need to do any processing to cater for it

That would be true if the hub is in router mode, but in modem mode it does not 'look' at the packets nor do any processing (if it does then that is a serious bug).

Do we have any links to the evidence that much faster speeds are obtained using an SH4? Do we know for sure if the SH4 was in router mode or modem mode for those cases? I'd like to review exactly what has been claimed.

In modem mode the CPU will still be present though. You remove most of the routing functionality of course so easing the load, but the CPU is still required for the WAN side. It is why the latency issues with the SH3 in modem mode are still present, if it is a hardware issue from the CPE and can't be fixed with software or firmware. Modem mode would help, but it can't fix the underlying hardware level issue.

From the few people I talked to outside of this community forum who have a Hub4 and known what 6in4 is, they were using modem mode. The only way to configure a 6in4 tunnel in router mode is then having to NAT a LAN client for protocol 41 and deploy the tunnel on that client, so no one will really be doing that I don't think.

Given the Hub4 is newer and the not many people will be doing 6in4 I admit, I cannot verify the claim myself. I'm not currently in a DOCSIS 3.1 area, so I doubt I'd be able to convince Virgin Media to give me a Hub4, I'd even consider paying for it, if it was an option just to see for myself. I guess the alternative is throw out a general "All Hub4 users using a 6in4 tunnel" type of message to see what the story is. Of course, a few people isn't a relative sample.

The latest known info I'm aware of on the Hub4 is, Virgin Media are offering it outside of the Gig1 service, but only to selected areas, likely where DOCSIS 3.1 is available, so they can utilise the extra bond channels to reduce network load, or use it as a "WiFi upgrade" for the home. Eventually it will become widely available, but I don't think it will happen just yet.

James, this doesn't really make sense... Why would the hub, in modem mode, have to spend much more CPU processing protocol 41 packets than other packets (given that it should simply be 'passing through' all IPv4 packets in the same way)? If there is a general issue with the CPU power of the hub (in modem mode) then it would be impacting all traffic not just protocol 41 traffic. I pay a great deal of attention to the performance of my Internet connection (throughout and latency). I have monitoring in place that measures the performance every 15 minutes and I have data from this going back for over 3 years (SH2, then SH3 now Hitron). Other than occasional periods when there has been an actual service issue (i.e. VM network problem) I have not observed any major issues with latency or throughput (apart from the dreadful IPv6 throughput of course).

Certainly the hub processing power might be an issue in router mode *if* the hub was for some reason doing a lot of extra processing for packets carrying protocol 41 (it should not be of course but who knows what the firmware does) but again in modem mode the doesn't make sense. We're not talking about a small impact here; we are talking about the difference between 500 Mbit/s and 20 Mbit/s. I cannot conceive that this is due to a lack of CPU power in the hub when the hub should not even be involved (other than simply passing the packets through uninspected).

If we can see some real evidence that SH4 make a big difference (in mode mode) then I'll happily review my opinion but at the moment it seems like conjecture to me.

Fair enough.

It will be difficult, given the niche case of 6in4 and being on the newer Hub4 to test, but happy to try and help even if it invalidates my own theory, happy to be wrong!

• https://forums.thinkbroadband.com/virgin_cable/f/4653284-hub4-with-a-6in4-tunnel-please-share-your-ipv6-performance.html
• https://www.reddit.com/r/VirginMedia/comments/huhea5/anyone_with_a_hub4_in_modem_mode_using_a_6in4/

Here's a couple of threads asking the question in a couple of forums to see what the response might be on it. No guarantees it will yield a sizable response but one can try!

There is anecdotal evidence that that SH3 isn't very good at handling large amounts of UDP traffic in certain situations.

A recent (Jan / Feb of this year) software update introduced all sorts of latency issues with users running the SH3 in modem mode hooked up to a pfsense router. Eventually someone worked out that if you turn of DNS resolution (and just use DNS forwarding) in pfsense, then the issue with latency goes away. The theory is that doing DNS resolution to the root servers generates more or a different type of traffic, that the SH3 isn't very good at handling.

I can show you graphs where I have a perfectly usable connection one moment, then the hub goes offline briefly to carry out the software update, then comes back with awful latency spikes. Then a month or two later someone finally worked out how to work around the issue, and the spikes all but disappear once a single checkbox is changed in pfsense.

This does suggest that there's a potential performance issue in the SH3 even when it's running in modem mode. It's far from conclusive though.

Andy

That certainly sounds like an SH3 firmware issue, but it seems pretty specific. I've been doing all my external DNS lookups through my SH2/SH3/Hitron for several years and I never observed that issue. I'm not using pfsense though.

Not sure this is really related/relevant to the 6in4 issue other than as a general indicator that VM modems/routers are often a bit flaky 🙂

---

ChrisJenkins wrote:

That certainly sounds like an SH3 firmware issue, but it seems pretty specific. I've been doing all my external DNS lookups through my SH2/SH3/Hitron for several years and I never observed that issue. I'm not using pfsense though.

Not sure this is really related/relevant to the 6in4 issue other than as a general indicator that VM modems/routers are often a bit flaky 🙂

---

Yes, it seemed to be something specific to pfsense that was triggering this issue. A small number of people had a similar setup and had seen the same thing. They made the same change as I was suggested to try and it also had a similarly beneficial effect.

And yes, not necessarily relevant to 6in4, but I just wanted to offer it up as a potentially similar issue, showing that it could indeed be something in the SH3 itself, even when running in modem mode.

Andy

So, there may be something in this... I ran some speed tests (iperf3) over IPv4 against a public server using both TCP and UDP. One would expect broadly similar results but in fact there is a huge difference...

With TCP I can consistently get ~490 Mbit/s download speed using a single 'stream'. With UDP I max out at ~ 1 Mbit/s per stream, though it does scale somewhat (16 concurrent streams gives me ~16 Mbit/s throughput). So for some reason UDP is much, much slower than TCP, at least for this test. This *might* indicate some issue with UDP traffic either in the VM network or possible related to the modem (Hitron in my case). I need to try and do some more detailed testing to dig into this.

I wonder if 6in4 tunnels use UDP or TCP... I need to also look into that. Strangely, my VPN provider supports OpenVPN over both TCP and UDP and for that UDP is much, much faster (~3x) the TCP (I can get ~150 Mbit/s download via VPN over UDP versus around 50 Mbit/s via VPN over TCP.

All very strange and needs more investigation I think.

6in4 uses IP protocol 41 which is neither UDP (IP protocol 17) or TCP (IP protocol 6). This is likely the source of the problem whether it be an issue with the VM network or the CPE. Once upon a time there were many IP protocols these days anything outside of TCP, UDP and ICMP is pretty unusual. Network HW vendors have heavily optimised their hardware and software on this basis. For example many home routers have HW accelerated NAT that only speed up UDP, TCP and ICMP, everything else raises an exception that has to be processed by CPU. Sometimes this exception handling even works...😁 (OpenWRT avoided HW accelerated NAT for many years because of this).

"I wonder if 6in4 tunnels use UDP or TCP" <-- actually neither, UDP is protocol 17, tcp is protocol 6, 6in4 is protocol 41, does not utilize TCP or UDP.. one thing that's been mentioned is that there are optimized handling for TCP and UDP in the data path (priority, better treatment, etc, who knows), but since 6in4 is neither tcp or udp it has suboptimal handling somewhere along the data path (whether this be in the CPE or internal to VM's network)

Great catch @ksim I hand't noticed that in the man page but yes, the default bitrate for iperf3 is unlimited for TCP and 1 Mbit/s for UDP. Weird, but hey...

Okay, when I use a limit of 1000Mbit/s (i.e. no practical limit) I get ~360 Mbit/.s over UDP, so noticeable slower than TCP but certainly not enough to explain the 6in4 tunnel issue (even if they use UDP, which I haven't confirmed yet).

Ah okay, thanks for the education!