IPv6 support on Virgin media

[dgcarter]

Does anyone know whether (and if so when) Virgin plan to implement IPv6 on its network?

[Kippies]

Given that down the road from me VM.ie have a poor implementation of IPV6 and it causes as many issues as it solves (yes I understand thats the implementation), the long game may yet prove to be the best one.

The connectivity issue is easily resolved in IPV4  (anyone for DHT?)  and we lose the natural resilience of a NAT "firewall". So there are dpownsides if managed badly.

As someone who supports users day and daily IPV6 and IOT seem , well..... scary.

Especially given the average level of technical knowledge out there. And I do not  mean that disparagingly, network security is a complex subject. It becomes MORE complex once NAT is out of the equation.

I would also argue that the current state of play , especially the "centralised server" model so many IPV4 applications use is as much about commercial pressures as the protocol. Less "big data" payoff in a decentralised model.

Taking games as an example, theres no actual need for central servers in most cases. UDP is happy to match-make with no external input. However what it does take is good netcode and deviation from the "games as a service" model AAA gaming want to foist on the end user.That is  a commercial pressure, not a protocol issue.

Id love to believe the view that IPV6 will somehow right the wrongs of the current state of play. But  I remain unconvinced.

At the end of the day thats not an argument to NOT implement it. More of a cautionary "Hey lets not lose the run of ourselves" as we say round here.

Whilst a phased move to IPV6 would be a GOOD THING, lets not lose sight of the fact that it throws up as many challenges as opportunities.

[Morgaine]

@Kippies:  Fortunately a phased moved to IPv6 is what most of the world is doing, as Dual Stack is by far the most popular transition mechanism and it's also the one that is best able to accommodate a phased transition. The reason for this is that in Dual Stack the IPv4 and IPv6 stacks are (at least in principle) completely independent and coexist side by side on the same hardware, so each stack can be brought up and taken down without affecting the other. This makes performing tests and trials and upgrades and reverts about as risk-free as such complex things can ever be.

Of course the theory of "completely independent" stacks never works out quite that perfectly in practice, not through any fault with the concept of IP stack independence but because people accidentally hardwire-in dependencies between them which don't come to light until testing begins. Those of you who follow the meetings of UK IPv6 Council and of UKNOF will have noticed such issues described in the presentations. The good news is that it's rarely difficult to remedy the problem because beneath it all, the stacks truly are independent.

Regarding "the long game", I used to think as you do @Kippies, but no longer. I've now seen far too many company presentations explaining why they want to move as fast as possible to IPv6-only operation to still believe in the long game for IPv4.

The reasons for this are twofold and absolutely clear cut: money and pain. There is no company on this planet that wants to pay out more money than is strictly necessary nor to suffer high pain for its employees and customers, and seriously, who can blame them. When a company (especially an ISP) runs dual stacks internally, their equipment costs, power costs, maintenance costs, user-support costs, administration costs and their development costs are all significantly higher than when running just a single stack, often more than double because the dual stack system is more than twice as complex. And the pain ... well let's just say that engineers and managers generally prefer to sleep at night rather than be called out.

It's easy to see how the above promotes this kind of plan:  bring in IPv6 through the low-pain path of Dual Stack, but downgrade the IPv4 equipment progressively as more of the traffic moves to IPv6 --- very easy to do owing to the independent stacks. Then a few years down the road once IPv4 becomes a minority protocol, turn IPv4 provisioning into Software As A Service over DS-Lite, which requires IPv4 equipment only at the edges of the AS while the rest of the company can become IPv6-only. This is a win-win situation for an ISP, as it lets them continue to offer IPv4 to legacy customers while avoiding the costs and pain of running two stacks themselves. Also, it won't have escaped management's notice that IPv4 SaaS then becomes a small revenue stream through which legacy customers pay for their own upkeep while also encouraging them to migrate to IPv6. This is a very appealing business plan! 🙂

That's why I'm a bit more optimistic than yourself. Although transitions always introduce some pain, this one has very benign properties, it's already working very well worldwide, and strong pressure for an early end to the transition is already in very clear evidence.

Morgaine.

[TonyJr]

---

@Kippieswrote:

Given that down the road from me VM.ie have a poor implementation of IPV6 and it causes as many issues as it solves (yes I understand thats the implementation), the long game may yet prove to be the best one.

The connectivity issue is easily resolved in IPV4  (anyone for DHT?)  and we lose the natural resilience of a NAT "firewall". So there are dpownsides if managed badly.

As someone who supports users day and daily IPV6 and IOT seem , well..... scary.

Especially given the average level of technical knowledge out there. And I do not  mean that disparagingly, network security is a complex subject. It becomes MORE complex once NAT is out of the equation.

I would also argue that the current state of play , especially the "centralised server" model so many IPV4 applications use is as much about commercial pressures as the protocol. Less "big data" payoff in a decentralised model.

Taking games as an example, theres no actual need for central servers in most cases. UDP is happy to match-make with no external input. However what it does take is good netcode and deviation from the "games as a service" model AAA gaming want to foist on the end user.That is  a commercial pressure, not a protocol issue.

