IPv6 support on Virgin media
Does anyone know whether (and if so when) Virgin plan to implement IPv6 on its network?
Forum Discussion
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.
- > 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.
you are testing it wrong. iperf is using 1Mbit/s as a default stream bandwidth, it is UDP, a loss tolerant protocol! use `-b` switch to adjust bandwidth 
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!