IPv6 support on Virgin media

Maybe VM techies couldn't figure out a way to make DS-Lite stateful and behave like their native IPv4 does currently, ie. keeping the same IPv4 address as long as the CPE's MAC address remains the same.  That would have made DS-Lite palatable, but if they failed to design that then indeed stateless DS-Lite would be an utter disaster for users and would have become a support nightmare for VM.  Under those circumstances it wouldn't surprise me if they abandoned DS-Lite plans and switched their IPv6 target to dual stack.

Unfortunately dual stack is just a short-term transition mechanism and has no future beyond local IPv4 exhaustion at all, whereas DS-Lite transforms easily into "IPv4 as an extra-cost service" which makes the long tail of legacy IPv4 users bring in some nice extra cash --- not surprisingly, most ISPs tend to like that idea.

Perhaps Virgin just deferred it:  dual stack while they still have IPv4 addresses to assign statefully, and then the horrible stateless DS-Lite for new customers once VM runs out of IPv4 blocks in a few years' time.

---

Morgaine wrote: ... Perhaps Virgin just deferred it:  dual stack while they still have IPv4 addresses to assign statefully, and then the horrible stateless DS-Lite for new customers once VM runs out of IPv4 blocks in a few years' time.

---

Well VM keep saying that they are not going to run out of IPv4 addresses for the foreseeable future and words to the effect of "Don't panic, this isn't a problem for us" what with customers moving to other High-speed ISPs maybe VM customer-base will become, what is a polite term, ah, how about "consolidated" in the next few years! :smileytongue:

What about the possibility that VM firmware for SuperHub 3 is common across multiple regions? Getting OEM firmware developed for a device is expensive. The DS-Lite functionality could be in there for deployment in VM Ireland where such things are required but not turned on for VM UK where they aren't.

That's an interesting suggestion @davefiddes.  It's certainly possible that the DS-Lite options in Hub 3.0 are generic to the device, and not related to any Virgin Media plans for the UK.

Perhaps one of the early adopters of Hub 3.0 might remember whether the DS-Lite information fields that I pasted earlier were there from the day of Hub 3.0 release, and not a recent addition reflecting the "by the middle of 2017" plans of half a year ago.

Interesting information, thanks @Sephiroth.

So, the history of Hub 3.0 firmware upgrades does strongly suggest that DS-Lite was part of a recent IPv6 deployment plan for the UK, probably the plan that was intended to come to fruition "by the middle of 2017".

As I speculated before, if it's true that DS-Lite isn't part of Virgin's current IPv6 plan for "later this year", then it looks like they've changed their plan from what it was before, and Hub 3.0 firmware hasn't caught up with the current plan yet.  If so then we can expect new firmware to roll out in advance of IPv6 deployment, and for the current DS-Lite fields to vanish.

Silly question. Why would we need DS-Lite?  

https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29

From what I read DS-Lite isn't end to end dual stack; it's Carrier-Grade-NAT (CGN) masquerading as dual stack.

I thought CGN was generally considered an abomination and something to be avoided at all costs?

