IPv6 support on Virgin media

Sunday update --- The fast rise we noted a fortnight ago continues, at a very uniform pace.

This remarkably steady rate of growth is reminiscent of the straight line that we saw throughout February and March. We attributed that linearity to rollout of network equipment, because trialist populations rarely increase linearly whereas a small team of engineers deploying equipment across the country would produce near-constant growth. There are no regular dips in the curve coinciding with weekends so it would appear that they're working non-stop, perhaps suggesting that it's a high-priority project, if this guess is correct. We'll probably never know of course, but it seems possible in the absence of a better hypothesis.

Today's count stands at 5,391 per day.

Morgaine.

Someone who went to a recent UK IPv6 council about a month ago told me that Virgin had hired a new manager of the IPv6 transition, which is to happen 'by the end of the year'.  How I laughed.  Apparently they lost the people who were doing the transition, so had to re-hire before they could restart.

Anyway, looks like 'end of the year' might be a thing for the start of the transition, if not the end of the transition.

Interesting comment, and I hope you're right, @impromptu.

I'll stick to being hopeful, just because being realistic based on VM's past record over the years is too depressing. :(

I don't know if this is any indication of anything but my internet cut off for around two hours and when it came back online my router is pulling a link-local ipv6 address through the wan interface of fe80::201:5cff:fe82:447 and nmap puts it as Cadant routing equipment using the bgp protocol.

[2.4.4-RELEASE][admin@pfSense.network.dev]/root: nmap -6 fe80::201:5cff:fe82:447
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-01 03:25 GMT
Nmap scan report for fe80::201:5cff:fe82:447
Host is up (0.0090s latency).
Not shown: 999 filtered ports
PORT    STATE SERVICE
179/tcp open  bgp
MAC Address: **:**:**:**:**:** (Cadant)

---

MichaelL01 wrote:

I don't know if this is any indication of anything but my internet cut off for around two hours and when it came back online my router is pulling a link-local ipv6 address through the wan interface of fe80::201:5cff:fe82:447 and nmap puts it as Cadant routing equipment using the bgp protocol.

[2.4.4-RELEASE][admin@pfSense.network.dev]/root: nmap -6 fe80::201:5cff:fe82:447
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-01 03:25 GMT
Nmap scan report for fe80::201:5cff:fe82:447
Host is up (0.0090s latency).
Not shown: 999 filtered ports
PORT    STATE SERVICE
179/tcp open  bgp
MAC Address: **:**:**:**:**:** (Cadant)

 

---

Arris Cadant make the CMTS hardware.

Or go to http://ipv6-test.com/ and see if it says you have ipv6.

---

Dagger2 wrote:
Link-local addresses are self-assigned, not pulled from anywhere... or do you mean you have a default route assigned? In which case it's still not being pulled (default routes are advertised) but that would be a lot more interesting. If you can get a copy of rdisc6 and run it against your WAN interface then it might give a little bit more info.

---

yes I believe so? it is a route to the CMTS system the same one that is issuing my ip4 address, here is the output of rdisc6 if it sheds some light on anything.

[2.4.4-RELEASE][admin@pfSense.network.dev]/tmp: rdisc6 re0
Soliciting ff02::2 (ff02::2) on re0...

Hop limit                 :    undefined (      0x00)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         9000 (0x00002328) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Prefix                   : 2a02:8800:f000:d23::/64
  On-link                 :          Yes
  Autonomous address conf.:           No
  Valid time              :      2592000 (0x00278d00) seconds
  Pref. time              :       604800 (0x00093a80) seconds
 Prefix                   : 2a02:88fd:d:4::/64
  On-link                 :          Yes
  Autonomous address conf.:           No
  Valid time              :     infinite (0xffffffff)
  Pref. time              :     infinite (0xffffffff)
 from fe80::201:5cff:fe82:447

andrewducker wrote:

Or go to http://ipv6-test.com/ and see if it says you have ipv6.

 I don't have a public ipv6 address assigned nor is my router issuing any addresses to clients, i just see the link-local address of CMTS but it isn't issuing me an address and it is the only outside ipv6 system I can access.

---

MichaelL01 wrote:

---

Dagger2 wrote:
Link-local addresses are self-assigned, not pulled from anywhere... or do you mean you have a default route assigned? In which case it's still not being pulled (default routes are advertised) but that would be a lot more interesting. If you can get a copy of rdisc6 and run it against your WAN interface then it might give a little bit more info.

---

yes I believe so? it is a route to the CMTS system the same one that is issuing my ip4 address, here is the output of rdisc6 if it sheds some light on anything.

[2.4.4-RELEASE][admin@pfSense.network.dev]/tmp: rdisc6 re0
Soliciting ff02::2 (ff02::2) on re0...

Hop limit                 :    undefined (      0x00)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         9000 (0x00002328) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Prefix                   : 2a02:8800:f000:d23::/64
  On-link                 :          Yes
  Autonomous address conf.:           No
  Valid time              :      2592000 (0x00278d00) seconds
  Pref. time              :       604800 (0x00093a80) seconds
 Prefix                   : 2a02:88fd:d:4::/64
  On-link                 :          Yes
  Autonomous address conf.:           No
  Valid time              :     infinite (0xffffffff)
  Pref. time              :     infinite (0xffffffff)
 from fe80::201:5cff:fe82:447

andrewducker wrote:

Or go to http://ipv6-test.com/ and see if it says you have ipv6.

 I don't have a public ipv6 address assigned nor is my router issuing any addresses to clients, i just see the link-local address of CMTS but it isn't issuing me an address and it is the only outside ipv6 system I can access.

---

:smileyhappy: woohoo! A sign of progress!

Unfortunately it looks the same as I reported back in January so I wouldn't read too much into it. Proves a chunk of infrastructure is at least ready to take part.

---

MichaelL01 wrote:

 I don't have a public ipv6 address assigned nor is my router issuing any addresses to clients, i just see the link-local address of CMTS but it isn't issuing me an address and it is the only outside ipv6 system I can access.

---

I get the same thing.  But aren't you getting two /64s assigned - 

2a02:8800:f000:d23::/64
2a02:88fd:d:4::/64

The two address I get are similar - top one from the same /48, bottom one from the same /32.  My CMTS is fe80::201:5cff:fe86:ac47

I don't know if Virgin plan to do DHCP6, but I'd have thought with those it would be enough to autoconfigure an address, if that wasn't turned off.

I tried assigning myself an IP address based on either of my two /64s and setting a default route to the CMTS using its link-local address.  I can ping it via  link-local, but traceroute can't get beyond it and needless to say I can't reach the Internet.

Edit: I also notice that VM are currently advertising prefixes 2a02::8801::/32 and 2a02:8880::/25 to BGP. The first of my prefixes isn't in an advertised range but the second is.

What you folks are logging is very interesting from the standpoint of IPv6 address planning. I like the symmetry between Virgin's and BT's /25 IPv6 RIPE allocations, which hopefully will help us keep our multi-homed systems tidy, avoiding excessive wear and tear on the brain :P :

BT prefix : 2a00:2380::/25 -- https://www.bgpview.io/asn/2856#prefixes-v6
VM prefix : 2a02:8880::/25 -- https://www.bgpview.io/asn/5089#prefixes-v6

As I described back in September in answer to @Adduxi, if our /56 delegations come out of those large /25 blocks then the leading 6 hex digits (6*4 = 24 bits) of our addresses will always be 2a00:23 (BT) or 2a02:88 (VM), and the 25th bit will always be a 1 (never a 0), so our 7th hex digit will always be in the range from '8' through to 'f'. Simple and tidy.

That 7th hex digit and the next 7 digits will be the varying part of our individual /56 prefixes (6 + 1 + 7 = 14 hex digits == 14*4 = 56 bits), so the addressing layout I described in that post applies nearly identically to Virgin. However, there appears to be a difference in the schemes chosen for CPE management assignments, as Virgin seems to have chosen Block fd instead of Block 01 --- I'm going to assume that this means that they've assigned the top 3 /64 blocks for management or other predefined uses, namely Block fd through Block ff (although engineers prefer powers of 2 so Block fc might be pre-allocated too).

So here's a guess at our forthcoming IPv6 assignments but this time using VM's prefix. As before, a delegation of /56 provides 256 blocks of /64:

2a02:88xx:xxxx:xx00::/64 - Block 00 - Probably on CPE's LAN interface and switch
2a02:88xx:xxxx:xx01::/64 - Block 01 - First block available for domestic routing
.... 249 more /64 blocks
2a02:88xx:xxxx:xxfb::/64 - Block fb - Last block available for domestic routing
2a02:88xx:xxxx:xxfc::/64 - Block fc - Unknown use, possibly reserved, or free
2a02:88xx:xxxx:xxfd::/64 - Block fd - CPE management, possibly WAN routing too
2a02:88xx:xxxx:xxfe::/64 - Block fe - Unknown use, possibly reserved
2a02:88xx:xxxx:xxff::/64 - Block ff - Unknown use, possibly reserved

If this is indeed Virgin's general IPv6 assignment scheme for customer delegations then I actually prefer it to BT's, as it keeps CPE management out of the way of domestic routing. Since Hub 3.0 has telephony sockets, one or more top blocks could be used for VoIP for example.

Hopefully the days of trialing and the NDAs that seem to go with it will soon be over and we'll know the address assignment with certainty. The friendly and helpful symmetry at the level of /56 seems highly likely though, since that's determined by RIPE allocations.

Morgaine.

Interesting. Two prefixes is a bit weird but not necessarily wrong; even though 2a02:8800:f000:: is unreachable from the internet it may still have some valid purpose (VoIP/IPTV/management?). Both of those prefixes are marked "Autonomous address conf.: No" so your router won't configure itself an address from either of them.

However there's "Stateful address conf.: Yes" and "Stateful other conf.: Yes" which indicates that you should be able to fetch an address by DHCPv6. I don't know if pfSense will do that automatically (and to get v6 on your LAN rather than just your WAN interface, you'd also need to do a DHCPv6-PD request to get a routed block -- RAs don't provide any indication of whether you can do that so you basically just have to blindly try it.)

I'm still not completely convinced we'll see v6 on Virgin this side of 2020, but it looks like there's some justification for a bit of optimism.

---

Morgaine wrote:

What you folks are logging is very interesting from the standpoint of IPv6 address planning. I like the symmetry between Virgin's and BT's /25 IPv6 RIPE allocations, which hopefully will help us keep our multi-homed systems tidy, avoiding excessive wear and tear on the brain :P :

BT prefix : 2a00:2380::/25 -- https://www.bgpview.io/asn/2856#prefixes-v6
VM prefix : 2a02:8880::/25 -- https://www.bgpview.io/asn/5089#prefixes-v6

 

As I described back in September in answer to @Adduxi, if our /56 delegations come out of those large /25 blocks then the leading 6 hex digits (6*4 = 24 bits) of our addresses will always be 2a00:23 (BT) or 2a02:88 (VM), and the 25th bit will always be a 1 (never a 0), so our 7th hex digit will always be in the range from '8' through to 'f'. Simple and tidy.

That 7th hex digit and the next 7 digits will be the varying part of our individual /56 prefixes (6 + 1 + 7 = 14 hex digits == 14*4 = 56 bits), so the addressing layout I described in that post applies nearly identically to Virgin. However, there appears to be a difference in the schemes chosen for CPE management assignments, as Virgin seems to have chosen Block fd instead of Block 01 --- I'm going to assume that this means that they've assigned the top 3 /64 blocks for management or other predefined uses, namely Block fd through Block ff (although engineers prefer powers of 2 so Block fc might be pre-allocated too).

So here's a guess at our forthcoming IPv6 assignments but this time using VM's prefix. As before, a delegation of /56 provides 256 blocks of /64:

2a02:88xx:xxxx:xx00::/64 - Block 00 - Probably on CPE's LAN interface and switch
2a02:88xx:xxxx:xx01::/64 - Block 01 - First block available for domestic routing
.... 249 more /64 blocks
2a02:88xx:xxxx:xxfb::/64 - Block fb - Last block available for domestic routing
2a02:88xx:xxxx:xxfc::/64 - Block fc - Unknown use, possibly reserved, or free
2a02:88xx:xxxx:xxfd::/64 - Block fd - CPE management, possibly WAN routing too
2a02:88xx:xxxx:xxfe::/64 - Block fe - Unknown use, possibly reserved
2a02:88xx:xxxx:xxff::/64 - Block ff - Unknown use, possibly reserved

 

If this is indeed Virgin's general IPv6 assignment scheme for customer delegations then I actually prefer it to BT's, as it keeps CPE management out of the way of domestic routing. Since Hub 3.0 has telephony sockets, one or more top blocks could be used for VoIP for example.

Hopefully the days of trialing and the NDAs that seem to go with it will soon be over and we'll know the address assignment with certainty. The friendly and helpful symmetry at the level of /56 seems highly likely though, since that's determined by RIPE allocations.

Morgaine.

---

Calm down, calm down! The important part for you to remember is to keep a few fireworks aside to celebrate native IPv6 connectivity being granted to you. I hope you didn't burn them all already 😱😱. ;-)

Oh dear, thanks for that input, @Dagger2!  It forced me to look again when I saw you write "two prefixes", as my guess was based on the normal situation of a single publicly routable prefix being used, ignoring ULAs since they're not publicly routable.  I knew that AS5089 had a /25 and a /32 visible in BGPview, but assumed that only the larger /25 was in play for customer allocations.

Sure enough, I misread the two addresses that MichaelL01 logged, and misread them badly.  The "fd" digits in the address didn't refer to block fd of a /56 delegation at all but to 2a02:88fd in VM's /25, and the other address isn't even in that prefix but in the lower half of the parent prefix 2a02:8800::/24.  That invalidates my guess about Virgin CPE assignments entirely.  Sorry, I need a visit to the optician. :-(

Although using two prefixes may be unusual, it does have merit:

• It keeps CPE management addressing entirely separate from customer delegations, at the cost of keeping them in sync.

• It makes all 256 of the /64 blocks of a customer's /56 space available for domestic routing.  Not significant, but a benefit nevertheless.

Fortunately the symmetry between VM and BT /25 prefixes still stands, and from my own past experience I will find that useful in multi-homing.

How about some praise for the people working hard on this on the ISP side, who may not be able to talk about it. We know something is going on, so thank you VM engineers.

Don't forget that VM management may still kill the IPv6 project, no matter how much hard work the engineers put into it.  You shouldn't be counting your chickens just yet, unless you have an authoritative source of information for believing that it will happen soon. :-)   That is particularly so in this thread where we've "enjoyed" so many years of disappointment that we've learned from bitter experience not to expect too much.

