IPv6 support on Virgin media

I know this point is larger than VM, but while selling off IPv4 address space maybe attractive to bean counters, surely the continued availability of large chunks of space helps IPv4 to limp on, thereby undermining investments in IPv6. That seems to amount to a lot of injured feet?

---

mhmeadows63 wrote:

I know this point is larger than VM, but while selling off IPv4 address space maybe attractive to bean counters, surely the continued availability of large chunks of space helps IPv4 to limp on, thereby undermining investments in IPv6. That seems to amount to a lot of injured feet?

---

Selling off IPv4 doesn't remove them, it just moves them.  In a way (a bad one) you could probably extend IPv4's life to extend beyond mine.  If only content suppliers had IPv4 addresses and ISP customers were all NAT then it would push the number of available address through the roof.  Quite a few website providers these days use some form of NAT on their end these days too using SNI (Server Name Identification).

Virgin have had this view that they didn't want to move to IPv6 until IPv4 ran out.  Virgin are not alone in this (their parent company seems to have a different view) and all around the world there are huge ISPs that have not deployed.  That's one reason why we are stuck with things like SNI.  SNI was a way for content providers to get around not having IPv6, BUT they only need IPv4 because the ISPs refuse to give IPv6.

But now we are ending up with things like SNI (Content provider NAT) + CGNat (What we will get) and that means that Nat itself will start to see issues too I think.  Before you had that 65,536~ port limit Per IP... Now that you have NAT on both sides then that limit could be reached pretty quick.
Imagine for a moment that your home has 30 connections to Microsoft, That means if 2200 homes are sharing the same IP that some connections will start to be refused (as there are no more ports).  That doesn't sound too bad, but now imagine that it's christmas and Amazon, BBC, ITV, and Youtube are all using AWS on the same IP... That could mean that homes will see streaming services not work.  While I know this is unlikely, it is something that's possible and easy to see.Dual Stack (not DS-Lite) in my view would be the better solution.

I know Morgaine makes a few good points regarding not having a proper working Dual Stack setup, but the cost, technical knowledge, and complexity of networks is something that any ISP the size of VM should be able to cope with.  My biggest counter (and original) complain about any type of forced NAT is that it will cause a lot of support issues, and I can guarantee that when people phone up with issues relating to CGNAT that Virgin media phone staff (and most forum staff too sadly) will not be able to understand the issue or offer solutions.

For Comparison, Sky finished rolling out IPv6 2 years ago (Sep 16). ~6.2 million customers, and BT nearly 2 years ago (Nov 16). ~9.4 million customers.The big holdouts are Virgin Media and TalkTalk.  If there is anything that should get an ISP worried, it's being lumped in with TalkTalk.

I believe both Sky and BT rolled out Dual Stack.  So I guess there are some isp's that have competent network techs that can cope with it.

Historically speaking in the beginning IPv4 allocations were being given out far too casually, it was like "Hello small company A, you have 500 employees and 20 computers so we're giving you 10,000,000 IPV4 addresses!"

No foresight what so ever about shortage and many companies who never did and still don't are still sat on tens of millions of never ever used IPv4 addresses tot his very day.

Kind of looks like to me that they are repeating the same thing with IPV6, under-estimating how many devices people will have at home. Come 10 years from now, homes will have every single device online with their own built in web server each, including the kids alarm clocks etc. And about the year 2050 we may face the same situation, but the demand would be for the move to IPV7 to complete because people got too large IPV6 assignments in the 2020s.

Anyway, not entirely about IPV6, but just felt like posting about how IP allocation in the beginnings seems to lack foresight and often grossly underestimates how need will boom beyond what they could barely grasp.

Strange enough that...

MIT sold off a large (unused) block so they could fully pay for their IPv6 conversion.

But we should never use all of our IPv6.  Not before humanity dies that is.

---

VMCopperUser wrote:

Strange enough that...

MIT sold off a large (unused) block so they could fully pay for their IPv6 conversion.

But we should never use all of our IPv6.  Not before humanity dies that is.

---

Well that's good. If all the companies who got larger than what they needed IPV4 wise just sold it off now in a flash sale. It would push back the need for IPV6 quite a bit further. The problem we're experiencing now is because of an artificial shortage made possible by giving them too freely away in the beginning. They had the mindset they do now, that there was no possible way to run out. But they were proven wrong and will be proven wrong again with IPV6. Humans never learn from their mistakes.

