IPv6 support on Virgin media

For completeness, here are today's APNIC figures for UK AS-numbers IPv6 usage for the UK's "Big Three" ISPs ranked by their number of observed user counts:

AS-Company        Users         IPv6-Users   %UK-IPv6
==========      ==========      ==========   ========
VIRGIN          15,086,097           8,219       0.05
SKY             14,895,928      13,633,350      82.54
BT              10,429,227       2,647,048      16.03

BT has got itself stuck in the 2.6 millions again --- it happened once before, in July, but that was caused by a network fault which is believed to have been fixed, whereas the current one seems to be related to their inability to enable IPv6 on BT Home Hub 5.  With this new freeze on BT IPv6 growth, Virgin currently has an opportunity to enable IPv6 and shoot far ahead of them, and indeed ahead of Sky as well.  It would be a good time for it.

BT's IPv6 usage has just passed the 3 million mark of daily counts as measured by APNIC:

DATE         AS      Users      IPv6-Users  %UKv6
==========   ==      ========== ==========  =====
2018_02_18:  BT      10,652,846 2,993,510   18.47
2018_02_19:  BT      10,651,980 3,015,684   18.63

Well done BT!  IPv6 kudos earned. :)

In the context of the UK's "Big Three" residential ISPs, BT continues to hold its previous IPv6 ranking, second to Sky's massive lead but well ahead of Virgin Media's still unreleased public IPv6 service --- I've been hoping that the 6,490 Virgin counts indicate that an undisclosed IPv6 trial is in progress at VM, but there has been no confirmation of this yet, not even an unofficial one:

ISP-AS            Users         IPv6-Users   %UKv6
==========      ==========      ==========   =====
SKY             13,937,631      12,772,577   78.89
BT              10,651,980       3,015,684   18.63
VIRGIN          14,704,336           6,490    0.04

Reaching another IPv6-millions milestone is great news for BT and for the UK, but it should be mentioned that BT's IPv6 usage counts could have been very much higher by now. Their announcement to the UK IPv6 Council in July of 2017 that enabling their most common CPE device (Home Hub 5) for IPv6 was "imminent" raised the hopes of IPv6 fans greatly, but unfortunately that never materialized. In addition, BT provides no support for when IPv6 disappears from a residential line, and in fact doesn't even acknowledge its existence when you try to file a fault report. Clearly there is much that still remains to be done.

Despite that, 3 million is a very nice milestone to have reached --- well done BT!

APNIC daily IPv6 stats for the UK are published here: https://stats.labs.apnic.net/cgi-bin/v6pop?c=GB

Now we just need Virgin to join in the IPv6 fun. :)  The UK needs this, IPv4 is holding us back.

Morgaine.

---

Morgainewrote:

Now we just need Virgin to join in the IPv6 fun. :)  The UK needs this, IPv4 is holding us back.

 

---

Holding us back from what exactly, i mean the change over to v6 is pretty much just to ease the strain on the now limited v4 addresses that are available, chances are any major sites already have or can get hold of a v4 address, are there any important sites that are only doing v6? :P

Its not like v4 support is going to go away any time soon and the internet won't suddenly stop working

You can only reach https://loopsofzen.uk/ on IPv6

@shanematthews asks:
> Holding us back from what exactly, i mean the change over to v6 is pretty much just to ease the strain on the now limited v4 addresses that are available

Gosh no, that's only the beginning of it. It's true that the most commonly mentioned benefit of IPv6 is purely remedial --- to provide us with much more address space because IPv4 blocks ran out at the RiRs a while back --- but if that were all that IPv6 provides, there wouldn't be such widespread interest in it. Its most exciting promise is enabling totally new networking protocols and applications to be developed.

I detailed some of the future benefits of IPv6 in answer to questions similar to yours, so I might as well refer you to one of my posts on the topic --- message 283 in the current thread:

• https://community.virginmedia.com/t5/QuickStart-set-up-and/IPv6-support-on-Virgin-media/m-p/3189947#M62787