I will certainly praise the VM engineers, and I will do so wholeheartedly, but only once IPv6 is released as a supported product and it works.  Not before.

For now, the only praise goes to APNIC for giving us the raw data on IPv6 activity in AS5089 while Virgin Media refuses to talk to its customers about it.

---

TonyJr wrote:

How about some praise for the people working hard on this on the ISP side, who may not be able to talk about it. We know something is going on, so thank you VM engineers.

---

I took my car to get a new tyre recently, after it was done I should have wrote a letter to the pressure gauge manufacture thanking them for making it possible for the mechanic to put the correct pressure in.  After all, they too were producing something no one really needed.

Just saying. 

Anyhow, I am glad that there's signs the deployment is growing.  I would say baby steps, but sadly most children who were in the womb at the time these things started to happen, well, they are in the middle of primary school now lol.  I would like to thank Morgaine for keeping us up to date.

It is interesting how VM have really sat back on this stuff for so long.  They did the same when Liberty Global (VM Owners) stated they were making a move to DS 3.1, VM have stepped back and said there's no plans to even test it in the UK yet.  Liberty Global are now offering "Gigabit" HFCN as a actual product - so it's well past testing phase!...

Sadly I have been around long enough to see some really bad things, and while I might be quite sour overall in regards to how VM has been ran, the product itself has never had any major faults.