With humans, they consume, whether it be media, trends, whatever. There's nothing too big for humanity to run short off. And more Internet tech will continue to slip into homes leading to the standard home in the near future to having thousands of internet connected devices simultaneously. Homes already commonly have hundreds of Internet connected devices. And that's not even talking smart homes where every facet of them will be online and internet connected+controlled vehicles etc

Edit: line adjusted.

There are some crazy penny pinching ISP out there trying to deploy one /64 per subscriber (I'm sure there are some who would wish to give /128s if only they could). Most seem to have settled on /56s which is enough for 256 networks. It doesn't take a lot of imagination to start eating into this. I saw a video a few months ago where someone from RIPE (the European IP address administrators) was recommending giving people /48s or worst case /56s but on /48 boundaries to save the inevitable but painful re-addressing years hence.

@davefiddes - what's your use case for the general population needing more than a /64? Unless you've got a router that can manage VLANs there's no benefit, and 99.99% of the population are going to be more than covered with the single network and the (approximately) 18,446,744,073,709,551,616 addresses contained within it. Once you start having multiple networks, you start needing admin/configuration and maintenance. If you're in the 0.01% of the population where you want to set up multiple networks, then there are still ISPs out there that will support that.

Before IANA ran out of v4 to allocate, back in 2011, we were going through over one /8 per month. That was back in 2011; demand has only gone up since then. If we could somehow get companies to give back their /8s, it would buy us... probably around 2 weeks per /8? That's very much not worth the effort.

Kind of looks like to me that they are repeating the same thing with IPV6

Nope, we're not. The standard allocation for an ISP is a /32, which consumes the same fraction of the v6 space that a single IP does of the v4 space. End users should be getting /48, which is the same fraction of the space that a single TCP port of a single v4 address is of the v4 space. We have enough space to give every person on the planet 5000 /48s (and each /48 is enough to number a substantial network with effectively unlimited hosts per subnet).

None of this is in any way similar to v4. If you think we're going to run out of v6 by 2050, then you haven't got your head around how large the v6 space is.

what's your use case for the general population needing more than a /64?

The use case is "to make multiple subnets possible, for whatever reason people come up with for using them". There is no good reason to prevent people from using more than one subnet, and plenty of reasons why people might want to do that (even though they might not understand what they're doing). For example, VM already ship routers with support for multiple guest WiFi networks, so that's a couple of extra /64s right there. How about routed virtual machine networks? VPNs? Cascaded routers (you might argue this is often a mistake, and often it is, but sometimes it isn't and in any case it should still work)? These are just the uses I can come up with now, and ISPs need to be giving blocks big enough for future uses too, not just current uses.

DHCPv6-PD allows multiple subnets to be set up and routed around with no user understanding, in much the same way that individual IPs are today with DHCP, so this is something that regular people can use via features in their software and router firmware without needing to know what's going on under the hood. It's the ISP's job to make sure that all this stuff is possible, and that means making more than a single /64 available to their customers.

Yep.

Use cases are not hard to think of. Each radio channel on an access point would perform better if given its own routed subnet. VM offered services like telephony or managed TV boxes need their own separate, secured subnet. How many homes have a single WiFi AP these days? IPv6 and wireless mesh networks will suck up address space. The concept of partitioning IoT botnets (sorry: devices) from regular users is becoming a more normal

The days of the single flat L2 network per subscriber are numbered.

Will all of this complexity be manually configured? Heck no! There are many moves afoot across the industry to automatically configure home networks. Have a look at the IETF homenet working group (https://datatracker.ietf.org/wg/homenet/) for some idea of how this might work.

The other key point is that even if the use cases aren't 100% apparent right now because of the largely static nature of IPv6 addressing it's important that consideration is given when designing roll outs. An ill-considered addressing scheme could paint an ISP out of important revenue opportunities in years to come (as well as upsetting their user base).

---

Anonymous wrote:

There are some crazy penny pinching ISP out there trying to deploy one /64 per subscriber (I'm sure there are some who would wish to give /128s if only they could). Most seem to have settled on /56s which is enough for 256 networks. It doesn't take a lot of imagination to start eating into this. I saw a video a few months ago where someone from RIPE (the European IP address administrators) was recommending giving people /48s or worst case /56s but on /48 boundaries to save the inevitable but painful re-addressing years hence.

---

Better for end users to have a shortage than the entire system again.

A /48 is way too big for a typical home user even if we start having toasters, cookers, fridge's all with internet connectivity.

A senior BT engineer wrote a document explaining how he thinks with current allocation's ipv6 will get exhausted, similar mistakes to ipv4 are been made in that the current policy is to supply ipv6 at very generous levels to organisations.  http://eradman.com/library/is_the_ipv6_address_space_too_small_.pdf

One of the reasons I want VM to push ds-lite and not proper DS is that I know there will be issues e.g. with people getting banned on shared ipv4 address space, but then the likes of VM will push the content providers to roll out ipv6 (which is what we need) and once thats done ipv4 cgnat issues wont matter as ipv6 will be used instead.  The likes of netflix and google moved to ipv6 years ago, but companies like sony playstation are shockingly still single stacked ipv4 on their gaming services.  Steam is also ipv4 single stacked, many web forums including this one are also single stacked.  The problem with dual stack deployments is it doesnt encourage content providers to deploy ipv6 because ipv4 still works 100%,  this is why I want VM to deploy DS-lite, as there "will" be ipv4 issues and VM are a big enough entity to bear weight on content providers to deploy ipv6.

Thanks for the link, chrcoluk --- that document gave me a good chuckle.  I think it must have been written on April 1st.  :P

The first thing to note is that the author seems to think that IPv6 addressing was designed with the idea that the space of Universal Product Codes would be mapped into it, which certainly wasn't a primary design consideration.  Then, apparently to make absolutely certain that this is impossible, he makes the outrageous manufacturing decision that product identifier, product type and product version are all in distinct spaces which add up to 37 bits and that these bits are entirely separate from a 40-bit unique serial number.  This gives him 77 bits of fantasy requirement which, when added to his inflated estimates for RFC2374's TLA, NLA and SLA, yields a total fantasy requirement of 162 bits.  Well let's unpack this bundle of fantasies.

To make it clear why this is quite nuts, understand what he is doing:  he's taking the worst case requirement for ONE product manufacturer (imagining the largest), and extending it to mean that ALL product manufacturers have this requirement and that therefore these field widths must be predefined statically to form a classful addressing system.  (Just like IPv4 was prior to CIDR.)  Well that is clearly not sensible, because such an address space would be almost entirely wasted since the great majority of manufacturers will always be vastly smaller than the largest imaginable.  This is why classful addressing is such a bad idea, as bad for product addressing as it is for network addressing.  I won't go into how product manufacturers should partition their individual spaces, but I will at least point out that just getting rid of his initial 37 bits of unnecessary pre-allocation already takes his claimed 162 bits down to below the 128 bits of IPv6.

To add to the above, his interpretation of RFC2374's suggested FP, TLA, RES, NLA and SLA fields seems to be quite wrong.  Similar to what I described in the paragraph above for products, he estimates worst-case field widths for TLA, NLA and SLA which he imagines would be needed for ONE geographical jurisdiction (the largest or most complex one), and then he extends this imagined requirement to apply to ALL geographical jurisdictions so that his fields must be predefined statically to form yet another classful addressing system, just like before.  Well that is not how IPv6 is organized, as far as I know.  The FP bits are certainly allocated statically because they are encoded in router hardware, but all other parts of the top /64 are flexible and have more in common with CIDR than with classful pre-allocation of fields.  TLA is the least flexible because it's the basis of geographical partitioning into jurisdictions, but ultimately each jurisdiction is expected to partition the combined TLA, RES, NLA and SLA space as best suits their own jurisdiction, and it certainly won't be the same everywhere in the world.  IPv6 routers won't care, it's just a configuration option.

In summary, I think the author of that document has an acute case of classfulitis, and it makes him want to pre-allocate fields in IPv6 addresses in a very wasteful manner.  It's not really surprising to me that he finds 128 bits constraining under these conditions, but that's not really a fault of IPv6 but of his desire for universal static pre-allocation of the IPv6 address space.  I think it's a very bad idea.  I doubt that many people will agree with him.

Morgaine.

Yeah, that presentation describes classful allocation, which isn't what we're actually doing with v6 (because that would be one of the mistakes of v4 that we're avoiding). It also seems to think that you can identify individual devices from the IP, which isn't really true. IPs encode a node's current network location, not its identity. (Don't get confused by SLAAC; yes, it inserts the MAC into the IP address, but that's just as a convenient way of generating a unique IP. There's no requirement to use the MAC there, and v6 doesn't do anything special with it -- those are just opaque bits as far as v6 is concerned.)

There's no way to send a packet to a given MAC, or to look up the rest of the IP from just the MAC, or anything like that. The last page of the presentation makes it clear that he's expecting that, but it's not something that v6 can do. There are protocols that can handle it (LISP?) but you could just as well have the devices phone home to a central server with their UUID. Neither of those would require inserting the UUID into the IP. Slide 19 sorta comes to that conclusion if you read between the lines a bit.

That presentation is from 2005 or earlier so you could maybe excuse it as being dated, but if so then you can't use it as a useful argument in a discussion today. All it's really arguing is that classful allocation of networks won't fit into 64 bits, which is true but irrelevant since we're not doing classful allocation.

A /48 is way too big for a typical home user even if we start having toasters, cookers, fridge's all with internet connectivity.

Good! Our allocations should be way too big, rather than way too small. The only question is whether we have enough address space to cover them.

There are 5000 /48s available per person on the planet, so unless you think that each person is going to run thousands of separate networks then we should be fine with that. If you want to talk /56s there are ~330 million per person, which is definitely in "enough" territory. And even if that's somehow wrong, both of these figures are from just 2000::/3, and there's another five unused /3s so we could start all over again in one of those using tighter allocation policies if needed.

In summary: /48s should be fine, /56s certainly will be, and there's no argument whatsoever for going down to /64s.

similar mistakes to ipv4 are been made in that the current policy is to supply ipv6 at very generous levels to organisations

The allocations we're doing in v6 are nothing like the ones we've done in v4. The "standard" ISP allocation is a /32, which consumes the same fraction of the v6 space that a single IP does in v4. Would you consider a single IP, for an ISP with tens of thousands of large end-user networks, to be "very generous" in v4?

If you can find me some /8s issued to individual companies, or /16s issued to users that could fit into a /48, then you'd definitely have a point, but we're not making allocations like that.

I am glad his views have been addressed, but I also am someone who thinks efficiency should be adopted.  Applying /48s to home users to me is just stupid.  I agree that allowing for multiple subnets is sensible and since /64 is the smallest routable address space then /56 is a sensible size to home users.  Maybe /48s to advanced technical minded users, businesses and so forth.

To think been wasteful is a good thing, its that kind of thinking that led to the ipv4 crisis.  It is easier to fix too small allocations than it is to fix too big allocations.  The number of internet connected devices will grow, the population will grow, the amount of server (instances) will grow.

It is a bit like people searching for an isp where they can gain a ipv4 block for their home, they probably dont need it but want it as its the cool thing to do.  Yes I do have have friends who have a 8 ip block (5 routable so 3 wasted), but dont actually need more than one ip.

Also remember there is always fluff/waste not 100% efficiency as isps split their networks into different segments, so e.g. if a block of ips is say 4000 addresses and they have 4002 online customers in a segment then they may allocate 2 4000 blocks and waste 3998 ips, it is not as simple as 1 ip per device. Or 1 prefix per end user.

Then there is the matter of growing routing tables that would be processing bloat.  The reason /64 is the smallest prefix because if there were smaller then that then the prediction is routing tables would get too big on the internet.

Sorry but you wont get me to agree to a lets be wasteful because we can motto.  The point you guys are making is that you believe at some point in the forseeable future a /56 wont be adequate, so a /48 should be assigned to home users, but if you really think home address space is going to expand to such extreme amounts within say the next decade or so, then why not apply that thinking to larger prefix allocations as well, it applies both ways in my opinion.

I expect VM to do the same as BT and sky and adopt /56.

Can we firstly get IPv6 on Virgin and then moan about it after. I can’t believe what I am seeing here.

Sorry. We'll stop procrastinating and get back on with our jobs implementing IPv6 for Virgin... :smileytongue:

> Sorry. We'll stop procrastinating and get back on with our jobs implementing IPv6 for Virgin... 

Excellent, much appreciated!

But seriously, if Virgin had capitalized on its community resources and offered a variety of short-term roles to its IPv6 enthusiasts a decade ago, it wouldn't be coming in last of the Big Three in its IPv6 deployment now.  But oh no, shock horror, that would have involved talking to customers and even worse, meeting their needs ...

Everything that is wrong with Virgin boils down to just that one single thing, a failure to recognize that customers are your primary stakeholder, the source of all your revenues, and so you must embrace them.  For a business in a competitive market, ignoring that stakeholder is suicidal.

---

TonyJr wrote:

Can we firstly get IPv6 on Virgin and then moan about it after. I can’t believe what I am seeing here.

---

Well, they are going to be forced to do IPv6 eventually.

It's a bit like CLID, that has to be free from October 1st (So add it to your package after that day), sometimes they are forced to do good things.  Of course, this might be why they put EVERY bill up by £3 or more.

Back to point.  The Council buys a bit of anti-tamper furniture to put in the park.  The staff that goes to install it (Lets call them Mergin Vidia) installs said equipment without reading the instructions or taking on any taxpayers feedback.  Once it is done it's found that everything is facing the wall (Ooops) and that the Anti-Tamper connections were attached incorrectly making them impossible to remove (Ooops).  Now it all has to be dug up again and fully replaced.

DS-Lite will break Ipv4 connectivity for far too many people.  It will create a massive support load that they are in no way planning for.  This is Virgin, they don't plan for anything, Do you think they have tripled their phone support staff in anticipation for rollout?  The problem will slowly go away as Ipv6 adoption gets larger, but it still stinks.  Do it correctly now and it doesn't.  You can guarantee if they go with a broken implementation, that they will stick with it for 10 years until it eventually fixes itself.

Just for information in case anyone is interested.

On my Dual BT/VM setup, from BT I get a /64 address to the router and the assets get a /128 address, apparently, if I'm reading the PowerShell output correctly :)

My understanding is that BT users get a /56

However what typically happens is that the router will use a /64 from that delegation.

There's an interesting thread on the BT forums here.

https://community.bt.com/t5/BT-Fibre-broadband/How-to-get-IPv6-working/td-p/1732761

Tim

@Adduxi:

If you look through your HH6's Event log, which is in the hub's GUI menus at:
         Advanced Settings->Technical log->Event log
you'll find a line containing something like:

WAN DHCPv6 Client Prefix : 2a00:23xx:xxxx:xx00::/56 (valid time = ...

From https://www.bgpview.io/asn/2856#prefixes-v6, BT has a prefix of 2a00:2380::/25
which you can see in the first 6 hex digits (6*4 = 24 bits) of your client prefix.
The 25th bit of their allocation is a 1-bit (bit 3 of hex '8'), so your 'x' hex digits
can be anything as long as the first one starts with a 1-bit, hence '8' through 'f'.

So, altogether there are 14 hex digits = 14*4 = 56 bits in your prefix, matching the /56
mentioned in your Event log. (The "00" just before the :: is not part of your prefix, but
just pushes the two preceding 'x' digits left by 2*4=8 bits.) What that line is telling
us is that BT is delegating to clients a /56 IPv6 block, the same as Sky. According to a
presentation given by Virgin at a meeting of the UK IPv6 Council, this is also the same
as Virgin will provide. (Just as well, as competing on delegation width would be daft.)

The /64 that you observed isn't the client delegation but only the width assigned to the
IPv6 address on the interface connected to the CPE's switch. You can see that on the two
pages Home->Advanced settings->IPv6->Ststus and Home->Advanced settings->IPv6->Configuration.
Those detail the settings on the WAN and LAN sides respectively, the WAN settings being fixed
and the LAN settings being configurable.

A delegation of /56 provides 256 blocks of /64, so in summary what you have is this:

2a00:23xx:xxxx:xx00::/64 - Block 00 - On your HH6's LAN interface and switch
2a00:23xx:xxxx:xx01::/64 - Block 01 - On your HH6's WAN interface
2a00:23xx:xxxx:xx02::/64 - Block 02 - First block available for further routing
.... 252 more /64 blocks
2a00:23xx:xxxx:xxff::/64 - Block ff - Last block available for further routing

Morgaine.

@ravenstar68  , @Morgaine

Thanks guys for the information.  I think I'll go and lie down in a dark room.!!

All those Hex numbers are too much :)