IPv6 support on Virgin media

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 :)