If you look back you can see that they always leave everything to the last minute to do, and sometimes it goes wrong.  PHORM, Cloned Modems, IPv6, Legacy Equipment not getting upgraded even though it would benefit the network and user both.  There will come a point when they think forward instead of looking backward.  That time is not now.

TalkTalk will have IPv6 before VM.

What will be depressing is that IPv6 will come when it's like that pressure gauge.  VM Tech support staff are generally not that techie, so once IPv6 deploys on VM network you can be sure that the service center is going to go into meltdown.  Had they rolled out support early on then it would have given them time to test and fix issues.  As it stands now, they are just going to turn it on one day and hope.

True.

Was just thinking that back when I first joined Telewest in late 2000 they used to be progressive and open. I used to get a regular newsletter with service updates and future plans for the network. It was great. Since that died a death in the mid-2000s everything is so much more conservative and secretive. BT and Sky both seem to be able to be more open about what they do. I guess it comes down to a pretty fundamental corporate culture rather than competitive or commercial concerns. Very sad.

---

MichaelL01 wrote:

I don't know if this is any indication of anything but my internet cut off for around two hours and when it came back online my router is pulling a link-local ipv6 address through the wan interface of fe80::201:5cff:fe82:447 and nmap puts it as Cadant routing equipment using the bgp protocol. <snip>