The last paragraph of that post hints at what I meant when I said that "The UK needs this, IPv4 is holding us back." We were actually one of the world leaders in networking technology at the dawn of the Internet, and we could be again. Unfortunately IPv4 has hampered the development of many interesting classes of protocols because NAT broke both end-to-end reachability and protocol transparency in IPv4.

That has had an extremely detrimental effect on the topology of the Internet, making it change from its original highly decentralized form into a heavily centralized one, because IPv4's NAT makes most people's hosts not reachable so they're forced to connect outwards to centralized servers. In addition, with NAT in the way, CPEs often have to be specially modified by their manufacturers to allow useful protocols to pass through, which is a major showstopper for protocol development. In effect, IPv4 severely constrained networking to a narrow subset of possibilities, while IPv6 lets evolution in networking start again.

Many of the ills of the Internet stem from what IPv4 has forced upon it, including mass surveillance at centralized sites, an almost total absence of federated protocols which would have put power in the hands of end users, and the rise of online megacorps abusing user privacy for revenue on billion-user social networking sites. Although many things contributed to this unhappy situation, IPv4 played a central role in making centralization almost mandatory.

IPv6 avoids that faulty design, and if our ISPs don't drag their IPv6 heels too long and help the UK to become a major IPv6 player, we could become leaders in protocol and application development again, instead of followers.  In the process, we might even cure some of the Internet's many problems.

Morgaine.

Although networking developers intrinsically understand the huge benefits that result from end-to-end reachability and protocol transparency, it may not mean much to those who don't work in this area, so perhaps some examples might help.

Consider two types of application which are both rising stars today: Virtual Reality and Augmented Reality. Both of these benefit from participant reachability:

• In VR, participants are commonly agents who animate an avatar in a virtual world. In the bad old days of IPv4, lack of user reachability commonly meant that the virtual environment had to be held on a central server to which participants were forced to connect. Unfortunately, this is a recipe for world non-scalability and lag, and it also leads to centralized tracking, abuses of privacy, and the creation of walled gardens. With IPv6 there is no need for remedial architecture like central servers, because agents can interact directly with each other. This is not only faster because the middleman is eliminated and the aggregate bandwidth is enormously larger, but also safeguards people's privacy by limiting knowledge of agent interactions to the participants alone.

• In AR, the environment surrounding the user is typically augmented by digital information from elsewhere, which  requires knowledge of the user's environment. If the user's system is not directly reachable, once again connecting to a central server is usually required, but the impact of this is even worse than in VR because now the server has to be kept in sync with the state of the user's local environment as well. As before, the remote server introduces lag and harms privacy, and update delays create a poor user experience because any discrepancy between local and remote states is directly visible and breaks the illusion of an augmented real world. IPv6 eliminates the remote server bottleneck as it did in VR, and also provides a new ability: the virtually unlimited IPv6 address space allows every object modelled to have its own IP address, so protocols can be much more elegant and efficient, communicating directly object-to-object.

Considerations like this are only meaningful to developers, but the end result is that IPv6 gives end users much more capable and streamlined applications to enjoy. IPv6 is a much better base upon which to develop new protocols for VR and AR, and most other advanced areas of networking will benefit similarly. It goes far beyond "just more addresses". It's a transformative technology, and will transform the Internet.

Morgaine.

+1 Wot, (s)he said.

Whilst I miss not wasting time on Loops of Zen, the straightforwardness of establishing direct peer-to-peer connectivity between IPv6 hosts is something many IPv4-bound users are not going to get. Thank you Morgaine for given us just a couple of reasons why that Michaelson person is right...

---

antxxxxwrote:

You can only reach https://loopsofzen.uk/ on IPv6

---

Well i can access the site just fine on my VM connection and i don't have a public facing IPv6 :P

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

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.

@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.

---

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!

---

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.

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

---

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

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.

---

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.

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.

---

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...

@philjohn writes:

> "According to a news item on ISPReview.co.uk ..."

Good find, thanks!  I guess you mean this one:  "Some Background on Virgin Media’s UK IPv6 and DOCSIS 3.1 Plans" -- https://www.ispreview.co.uk/index.php/2018/02/update-virgin-medias-uk-ipv6-docsis-3-1-plans.html