If VM have enough v4 IPs (as they've always claimed) then the best thing for their customers is NOT to use DS-Lite.  The best thing for us is actual bonafide Dual Stack with two public IPs (a v4 address and a /64 v6 block).

@couling asks:

Why would we need DS-Lite?

I summarized the DS-Lite vs Dual Stack issue back in messages 335 and 383, but I'll expand a little on it for you.

It's not that anyone needs DS-Lite specifically, but that ISPs need some IPv6 transition mechanism that works over the medium term when most traffic is running on IPv6 and IPv4 use begins to ebb away.

Dual Stack isn't such a mechanism because it requires ISPs to maintain internal IPv4 infrastructure which they want like a hole in the head.  Running two IP stacks in parallel is both very expensive and a major support headache, so it's no surprise that many ISPs are planning on IPv6-only for internal infrastructure as seen in their IPv6 conference presentations.  In any case, Dual Stack has no long-term future for them since it can't expand beyond IPv4 address exhaustion --- that's why ISPs are looking at other IPv6 transition mechanisms.

DS-Lite has its own problems, but it does give ISPs the ability to run IPv6-only infrastructure internally and deploy IPv4 equipment only at the edges where it's still needed.  What's more, this IPv4 provisioning can be "on-demand", allowing ISPs to offer "IPv4 as an extra-cost service" which turns the long tail of legacy IPv4 users into an extra revenue stream for them --- ISPs like that idea a lot.  So, that's the motivation for DS-Lite or any other IPv6 transition mechanism that transports IPv4 over IPv6 and allows IPv4 to be optional and decreasing with time.

Hopefully that answers your question.

Unfortunately DS-Lite introduces many problems as well --- added latency, dual-NAT and broken port forwarding are often mentioned.  To make it even worse, the most common variety (stateless DS-Lite) would probably be a disaster for everyone, including the ISP through increased support costs, since it adds non-persistent IPv4 addresses (and hence TCP session breakage) to all the other DS-Lite problems.  That's why I hypothesized that Virgin abandoned their "IPv6 by the middle of 2017" plans, which were going to use DS-Lite based on the evidence of Hub 3.0 firmware.  "Support doesn't need the pain that DS-Lite will bring, when we still have enough IPv4 addresses for a few years of Dual Stack", their Support manager may have advised the board.  (Just my guess, of course.)

In other words, I'm hoping that Virgin deploy Dual Stack now, and defer DS-Lite for when IPv4 becomes an optional service some years down the line.  This would also give them extra time to implement stateful DS-Lite with IPv4 address persistence and hence eliminate some of the known problems that DS-Lite would otherwise introduce.

Morgaine.

Thanks.  That does bring me up to speed on the discussion.  To summarise, DS-Lite is not good for customers but is seen as achievable where other options are not.

Roughly, yes, although I'd modify your one-line summary to "DS-Lite is not good for customers but it has long-term viability where most other transition mechanisms do not."  It captures the essence of the issue.

And to complete the picture, "Dual Stack is the simplest and least problematic transition mechanism for users and providers alike, but it is strictly a short-term solution with no long-term viability in an IPv6 world, and is costly in ISP equipment and manpower."

Not sure if it's the beginning of some form of test roll-out, but I've noticed that my Hub 3 has started advertising a ULA prefix (fd15:64dc:3397:1:: in my case). Sky did this before rolling out real IPv6 addresses to everyone

It might be worth me asking at this point - which Not-So-Super Hub Types will be capable of providing whatever it is that VM are going to offer in terms of IPv6? Of course, answering this may well depend on the answer to the latter anyhow - so I guess it is who knows at this point... :smileylol:

@matthewsteeples writes:

I've noticed that my Hub 3 has started advertising a ULA prefix (fd15:64dc:3397:1:: in my case).

That's very interesting and it raises my hopes, thanks.

I see no IPv6 router advertisements coming from my Hub 3.0, but this may be because I run it in Modem Mode.  My Billion BiPAC 6300NX router is configured for combined IPv4+IPv6 operation, dynamic IP assignment, and with "Obtain IPv6 DNS" enabled, so I'd expect any Virgin ULA addresses required for communication with ISP infrastructure to be advertised to the router and a corresponding ULA prefix delegated to it.  My Billion hasn't received any IPv6 advertisements from the VM modem at all though, neither global, ULA, nor even link-local.

Is your Hub 3 in Router Mode when you see the ULA prefix, or in Modem Mode?

My Hub 3.0 is still on firmware version 9.1.116V as before, and in Modem Mode it still shows the three IPv6 DS-Lite fields in its Admin->Info screen, as I pasted here previously.  Is yours running a newer version?

Well I've only got a Super Hub 2 - the one that can do 2.4 and 5 GHz WiFi - but not both at the same time :smileysad: - but it has been updated in the past and now claims to have version V2.39.02 and more importantly "EU DOCSIS 3.0" which according to the stuff over on Wikipedia means that it should support both flavours of IP.  Interestingly one of the references on that page was: "IPv6 and Cable: How Cable is managing the transition from IPv4 to IPv6" (PDF) which though over ten years old (IIRC, it only listed Win XP/Vista!) gave some interesting (to me anyhow) pointers...

---

SlySven wrote:

Well I've only got a Super Hub 2 - the one that can do 2.4 and 5 GHz WiFi - but not both at the same time :smileysad: - but it has been updated in the past and now claims to have version V2.39.02 and more importantly "EU DOCSIS 3.0" which according to the stuff over on Wikipedia means that it should support both flavours of IP.  Interestingly one of the references on that page was: "IPv6 and Cable: How Cable is managing the transition from IPv4 to IPv6" (PDF) which though over ten years old (IIRC, it only listed Win XP/Vista!) gave some interesting (to me anyhow) pointers...

---

Both the SH2 and SH2ac support simultaneous dual band, as does the Hub 3.  Only the SH1 was an either or affair.

Well it is a Black VMDG480 so perhaps it is only a 1 after all even though it reports Hardware Version 2.0 (must be version two of SuperHub one!) anyhow it can only do one band at a time:

That being the case the chances of it having the processing power to handle two IP stacks at least on the downstream side does not seem likely even if it does claim EU DOCSIS 3.0 certification...

---

Morgaine wrote:

I see no IPv6 router advertisements coming from my Hub 3.0, but this may be because I run it in Modem Mode.  My Billion BiPAC 6300NX router is configured for combined IPv4+IPv6 operation, dynamic IP assignment, and with "Obtain IPv6 DNS" enabled, so I'd expect any Virgin ULA addresses required for communication with ISP infrastructure to be advertised to the router and a corresponding ULA prefix delegated to it.  My Billion hasn't received any IPv6 advertisements from the VM modem at all though, neither global, ULA, nor even link-local.

 

I'm running it in router mode (not got round to configuring modem mode yet). I wouldn't expect it to hand out ULA config in modem mode, as ULAs are for internal networks only; They don't route traffic out on to the internet. My guess for this configuration would be that the Hub will see how many devices are IPv6 aware and they'll use that to try and gather stats and iron out any kinks before enabling routable addresses

I'm still on the same version you are (9.1.116V)

@matthewsteeples:  If Virgin has chosen to implement their IPv6 distribution network using ULAs (exactly the kind of role for which they are intended) and one of these ULAs is the IPv6 gateway address for a set of customers in a given area, then in Modem Mode this gateway address would have to be handed to the customer's router in the same DHCPv6 exchange that hands them their delegated public address prefix.

As the name implies, in Modem Mode the Hub 3 is not a router, only a modem, so the customer's router does not route to the Hub 3 as its default IPv6 gateway but to a router further upstream, which in this case would bear a Virgin ULA.  This ULA can't avoid being communicated to the customer's router when Hub 3 is in Modem Mode.  Without it, the customer's delegated public IPv6 addresses would have no default gateway through which to reach the outside world.

It's a separate issue whether a Virgin ULA prefix also needs to be delegated to the CPE, but it's easy to find scenarios where it might:  for example, Hub 3 has two telephony sockets on the back and we know that Virgin is moving into phone territory, so one possibility is that IP phones on the Virgin service will each need their own Virgin ULA which is why you're currently seeing an ULA prefix on Hub 3 in Router Mode.  In this particular scenario the Virgin ULA prefix would be tied to their telephony equipment and hence it would remain on Hub 3 and not be delegated to the customer's router when in Modem Mode.  (This would explain perfectly why I don't see such an ULA prefix here on my Billion router behind the Hub 3 modem, assuming that telephone functionality is present in my VM area.)

In other scenarios however, it's entirely conceivable that an ISP might want to extend their IPv6 distribution network further into customer premises, for example for tied-content video delivery to smart HDTVs.  In this case their ULA prefixes would be delegated to customer routers (alongside the customer's global address prefix) even when their hubs are in Modem Mode, effectively extending ISP "internal" infrastructure into homes as far as IPv6 addressing is concerned.

We can't tell at this stage what Virgin is doing, but there are many different ways of using ULAs.

---

Morgaine wrote:

matthewsteeples:

As the name implies, in Modem Mode the Hub 3 is not a router, only a modem, so the customer's router does not route to the Hub 3 as its default IPv6 gateway but to a router further upstream, which in this case would bear a Virgin ULA.  This ULA can't avoid being communicated to the customer's router when Hub 3 is in Modem Mode.  Without it, the customer's delegated public IPv6 addresses would have no default gateway through which to reach the outside world.

---

My ULA doesn't have a default gateway assigned (I currently only have IPv4 connectivity to the internet). You'd only use that configuration if you were planning on offering IPv6 on a NAT basis (which would be ludicrous, and a lot more hassle than it's worth). Because of this, the hub (as a router) can hand out these addresses without receiving notice of them from the upstream systems (as they're local to my network only) and they may just be set as a configuration flag instead. ULAs and publicly accessible IPv6 addresses are for different purposes, and ULAs are not required for public IPv6 to work. It could be for internal infrastructure (as you've mentioned) but there'd be no real reason to use ULAs in favour of public IP addresses; It would be an additional set of services to configure, and would cause issues with consumer devices having 2 IPv6 addresses with 2 default gateways.

@matthewsteeples  writes:

My ULA doesn't have a default gateway assigned (I currently only have IPv4 connectivity to the internet). You'd only use that configuration if you were planning on offering IPv6 on a NAT basis (which would be ludicrous, and a lot more hassle than it's worth).
...
It could be for internal infrastructure (as you've mentioned) but there'd be no real reason to use ULAs in favour of public IP addresses

I think you may be conflating two different things in this discussion, provision of end-user global IPv6 prefixes (which have to be global otherwise end-user hosts would not have public IPv6 addresses) and what we're discussing here, namely provision of ISP ULA prefixes on CPEs for use with ISP infrastructure.  Infrastructure use doesn't need to be public so ULAs are fine, and NAT is most definitely not needed.  I gave two examples of such use by an ISP, and neither of them requires public addressing nor NAT.

What's more, such application of ULAs provides an ISP or any company or even an ambitious home user with very important benefits, especially greater immunity to attacks.  Because ULAs are not routable over the public Internet, equipment which uses them cannot be the target of directly addressed attacks from remote parties, and hence exposes only the much smaller attack surface of susceptibility to packets that it is forwarding.  This is of great benefit in these bad times when malicious actors are everywhere.  That's the main reason why ULAs have been defined.

Viewed in this light, the use of ULAs by ISPs is perfectly understandable and even recommended, and to our own benefit as customers.  When our ISP's infrastructure gets attacked, it doesn't do us any good either.  That's why I wouldn't be at all surprised if Virgin are deploying ULA prefixes to CPEs matching that on their distribution equipment, alongside the public prefix delegated to each customer.  It's likely to be far more robust than if they were using global addressing throughout.