Hmmmm, I wonder if I turn on DHCPV6 on my Vigor DualWAN router will I pick up a VM one as well ?

I already have one from BT, so another one is bound to help ;)

I might give that a go later this evening.

Give it a try but my router (OpenWRT) is periodically sending out DHCPv6 requests and doesn't get anything back. They're controlling access to the infrastructure to just trial participants for now it seems.

---

VMCopperUser wrote:

---

TonyJr wrote:

How about some praise for the people working hard on this on the ISP side, who may not be able to talk about it. We know something is going on, so thank you VM engineers.

---

I took my car to get a new tyre recently, after it was done I should have wrote a letter to the pressure gauge manufacture thanking them for making it possible for the mechanic to put the correct pressure in.  After all, they too were producing something no one really needed.

Just saying. 

Anyhow, I am glad that there's signs the deployment is growing.  I would say baby steps, but sadly most children who were in the womb at the time these things started to happen, well, they are in the middle of primary school now lol.  I would like to thank Morgaine for keeping us up to date.

It is interesting how VM have really sat back on this stuff for so long.  They did the same when Liberty Global (VM Owners) stated they were making a move to DS 3.1, VM have stepped back and said there's no plans to even test it in the UK yet.  Liberty Global are now offering "Gigabit" HFCN as a actual product - so it's well past testing phase!...