> "... VM are doing the brain dead thing and going with DS-Lite."

Oh dear, that's not good.  I hope they've budgeted for massive support costs and non-stop truckloads of aspirin. :(

That said, there is still a tiny light at the end of the tunnel, in fact two of them:

1. That implementation of DS-Lite may not be the standard stateless one, but might instead be a stateful solution which reserves recently used public IPv4 addresses for a period.  During that reservation period it could assign that reserved public IPv4 address only if commanded to do so because the MAC address of the user's router was recognized in the access network.  This would preserve some compatibility with Virgin's current implementation and, most importantly, it would not break TCP connections by changing the user's IPv4 address on every hiccup in the access network.  (Yes, I know that this invites a comment of "And pigs will fly first", but it is at least a possibility, however remote.)
2. If DS-Lite turns Virgin's IPv4 into a total disaster, it could accelerate IPv6 adoption massively because the standard advice for any problem will become "Turn off your IPv4".  Unfortunately for VM, this will also lose them countless customers to BT and other ISPs who provide the better-behaved Dual Stack method over VDSL.  If so, Virgin will deserve their big fall in earnings by having ignored all user advice and making an ill-considered technical choice.

It'll be very unfortunate if ISPreview's information is accurate, particularly for gamers who are reliant on IPv4, but at least we'll finally get IPv6.

Morgaine.

Reading the Ispreview article I noted the following 

* Provides dual-stack to users without requiring any public IPv4 address to be assigned to the CPE, thus streamlining the deployment and management of IPv4.

Which indeed suggests they are going for the CGNAT option.

ModTeam  I have to express my extreme displeasure at this idea.  You are going to have A LOT of unhappy customers

There's some confusion here - but to clear it up, DS-Lite is built upon the use of CGNAT[1], because the core network becomes IPV6, with IPV4 encapsulated over IPV6 and terminated on the ISP equipment, where it's passed out onto the IPV4 internet using NAT.

So, not only do you have all the problems that CGNAT introduce, you also have the issue that VM will probably do what they do for business customers wanting a static address and route all IPV4 via London, so we'll be getting increased latency added to the mix.

Out of all the options they chose the 2nd worst (worst is no IPV6). Come on, BT have been successfully running a full-fat dual stack network for 2 years at this point, it's a solved problem.

I wonder how much money Liberty will be getting for selling their IPV4 allocations ...

[1] - https://tools.ietf.org/html/rfc6333

Yep. To deploy DS-Lite at this stage in the IPv6 migration seems daft. Plonking a CGN machine between users and a significant percentage of their IPv4 based content seems crazy. The recent focus on getting speeds up across the VM network will go backwards. Many of the big content providers CDNs are still doggedly IPv4 (e.g. BBC) so a lot of traffic is going to be going through those CGN boxes.

As a technology DS-Lite seems more suited for the end-game when the majority of the content providers (by traffic) have moved to IPv6 and the IPv4 Internet is headed for the graveyard.

It may be a daft question to ask at this point but what to the big US cable providers like Comcast do? The US transition to IPv6 is a lot further on than ours.

You don't even need to look to the US, there are cable companies owned by LG in europe and they are a mix of no IPV6, DS-Lite and full fat Dual Stack.

And closer to home, BT have been running a proper dual stack network for several years.

To be honest, I'd prefer until we're further along the transition that VM ran a 6-in-4 tunnel.

---

philjohnwrote:

You don't even need to look to the US, there are cable companies owned by LG in europe and they are a mix of no IPV6, DS-Lite and full fat Dual Stack.

And closer to home, BT have been running a proper dual stack network for several years.

---

and Sky, who are running Dual Stack and completed their IPv6 rollout over a year ago. They're the only major UK ISP to have the vast majority of customers on IPv6.

https://www.ispreview.co.uk/index.php/2016/09/uk-isp-sky-broadband-officially-finish-roll-ipv6.html

VM don't do themselves any favours with terrible decisions like this.