Posts by Nanashi 384 publicly visible posts • joined 19 Sep 2016
Not if you believe El Reg's armchair network "engineers" it doesn't!
v6 is backwards compatible with v4, but as you say that doesn't mean that v4 is forwards compatible with v6. It also doesn't stop people from moaning constantly about how it's not backwards compatible.
64 bits isn't enough. Hardware (EUI-64) addresses are 64 bits, and you need way more than 64 bits of L3 address space to handle 2^64 L2 hosts. The next power of 2 up from 64 is 128, so here we are.
You can already set most of a v6 address to zero (e.g. is 2600:: really so hard to remember?), to the point where anybody can easily make addresses that are ~64 bits of actual stuff plus ~64 bits of zeros. And they go straight into DNS so it's not like you even need to remember them anyway, but if you did then you have the 64 bit addresses you're asking for.
If you understand v4, then you understand v6. The operating principles of the two protocols are somewhere around 90% identical.
I'm willing to bet there are a lot of network engineers that don't really understand v4 though. You only have to look around this thread at all the people who somehow think it's possible for v4 to be forwards compatible with v6...
Actually, there's a way for a device on a v4-only network (even behind NAT) to get v6: Teredo. Also, every v4 address has a /48 of v6 space tunnelled to it via a mechanism called 6to4.
For some reason, the existence of these protocols doesn't seem to stop people from complaining that they don't exist.
Indeed.
v6 is already backwards compatible. Perhaps you wanted v4 to be forwards compatible, but we can't create an IPv7 which v4 is forwards compatible with for the same reason that we didn't create an IPv6 that it's forwards compatible with: because v4 isn't forwards compatible with any address size that's bigger than 32 bits.
If you could fix that problem, then we wouldn't need an IPv7. You could just make v4 be forwards compatible with v6.
This is exactly what v6 does. The "compatibility mode" is v4. What else were you expecting it to be?
And in fact v6 has NAT64, which basically places the v4 address space into a v6 /96 so that v6-only clients can talk to v4-only servers. Is that somehow not good enough for you?
I found it by Googling for "apnic ipv6 measurement". There's a more detailed explanation here: https://labs.apnic.net/?p=348.
AMS-IX are the best available public statistics. They're nowhere close to the best possible -- in fact the measurement they make is fairly useless in working out where v6 deployment is at. It misses out on on-net caches (which will be mostly v6 where available) and private peering (again mostly v6 by volume), which apparently account for something like 75% of ISP bandwidth between them. It counts large parts of the traffic from v6-only ISPs that use NAT64 as being v4. It's measuring at the wrong place to figure out what percentage of servers or clients have v6, and it's completely incapable of showing how readily available v6 support is to the people who aren't yet actively using it.
These are not very useful stats, unless your goal is to cherry-pick something that makes v6 deployment look bad.
> 3) What is the traffic volume that your statistics is based upon?
I don't know. But the volume doesn't matter if it's not a representative sample or if you're not measuring the right thing.
APNIC's methodology is explained here: https://labs.apnic.net/measureipv6/. AMS-IX's graphs are obviously flow statistics from their network only.
Your source was right in that these (plus Google's) are the best publicly available statistics, but they won't be of any use to you if you don't understand what they're measuring.
My "wide deployment" comment was referring to the things necessary to support a network of the type described in your draft/presentation but using existing v6 transition tech -- mainly that's support for v4, v6, NAT64 and NAT46 in ISP gear, CPEs and client devices. Those are either supported by almost everything or (in the case of ISP gear and CPEs for NAT64/NAT46) supported by enough things that you shouldn't have any trouble getting equipment for them if you want to.
I've looked at APNIC's stats many times, but what they track is the percentage of clients that hit their measurement servers over v6. As it happens, that's not a useful stat when it comes to tracking support for any of the above.
As for the AMS-IX stats, I already explained to you why they're not an accurate measurement of the overall amount of v6 traffic on the internet, but they're also not a useful stat for tracking the above things either.
In case anybody cares, I looked at this draft the last time it was posted and came to the conclusion that it's more or less a rehashing of methods that already exist in v6 (that is, 6to4 and NAT64/NAT46).
Like I said earlier in this thread, people's ideas seem to be either impossible or already implemented in v6. This one happens to fall more into the latter.
...no they don't. Even the routers that support NAT66 (which is a minority of the set that support v6) don't set it up by default. Major deployments in the UK (BT, Sky) and the US (Comcast) don't use NAT66. In fact I don't think I've heard of any ISP v6 deployments that rely on NAT66.
I'm under the impression that most new routers support v6, although there's certainly a long tail of crap out there. On the other hand, something like 97% of people use the ISP-provided router, so there's an argument that third-party routers are mostly irrelevant.
So what sort of network would require a complete redesign for v6? I'm sure there's something out there somewhere, but it's not common. People that incorrectly think that v6 would require a complete redesign of their network are a lot more common.
> IPv6 does the job, but it is certainly not the best solution to the problem. If it were, we wouldn't have an uptake problem.
Your second sentence doesn't logically follow from the first. It's entirely possible that the best solution has an uptake problem.
As far as I can tell, it's impossible to make a solution without an uptake problem, and it's my humble opinion that being impossible disqualifies a solution from being the best solution, on virtue of the fact that we couldn't actually do something that's impossible.
To be clear, my basis for believing that it's impossible is that (a) current v4 doesn't support bigger addresses, (b) any method of upgrading it requires lots of people to do something, and (c) it's the "require lots of people to do something" part that causes the problems in uptake.
Lots of people think they have a way around one or the other of those, but their ideas always seem to be either impossible or already implemented in v6.
(As always, you could easily change my mind by giving me something that doesn't fall into one of those categories. But if your idea is "just add another octet" or if it involves pointing me to dozens of pages of draft text, expecting me to read it all and decipher your idea for you and then spend weeks dancing around explaining it to me when I conclude that you've just reinvented something that already exists and ask you to explain how it's different... then you're probably not going to have much luck.)
Perhaps it would be more accurate to say that v4 as currently specified and implemented everywhere is not forwards compatible with bigger address spaces.
It has multiple places where that forwards compatibility could be added: the version field, option headers, the reserved flag or even a reserved src/dest IP address. (Of those, v6 went with the version field for native operation and the protocol field for operation over the top of v4, which makes sense because that's the intended use of those fields.) But all of these options require upgrading hosts, routers, networks, software etc to handle them, so no existing devices will be compatible with the longer addresses, and none of them allow an unupgraded host to initiate connections to an arbitrary upgraded host.
At the point where you have to change v4 to support bigger addresses, can you really say that v4 is compatible with bigger addresses? Looking at the rest of the thread, it seems to me that "existing, unmodified v4 host can talk to arbitrary v6 host" is what people want, so it looks like their answer to this question is "no".
It might be more accurate to say that, but it's also an awful lot more words to type out every time.
That still requires you to do almost everything that v6 requires you to do. It may save you some code in the IP stack, but that's the part we're not having any trouble with. You still have to update protocols, patch all your software, configure new addresses, firewalls etc, and those are the parts we're having trouble getting done.
And v6 has a mode that works like that! You can put a magic number (41) in the protocol field to indicate that the packet contains v6 addresses, and then the v6 addresses go after the v4 header. People doing v6 deployments seem to strongly prefer running it natively though.
People who care about performance. And yes, computers work for us and not the other way around, which is why you let DNS do the heavy lifting rather than manually dealing with IP addresses. Otherwise you're just doing the computer's work for it, which is backwards.
That prefix is actually just a default, though. If you're setting up your own NAT64 router and you want to use another prefix, you can.
> The v4 hosts don't need to contact all the "extended address" hosts, they would be in their own world, and a dual homed interface (like how IPv6 works now) would let them communicate with the outside world using the new 6 octet scheme.
Okay, so the mapping wouldn't actually do anything that we don't already have in v6. As such, it seems unlikely it would be much different to v6 in deployment time either.
It does, though? It reduces the amount of CGNAT hardware the ISP needs to provision. I think for EE the figure was something like 70% of their traffic flows over native v6, which cuts the costs of their CGNAT infrastructure by two thirds.
Having v6 also means that the v4 doesn't need to work as well -- being behind CGNAT is a lot more okay if you can side-step it. Also, in many cases you don't need v4 on the client side. For their v6-capable users, EE provide no v4 service on the network. T-Mobile in the US is the same.
(The server side is a little trickier. I do run most of my own personal services over v6 only, so it's certainly doable.)
64:ff9b:: is checksum neutral, so packets can be translated without needing to adjust the checksum on them (0xffff - 0x64 = 0xff9b, and the rest is all zeros). Since you don't generally deal with IPs directly it's not critical for the prefix to be shorter, while performance is important.
> Had they simply added two octets and made 0.0.x.x.x.x map to IPv4 probably everyone would be using it today.
You clearly didn't think any part of this through. Two extra octets isn't enough, and how would the mapping benefit anybody? How would v4 hosts send packets to the IPs outside of 0.0/16? There are multiple mappings of v4 addresses into v6, but none of them enable v4 to talk to more than 32 bits of hosts, because v4 isn't capable of it -- and v4 will still not be capable of it regardless of the design of the other protocol involved.
> at home I've got plenty of choice over suppliers and equipment
So you're concerned enough to switch ISPs over it. But if you take shelter under a tree during a thunderstorm, you can't simply move over to the next tree once the first one is drenched.
And if you've never had an RFC1918 clash on a VPN (or M&A) at work, consider yourself lucky.
Then you're simply ignorant. Which is fine, because we can't all be experts at everything, but you need to realize that it limits how much useful insight you can have on this issue.
You cannot just "add an octet" to v4. v4 is hardcoded to a fixed address width of 4 octets. The header format is hardcoded with 4 octets for the src and dst addresses, and every single device out there (billions and billions of them) have v4 stacks which are hardcoded for 4 octets.
The telephone network is completely different. Telephone numbers have been variable length since the very beginning, which makes it easy to add extra digits. IPv4 isn't like that, at all.
So what can you do? You can deploy a new IP protocol version which has bigger addresses... and that's exactly what we're already doing.
> People complain about IPv6 because it requires a complete redesign of their networks.
These people are wrong. It doesn't require a complete redesign of their networks. v6 is almost completely identical to v4 in most aspects, including network design. Subnetting and routing in v6 is identical to v4, and the way you design your networks with it is also the same. To get v6 onto your existing v4 network, you just put it there alongside the v4. Your router gets a:b:c:d::1 as well as a.b.c.1, and your hosts get a:b:c:d::x as well as a.b.c.x. Firewalling works the same. You use TCP and UDP like you do in v4, and those work the same too. No redesign is needed.
It didn't have to be this way. There were various proposed alternatives for next generation IP which had variable length addressing, a different routing model or more weird and wonderful features, but we went with a protocol that worked the same way as v4 did.
> 3. Come up with an easier solution that doesn't require a complete redesign of how networks work.
As mentioned, this is what we did. But you're right, people want a unicorn. Even when you do the exact things they suggest, they still complain.
Before IANA runout (almost a decade ago now) we were going through more than one /8 per month, and demand has only gone upwards since then. Reclaiming unused parts of old allocations would buy us a couple of years at best.
And then what? We'd still have to do v6, and anybody who isn't doing it yet isn't suffering from a lack of time; they've had plenty of that. So what's the point? It'd be a massively disruptive and costly exercise to gain us a small amount of extra time which we would then squander. Put that effort into v6.
They're behind Cloudflare, who definitely support v6. Actually you can reach El Reg over v6 with the appropriate hosts file manipulation, but the last time I tried to make a forum post when doing that the post apparently got wedged and had to be manually removed.
(Cloudflare do support an option that hashes v6 addresses into 240/4 and uses the hashed address as the apparent source address of the inbound connection, which should work around databases with incorrectly-sized columns or whatever the problem is...)
You mean like 64:ff9b::xx.xx.xx.xx? We did this. It's a thing you can use, and it works -- it lets a v6 host connect to a v4 host, and it lets the other direction work too if you configure a port forward for the connection (so basically the same as NAT, just with v6 instead of an RFC1918 v4 address).
Why do people keep saying it doesn't exist?
"A 64 bit extension would have made so much sense, it never made sense to me why they went overboard with 128."
Do you know how hard it is to deploy a new IP protocol? That's why they went overboard: so we don't end up needing to go through this a second time.
In v6 you'll most likely be using privacy addresses, which randomize the host part of the address regularly. This obfuscates the number of active devices and the identity of each device, if in a slightly different way to NAT.
And there are far easier ways to track you, such as browser cookies. Those work across completely different networks.
"Remind us again why the IETF didn't make IPv6 backwards compatible… ®"
They did; you can talk from v6 to v4 in the same way that you can talk from RFC1918 v4 to public v4. But they didn't make IPv4 forwards compatible, and that's something we're stuck with -- the only way to fix it would be to deploy an update to v4, which is what we're doing with v6.
Did you really need yet another reminder about this? *reads comments* apparently El Reg's readers do, at least.
That isn't an accurate measure of v6 traffic on the internet though.
Here's another measurement: EE see about 70% of traffic from dual-stack devices going over v6. (Source: question at 16:50 of https://youtu.be/16FdlxyFQgY), which incidentally represents a cost saving to them.
This isn't an accurate measure of v6 traffic on the internet either; my point here is that the value you get depends on where you measure. There's a lot of reason to believe that most v6 traffic avoids hitting the Amsterdam Internet Exchange - for example, I'd imagine most of Youtube's traffic goes over private Google links and then via peering directly with eyeball ISPs, and a lot of Netflix's traffic is from local cache boxes. Most v6 traffic is generated by big networks, and those are also the networks most likely to have private peering. Traffic over private peering isn't going to show up in AMS-IX's graphs.
Is it really harder?
Look at this address: 2001:db8:abcd:1::2. The first three segments ("2001:db8:abcd") are the prefix assigned by the ISP. The next segment ("1") is the subnet ID I assigned (matching VLAN 1, perhaps). Finally, the "::2" part identifies the host on the network.
Compare that to v4, where the same machine is something like 203.0.113.51/27. Which parts of that are the prefix, which parts are the subnet and which are the host? I definitely can't tell at a glance.
v6 isn't hard. People are just scared by new things.
Truth is that you're not familiar enough with the problem space, or the existing solutions, to be able to criticize the people who are.
It'd be possible to assign a flag address like that, but no existing v4 hosts would recognize the address or be able to handle the extra addressing bits, so doing so wouldn't make existing v4 hosts be compatible with v6.
Plus we actually did something very much along these lines -- we defined a new protocol (6: TCP, 17: UDP, 41: 6in4) which places those extra address bits just before the payload. This is basically the same as your suggestion except that the magic value goes in the protocol field rather than the address field. But them doing what you suggested apparently wasn't enough to stop you from writing a great big post on how they screwed up.
I'd hate to do the "well, actually" thing, but actually... RFC 4443 section 4.1 requires hosts to respond to echo requests, and RFC 4890 sections 4.3.1/4.4.1 require networks and hosts to not drop echo requests or responses. Not that that stops people from doing it anyway, but hosts are indeed expected to respond to echo requests.
(And of course that's just echo requests, there are other ICMP types which hosts need to process.)
The v6 header is actually much less bloated than the v4 header is. One third of the non-address bytes were removed, reducing the number of non-address fields from 11 to 6. One of the removed fields is the checksum, so v6 routers no longer have to recalculate a checksum on every packet. Routing v6 packets tends to be about 500us faster than routing v4 packets, probably at least partly as a result of all this.
As for addresses, you can't just "simply prepend some octets" to them. v4 is inherently fixed length, as are all of the protocols and software that use it. It's just not an option, unlike in the telephony space where phone numbers have been variable-width since the beginning.
If we wanted to use the telephony solution, we'd first need to deploy some alternate protocol that supports variable-width addresses. That would require doing everything we're already doing to deploy v6, so it would be no easier. In fact it would be harder, because a protocol with variable-length addresses would be significantly different to v4. v6 at least has the advantage that it uses the exact same addressing and routing model as v4 does.
I just mean any system that can parse a v4 address and generate a v4 packet. This isn't some extra thing that needs to be added, it's literally the software that's already in those systems and which they're already using for v4.
I don't think I even understand what you mean by "transparent" any more. Do you mean "existing devices keep working", or do you mean "end users don't need to change what they're doing" or is it "the engineers responsible for making the network hardware and software are unable to detect any changes in behavior or functionality"? Or maybe even something else?
By this definition, v6 is backwards compatible. It can transparently handle v4 on any system that has the appropriate software support, and it doesn't require anybody to be capable of doing v6 if they don't want to do v6.
Is this what you mean by backwards compatibility, or are you going to change your mind again?
It would've been helpful to put that in your kosher definition of backwards compatibility when I asked you for it. By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. Operators and users need to deal with both.
So, it's been 11 days since I could bring myself to check the comments here, and I see that lots of people managed to downvote me but nobody managed to tell me how to make v6 more backwards compatible. I think that makes my point, no?
(I didn't forget to mention "v4 on the inside, v6 on the outside and NAT between". I didn't mention it because it doesn't work. That said, even if it did work it wouldn't require any changes to v6, so it wouldn't be a way of improving v6's design.)
They are actually behind Cloudflare, which means v6 is just a toggle away. It also means that, with appropriate hosts file entries, you can talk to El Reg over native v6 even without them explicitly enabling it. The last time I tried this, it worked fine except that attempting to post a comment didn't work. The post just disappeared into the aether, and never showed up.
What did show up, however, was a post from an admin complaining that they had to manually drop my post from the queue.
I'm guessing some part of the post pipeline can't handle long addresses (e.g. a database with a short VARCHAR column). Cloudflare have a workaround to deal with that though (hashing the v6 address into 240/4) so maybe there's something else that needs the real address (geolocation/spam filtering?). Hard to tell exactly unless they feel like showing up here and telling us.
As it happens, I do have a way to summon admins...
I guess you could even argue that we did do something along those lines:
$ curl -v https://www.theregister.co.uk/ | grep "<title>"
* Trying 64:ff9b::104.18.225.129...
* Connected to www.theregister.co.uk (64:ff9b::104.18.225.129) port 443 (#0)
<title>The Register: Sci/Tech News for the World</title>
Works fine so long as you have a translator box in your network path. It's outbound only unless you manually configure a port forward*, but then that's how NAT already works so that's hardly a new problem.
(* This is the part that lets you avoid being restricted to a 32-bit address space. Either you allow connections to be established both ways, which restricts you to 32 bits, or you restrict it to outbound only which allows you to use the full v6 address space.)
Seriously. Why more than one public IP per household, and maybe a dozen or so on average per organization?
Because most people have more than one device, and most organizations have more than a dozen or so devices. I guess we could all use proxies, but I know nobody wants to use those -- they actually want their devices to be connected to the internet, which is what the IPs are for.
We are not really running out of IP4, only out obviously unallocated IP4.
No, we're out. We're beyond out, almost nobody has enough addresses and everybody has to spend tons of time and effort trying to stretch what limited address supply they can get their hands on.
Back in 2011, before IANA ran out, we were going through one /8 per month. Given that demand has only gone up since then, 16 million addresses would be something like a 2 week supply now. If you think DEC's block is going to save v4, then you can think again.
You can't actually go IP6 only till everyone has IP6.
Not true. You can certainly do v6 before everybody has v6.
We need v6 because a) we will lose important internet functionality without it, and b) maintaining v4 is expensive, and is going to get extremely more so if we try to run the internet on it forever.
But as usual, people can't see past the next quarter when it comes to planning how they're going to spend their money.
If the people who designed v6 answered their outside phones, they'd spend all their time talking to crackpots and people who don't understand what they're on about.
v6 is already designed about as well as it can be given the constraints it's working under: it works almost exactly the same as v4 does (the two changes I can think of being SLAAC and NDP instead of ARP for neighbor discovery, both pretty simple things), and it's as backwards compatible with v4 as it is possible to be.
If you think I'm wrong about that last one, all you need to do is respond and tell me how, exactly, you'd make v6 have better backwards compatibility than it does. And I suspect you'll end up demonstrating my first paragraph.
The explanation is the pigeonhole principle.
The problem with your suggestion is that it limits you to a range of addresses that's 32 bits in size, and those 32 bits have to map exactly onto the v4 address space. So er... it's just v4, but it won't work with all routers, so computers will still have to ship with and use their v4 stack anyway, so what do you even gain with your suggestion?
We don't need an emergency, we need a deadline. Humans are incapable of responding to open-ended emergencies (see: global warming), but they can cope with deadlines even for the most unimportant crap.
The problem is that there's nobody in a position to enforce a deadline on the global internet.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