Sadly I have been around long enough to see some really bad things, and while I might be quite sour overall in regards to how VM has been ran, the product itself has never had any major faults.

If you look back you can see that they always leave everything to the last minute to do, and sometimes it goes wrong.  PHORM, Cloned Modems, IPv6, Legacy Equipment not getting upgraded even though it would benefit the network and user both.  There will come a point when they think forward instead of looking backward.  That time is not now.

TalkTalk will have IPv6 before VM.

What will be depressing is that IPv6 will come when it's like that pressure gauge.  VM Tech support staff are generally not that techie, so once IPv6 deploys on VM network you can be sure that the service center is going to go into meltdown.  Had they rolled out support early on then it would have given them time to test and fix issues.  As it stands now, they are just going to turn it on one day and hope.

---

Its not really that interesting, as it stands the internet will continue to function with IPv4, none of the big players will be affected for a long while to go, VM also already have a massive monopoly on speeds so there really isn't any incentive for them to keep upping speeds, ADSL can't compete and gigabit is only available in certain locations, VM would need some sort of actual competition for them to make any drastic changes, and that isn't going to happen

the internet will continue to function with IPv4, none of the big players will be affected for a long while to go.

But that's not actually what's happening, quite the opposite in fact.  It's the big players who are driving the change towards IPv6, while the small fry drag their feet and rationalize away their inertia with a variety of sometimes funny excuses.  The only reasonable one I've heard so far is "Our IPv6 firewall isn't ready yet", but that's not a card that can be played for too long, and it's not an excuse for not preparing one's IPv6 infrastructure internally.