Id love to believe the view that IPV6 will somehow right the wrongs of the current state of play. But  I remain unconvinced.

At the end of the day thats not an argument to NOT implement it. More of a cautionary "Hey lets not lose the run of ourselves" as we say round here.

Whilst a phased move to IPV6 would be a GOOD THING, lets not lose sight of the fact that it throws up as many challenges as opportunities.

Excellent reply!

[tjure]

---

@Kippieswrote:

The connectivity issue is easily resolved in IPV4  (anyone for DHT?)  and we lose the natural resilience of a NAT "firewall". So there are dpownsides if managed badly.

This has been argued many times before, just google "ipv6 nat security". The gist is that when you use NAT you are automatically using a stateful firewall, hence removing the NAT but keeping the stateful firewall does not lower the security at all. Simply allow outgoing and established traffic and block all other (incoming) traffic. If you look at the rules of a typical NAT firewall, then these are exactly the rules that will be implemented, plus the additional complexity of the NAT address fiddling.

The only thing that NAT does is hiding your network topology to the outside. If you are concerned about that then you can have a look at IPv6 privacy extensions.

[ravenstar68]

@Kippies

and we lose the natural resilience of a NAT "firewall".

NAT was NEVER intended to be a firewall.  While some people mention it in this context, it should be noted that the driving force behind NAT introduction was to preserve IPv4 addresses.

Read RFC 1631 - https://tools.ietf.org/html/rfc1631 - From 1994

You can have hardware firewalls that do not utilise NAT and Windows Firewall has advanced to the point where it is both IPv4 and IPv6 aware.  In fact in many instances the firewall is set only to allow connections from the local subnet.  However the use of Teredo as a transition mechanism actually screws things up as it allows connections to tunnel past the Firewall.

This is demonstrated when you have IPv6 and Teredo interfaces running together and try blocking ICMPv6 Echo packets.  With Teredo enabled the PC still responds to pings from an external source.  Disable Teredo and Pings will only be accepted by machines running on the same subnet.

Once NAT had been worked out this allowed for the later development of 1918 Private network space.  But again the driving force behind this was not privacy, it was the extension of the Lifespan of the IPv4 protocol.  In some ways it worked too well.

Tim

[shanematthews]

---

@ravenstar68wrote:

Being as Loops of Zen is only accessible over IPv6 you must be accessing it via Teredo or some other tunnelling mechanism, whether your aware of this is another matter.

However Tunnelling mechanisms are only a stopgap.

Tim

---

You mean that thing that has been a standard feature of windows for many years now? all i'm using is the native stuff provided by my OS and whatever the hub2 provides, nothing more

[Morgaine]

In message 419 of this thread I described the interesting changes in Virgin IPv6 counts during 2017, which featured two periods of rapidly rising activity peaking at 10,301 counts on 2017-09-27, and 8,642 on 2017-12-13.  Just as interesting as the peaks themselves was the fact that the daily APNIC counts fell off only very slowly after each peak, suggesting that Virgin's IPv6 was already solid enough to remain available to trialists after each testing and feedback period was over.  (It hasn't been confirmed yet that these actually were trials, but that seems to be the most likely explanation, and it is certainly the most optimistic one.)

Well, there's something new happening now on the Virgin IPv6 front, and it's not the same as before. After the peak in December of 2017, APNIC's counts ebbed away slowly as mentioned, but they reached a low point of 5,682 on 2018_01_31 and then the curve reversed direction, today standing at 6,907:

DATE         AS      Users      IPv6-Users  %UKv6
==========   ==      ========== ==========  =====
2018_01_28:  VIRGIN  14,957,550      5,849   0.04
2018_01_29:  VIRGIN  14,809,098      5,717   0.04
2018_01_30:  VIRGIN  14,781,448      5,716   0.04
2018_01_31:  VIRGIN  14,748,917      5,682   0.03 <-- low mark
2018_02_01:  VIRGIN  14,743,973      5,715   0.04
2018_02_02:  VIRGIN  14,739,480      5,710   0.04
2018_02_03:  VIRGIN  14,731,270      5,725   0.04
2018_02_04:  VIRGIN  14,705,093      5,773   0.04
2018_02_05:  VIRGIN  14,704,523      5,808   0.04
2018_02_06:  VIRGIN  14,702,609      5,808   0.04
2018_02_07:  VIRGIN  14,708,031      5,821   0.04
2018_02_08:  VIRGIN  14,706,682      5,867   0.04
2018_02_09:  VIRGIN  14,716,978      5,911   0.04
2018_02_10:  VIRGIN  14,722,629      5,971   0.04
2018_02_12:  VIRGIN  14,705,966      6,057   0.04
2018_02_14:  VIRGIN  14,707,402      6,114   0.04
2018_02_15:  VIRGIN  14,716,623      6,154   0.04
2018_02_16:  VIRGIN  14,726,452      6,242   0.04
2018_02_18:  VIRGIN  14,693,299      6,422   0.04
2018_02_19:  VIRGIN  14,704,336      6,490   0.04
2018_02_21:  VIRGIN  14,899,536      6,738   0.04
2018_02_22:  VIRGIN  14,878,172      6,799   0.04
2018_02_23:  VIRGIN  14,859,484      6,808   0.04
2018_02_24:  VIRGIN  14,823,157      6,907   0.04

These are small growth figures in a UK ISP context and not immediate reason to get excited, but they do have me puzzled.

It's not a third IPv6 trial period because the growth is too slow, and it seems unlikely to be the result of new trialists joining the ranks because the growth seems too fast. The only hypothesis that seems semi-viable to me is that after the two successful trial periods, VM is now enabling internal employee usage of IPv6, one team or department or site at a time. However, I must admit that this is grasping at straws.

Does anyone have a more convincing explanation for this odd rate of growth?

Morgaine.

[TonyJr]

---

@Morgainewrote:

In message 419 of this thread I described the interesting changes in Virgin IPv6 counts during 2017, which featured two periods of rapidly rising activity peaking at 10,301 counts on 2017-09-27, and 8,642 on 2017-12-13.  Just as interesting as the peaks themselves was the fact that the daily APNIC counts fell off only very slowly after each peak, suggesting that Virgin's IPv6 was already solid enough to remain available to trialists after each testing and feedback period was over.  (It hasn't been confirmed yet that these actually were trials, but that seems to be the most likely explanation, and it is certainly the most optimistic one.)

Well, there's something new happening now on the Virgin IPv6 front, and it's not the same as before. After the peak in December of 2017, APNIC's counts ebbed away slowly as mentioned, but they reached a low point of 5,682 on 2018_01_31 and then the curve reversed direction, today standing at 6,907:

DATE         AS      Users      IPv6-Users  %UKv6
==========   ==      ========== ==========  =====
2018_01_28:  VIRGIN  14,957,550      5,849   0.04
2018_01_29:  VIRGIN  14,809,098      5,717   0.04
2018_01_30:  VIRGIN  14,781,448      5,716   0.04
2018_01_31:  VIRGIN  14,748,917      5,682   0.03 <-- low mark
2018_02_01:  VIRGIN  14,743,973      5,715   0.04
2018_02_02:  VIRGIN  14,739,480      5,710   0.04
2018_02_03:  VIRGIN  14,731,270      5,725   0.04
2018_02_04:  VIRGIN  14,705,093      5,773   0.04
2018_02_05:  VIRGIN  14,704,523      5,808   0.04
2018_02_06:  VIRGIN  14,702,609      5,808   0.04
2018_02_07:  VIRGIN  14,708,031      5,821   0.04
2018_02_08:  VIRGIN  14,706,682      5,867   0.04
2018_02_09:  VIRGIN  14,716,978      5,911   0.04
2018_02_10:  VIRGIN  14,722,629      5,971   0.04
2018_02_12:  VIRGIN  14,705,966      6,057   0.04
2018_02_14:  VIRGIN  14,707,402      6,114   0.04
2018_02_15:  VIRGIN  14,716,623      6,154   0.04
2018_02_16:  VIRGIN  14,726,452      6,242   0.04
2018_02_18:  VIRGIN  14,693,299      6,422   0.04
2018_02_19:  VIRGIN  14,704,336      6,490   0.04
2018_02_21:  VIRGIN  14,899,536      6,738   0.04
2018_02_22:  VIRGIN  14,878,172      6,799   0.04
2018_02_23:  VIRGIN  14,859,484      6,808   0.04
2018_02_24:  VIRGIN  14,823,157      6,907   0.04

These are small growth figures in a UK ISP context and not immediate reason to get excited, but they do have me puzzled.

It's not a third IPv6 trial period because the growth is too slow, and it seems unlikely to be the result of new trialists joining the ranks because the growth seems too fast. The only hypothesis that seems semi-viable to me is that after the two successful trial periods, VM is now enabling internal employee usage of IPv6, one team or department or site at a time. However, I must admit that this is grasping at straws.

Does anyone have a more convincing explanation for this odd rate of growth?

Morgaine.

---

Yes - it could be network infrastructure addressing.

[philjohn]

According to a news item on ISPReview.co.uk VM are doing the brain dead thing and going with DS-Lite.

So, Carrier Grade NAT for IPv4 and a proper IPV6 address ... wow, fantastic.

So, anyone using XBox live, PSN, Voip and/or running a VPN server on their edge router to be able to connect into their home network are going to have a "fun" time.

Seriously, trust VM to pick the *worst* possible transition method.

[TonyJr]

---

@philjohnwrote:

According to a news item on ISPReview.co.uk VM are doing the brain dead thing and going with DS-Lite.

So, Carrier Grade NAT for IPv4 and a proper IPV6 address ... wow, fantastic.

So, anyone using XBox live, PSN, Voip and/or running a VPN server on their edge router to be able to connect into their home network are going to have a "fun" time.

Seriously, trust VM to pick the *worst* possible transition method.

---

There is contradicting information on this:

- Your source states that CGNAT will be used.

- Earlier posts in this thread state that it will not be used as VM have more than enough v4 addresses in their allocations from the RIR.

We shall soon see what happens...