It is easy to verify that it is the big players who are driving IPv6 deployment.  Google and Facebook carry an immense amount of traffic as network application endpoint providers, and their user base isn't narrowly techie or specialist but cuts across the entire world cross-section of Internet users so it's representative of both "big player" providers and their huge user bases.  LinkedIn has a more enterprise-themed audience, but is nevertheless a big player with a very large user base.  All of these companies also happen to publish useful statistics about their IPv6 usage:

• Google: "IPv6 connectivity among Google users" passed through 25% a few days ago, and this growth lies on a fast upward curve.

• Facebook: "Internet traffic over IPv6" recently reached 22.5% and is likewise steadily rising.

• LinkedIn: "In the U.S. we now pass 50% IPv6 usage on weekends across all devices", and around 40% for Germany.

That the big players are driving IPv6 adoption is also well described in the Internet Society's State of IPv6 Deployment 2018 publication, from which I've extracted a few snippets:

• Over 25% of all Internet-connected networks advertise IPv6 connectivity.

• Alexa Top Million Websites: 17% with working IPv6 (up from 13% in 2017)

• Alexa Top 1,000 Websites: 28% with working IPv6 (up from 23% in 2017)

And from the same Internet Society publication, three paragraphs which nail it:

Facebook reports that they are in the process of turning IPv4 off within their datacentres; IPv4 and IPv6 from outside comes to their load balancers, and behind them it is only IPv6. The effect has been operational improvements and innovation in their software. Other companies, including LinkedIn and Microsoft, have similarly stated an intention to turn IPv4 off within their networks.

Microsoft is taking steps to turn IPv4 off, running IPv6-only within the company. Their description of their heavily translated IPv4 network includes phrases like “potentially fragile”, “operationally challenging”, and with regard to dual stack operations, “complex”. The summary of their logic is both telling and compelling:

“Hopefully, migrating to IPv6 (dual-stack) is uncontroversial at this stage. For us, moving to IPv6-only as soon as possible solves our problems with IPv4 depletion and address oversubscription. It also moves us to a simpler world of network operations where we can concentrate on innovation and providing network services, instead of wasting energy battling with such a fundamental resource as addressing.”

It doesn't leave any doubt about where the big players stand.  They're blasting ahead with IPv6 at warp speed, and internally towards IPv6-only.

Morgaine.

EE Mobile Network Operator reaches 1 million daily on IPv6 (APNIC)

The UK mobile network operator EE Limited has today (7 Nov 2018) reached and exceeded 1 million daily IPv6 usage counts as measured by APNIC (1,001,735) --- well done EE! :-)

Although these round number milestones are arbitrary, they do track the growth of IPv6 deployment in the UK very nicely, and in a timely fashion. EE also has the distinction of being far ahead of any other UK mobile operator in their use of IPv6, and as a division of BT Group, this helps cement their future growth in a world of dwindling IPv4 addresses.

What's more, EE's IPv6 deployment currently puts them in a very commendable 3rd spot among the entire set of UK ISPs, as Virgin Media has yet to roll out its IPv6 service among the UK's "Big Three". That said, APNIC counts show that Virgin has an active IPv6 trial in progress, so this situation could change soon. The current status is shown in the accompanying graphic.

For today's nice milestone reached, congratulations EE! :-)

Morgaine.

PS. I posted this note in the UK IPv6 Council group at LinkedIn earlier today.  (I'll never understand why a bunch of IPv6 enthusiasts wanting to promote the adoption of IPv6 in the UK would want to operate a non-open forum, very peculiar. :P)