Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE | Hacker News Reader

Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

cloud.google.com

28 pointsl1n77 comments

> However not all enterprises or applications are ready for IPv6 yet.

I don't think this statement will ever be false in my lifetime.

It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

I'm not an RFC author, but something like "All existing IPv4 addresses will be reachable under the 0.0.0.0.0.0.0.0.0.0.0.0 prefix in the IPv6 Standard" seems like it would've made migration relatively trivial.

The draft standard is 26 years old. The official standard is 7 years old, and we are still reading articles about how "not all enterprises or applications are ready for IPv6 yet."

This question is coming from a place of genuine confusion and curiosity - I really don't get it. Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be? Was it a fairness issue where somehow this would have granted dominion over huge swaths of the new address space to existing players?

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading.

The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix.

Also, extending IPv4 address space has the problem that bake the misallocation into IPv6. IPv4 is broken in the small chunks that makes the routing table large. It also means that new organizations will have a hard time getting address space cause they need to get IPv4 addresses.

"The length is the problem, IPv6 format is more compact."

"IPv4 still can't access IPv6. IPv6 can't access IPv4."

I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

The IPv6 address format uses hex, that is always going to be shorter than decimal. I like that it is fixed width, has zero compression, and is distinct from IPv4.

It is physically impossible for IPV4 32-bit addresses to access IPv6 with 128-bit addresses. Accessing IPv4 from IPv6 requires middleware to translate IPv6 to IPv4 and IPv4 response back to IPv4. That is NAT64.

Making IPv4 addresses be a valid subset of IPv6 addresses would do nothing to help an IPv4 host reply to a packet from a host with a non-IPv6 address. Solving the "problem" of one-way communication without handling two-way communication is not worth anybody's time and effort.

You talk about networking as if this is just about updating a regex somewhere. 32 bits is 32 bits, there's no way around that. IPv4 addresses not being valid IPv6 addresses has nothing to do with anything.

This is like saying you want to put 16 gallons of liquid in a 4-gallon bucket. It just ain't gonna fit. You need a bigger bucket. Because a lot of people are still using carts that only hold 4-gallon buckets, let them keep using the 4-gallon ones until they get tired of paying IPXO for the 4-gallon bucket rental when the 16-gallon ones are free.

The real trouble here is that the entities that need more addresses and the ones not supporting IPv6 aren't the same ones. In particular, a lot of large companies basically need one IPv4 address and they can NAT their whole organization behind it. Meanwhile ISPs and hosting providers need lots of IP addresses but can't switch entirely to IPv6 because their customers demand the ability to communicate with those companies that still only support IPv4.

But the government could probably fix it without even mandating anything. They should just... stop using IPv4. Does your company have to file tax forms with the IRS website? Only available via IPv6, so better get your network to support it.

To some degree, no it's not a choice; you can't fit a 128-bit address in 32 bits. However, to the degree that it is possible, that exists; NAT64 does make every valid IPv4 address a valid IPv6 address.

> If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

This is already the case. The format for representing IPv4 addresses in IPv6 is to encode the first 96 bits of the address as ::ffff and the last 32 bits as the IPv4 address, e.g. 192.0.2.128 as ::ffff:192.0.2.128. You can also encode the last 32 bits as hex if you want (::ffff:c000:0280 is the same address) but then it's less obvious what the IPv4 address is.

The problem is that every IPv6 address is not a valid IPv4 address, because the IPv4 address space is smaller so there is no way to do that without some kind of NAT or similar, which also exists but sucks in various ways.

I don't think that would work. The IPv6 Notation is only the human representation. Inside the package it is a 128 bit integer. IPv4 addresses can already be put there. The problem is that everyone still needs to support a package with 128 bit addresses instead of 32 bit. There is simply no space in the IPv4 package format for the 128 bit addresses. Or anything bigger than 32 bit.

Well there is the options... But that means again every single router and host would need to support it on the path for it to be any use. So new protocol is much simpler and allows fixing other things as well.

There's no such thing as "backwards compatible." The IPv4 packet format is set in stone with 32 bit addresses. The "just add more bytes" meme doesn't make any sense.

But it gets brought up all the time...

Sure, by people who have never bothered to read the RFCs nor spent even a moment of thinking about what happens on the wire. (I last read the RFCs in the late 1990s so I don't know the latest, but it is obvious you can't add more bits)

They think the shed should be blue.

Makes me really doubt about general education in CS and programming.

Is there really this many people who never looked what is in IP packet. And well TCP and UDP too, but less so. Or considered how a packet might traverse across networks.

You have a small box, and that is it. You cannot make box bigger and make someone that only understand small box to understand the new big box.

Then on other end there are those that are too stuck of manually managing the small boxes... And the stuff that made them somewhat usable.

Just to address the implication (prevalent in many of the sibling comments as well) that I and everyone else who talks about this are idiots incapable of grasping that 128 is larger than 32:

If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely. They can putter along accessing only a subset of available resources forever and everyone can passive-aggressively roll their eyes at them and close support tickets saying "upgrade to IPv6 if you want to see the rest of the internet, it just works."

That's what I mean by backwards compatible. Everyone who says "it can't be done, it has to be this way" is asserting that there's no better alternative to NAT64/DNS64 and running two entirely separate networking stacks in parallel. I don't buy that there was no simpler way to accomplish packing 32 bits into a space that can contain 128 bits. And if "supporting IPv6" simply meant "upgrading your networking software to the latest version, which transparently handles both IPv4 and IPv6 traffic for you" then networking and server teams have no excuse to avoid deploying IPv6 support for 26 years.

I recognize that 128 bit addresses will be truncated and packets misdirected or rejected if handled by a 32 bit networking stack. I recognize that clients upgrading too early will fail and need to fall back. But making it unnecessarily difficult for servers and routers to handle IPv4 traffic in an IPv6-only context led us to where we are today.

To illustrate my point: ascii text works just fine, with no translation layer required, when parsed and transmitted as UTF-8.

How would IPv4 host talk through IPv6 network in your model? Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6. We'll call it NAT46, but it is deprecated because dual stack or NAT64 is better.

Or could tunnel IPv4 over IPv6. We'll call this 4in6.

The mistake you are making is thinking that it is hard to have dual stack. IPv4 will be running in tunnels for a long time, just like IPv6 run in tunnels in early days. There are enough IPv4 addresses for servers for a long time. Eventually, IPv6 will be the norm and nobody will care about IPv4 except for running old hardware and software.

Upgrading just networking software is impossible since client software needs to be upgraded to support longer addresses. In particular, they need to support the generic interfaces that work with multiple protocols.

> Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6.

Acknowledging my own ignorance here, assuming this sentence seemingly disregards my point, because this was a choice. The IPv6 standard chose to fix the header length at 40 bytes and operate differently from IPv4, but the standard could easily have said "We're re-using the IPv4 header format, except now addresses are variable-length up to 128 bits."

Because they also noticed that IPv4 has some design errors. So if you are anyway making something incompatible you can fix those and bring in new features.

IP packet having checksum that is also calculated on the hops remaining. Well, do you really really need that when most popular protocols TCP and UDP have also a checksum? So getting rid of it entirely is actually a smart move.

And then whole ARP, DHCP etc. Can we do something more sensible instead of that sort of thing. Different mindset, but reasonable attempt.

> If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely

If you have an IPv4-only client and an IPv6-only server (i.e., has no IPv4 address), you need a IPv4-IPv6 relay.

Because if the IPv6-only server is truly IPv6-only, it only has addresses that are 128 bits. How would an IPv4-only client, which only knows about 32-bit addresses, deal with a 128-bit address? The only address that the IPv6-only server has is 128 bits: how are you supposed to fit those bits in the 32-bit data structures of the IPv4-only client.

If a the server is IPv6-only, then its DNS records have to be 128-bits as well: how does that work with DNS A records, which are hard-coded to 32-bits? That's why AAAA records were invented: to with 128 bits. Now you're talking about update DNS server for new record types, resolver code to request A and AAAA records. Of course after you do a lookup to get the IP, you have generally want to connect, so you call socket(2) and then connect(7), so the latter has to be re-coded to understand 128-bit addresses.

You are correct, given the assumption that an IPv6-capable server or host has no IPv4 address. I attempted to acknowledge that such a server would be unreachable from an IPv4 client.

Thing is, all interesting Internet services require 2-way communication. Suppose you had an IPv6 client trying to talk to an IPv4 server. With that scheme, the initial packet could get routed to the server by dropping the first 96 bits of the address and treating the rest like an IPv4 address. But where do you put those other 96 bits so that the server can send its reply packet back to the originating client?

You can use NAT64 which does exactly that. If you're doing that anyway, there's not much advantage to adding all the complexity directly into the protocol.

IPv6 has other differences than the address length. A theme for IPv6 was to make it even easier for network equipment to process to make it faster; which aligns with "dumb fast scalable core; smart expensive edge" Internet philosophy - this is in contrast to "smart hard-to-expand core; dumb cheap edge" phone system philosophy

Compare the packets. https://www.networkacademy.io/ccna/ipv6/ipv4-vs-ipv6

> Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be?

No, but IPv4 and IPv6 can be used together (they're separate protocols) so there was no need for that.

> write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

This already exists. 2020:abcd:abcd::192.168.0.1 is a valid IPv6 address. Most applications will parse it just fine.

NAT64 has been around for ages and mostly works, but is pretty ugly so few people want to actually deploy it.

Extending IPv4 seems like it would work until you get into the details. You discover that any new protocol is going to have similar adoption problems. https://archive.ph/eHvKF https://news.ycombinator.com/item?id=10854570

They actually did that (see sibling replies), and it actually delayed adoption of ipv6 by a few more years, because of things like:

  1. some OSes can listen on ipv6-mapped-ipv4 automatically when some application listens on ipv4
  2. app is updated to listed on both ipv4 and ipv6
  3. at various companies, the updated app fails to start, because it listened on ipv4, which automatically listened on ipv6, and then it tried to listen on ipv6 and failed because the port was already in use
  4. The problem is weird and confusing, and the easiest fix is to just disable ipv6 everywhere: in the app, in the OS, everywhere. Then the app works again.
  5. The config changes remain untouched for many years (subtle config issue, don't touch!)

I think ipv6 would be more widespread if various auto-adaptation mechanisms were never introduced: 6to4, teredo, etc. I personally experienced this in my teens, one day my browser took 30 seconds to start loading any web page, and just disabling ipv6 everywhere fixed it, and for the next couple years browsers disabled ipv6 by default (whereas they previously were agnostic), and macOS also did a similar thing where it reduced ipv6 enablement by default for a few years, also domains like google.com and facebook.com removed AAAA records they previously had for a few years. They just can't tolerate 1% to 3% of users breaking due to ipv6 mis-config. Adoption would have been much smoother and faster overall, without these significant contributors to automatic-possibly-broken ipv6.

(Yes IPv6 works fine now, with happy-eyeballs, and DHCPv6, and pretty much only real-native ipv6 used anywhere)

Interesting! Thank you for the thoughtful reply - I did not anticipate those complications.

> and DHCPv6

So long as you don't have to care about Android, maybe.

Android still doesn't have this?

AFAIK https://issuetracker.google.com/issues/36949085 is still current.

Android is kind of boycotting DHCPv6 which annoys network admins.

What problems does that cause for Android users? I ask because I've never deliberately set up DHCPv6 on any network and haven't missed having it. However, it's clear that others strongly do want it for presumably good reasons. What are those reasons?

Not working well on networks that use it.

Also, a meta-reply would be: whatever clever solution you think you've invented was surely considered. It's 30 years ago so memory fades but all this was discussed at great lengths on mailing lists and in meetings by people who knew what they were doing. The only things I don't think were envisioned at the time were: NAT prolonging the V4 space exhaustion significantly, and the level of inertia for vendors implementing support for V6. I was still working on that in 2005 -- more than 10 years later.

I assure you I am under no illusions about my cleverness relative to others in this industry.

https://en.wikipedia.org/wiki/Second-system_effect

IPv6 definitely suffers from some amount of second-system effect but (I cannot stress this enough) that's not the cause of its failure. A minimal IPv4+ upgrade would still have failed for the same reasons.

IPv6 is actually working right now for many so I wouldn't call it a failure. Use of IPv6 has been increasing over time and who really cares how fast that is happening? Some ISPs, nodes or networks may never use it - but that's OK; really as long as major cell phone networks are using it, it's not going away.

Windows XP is another example of something that lingered far longer than it should have. It's not a failure just because everyone didn't immediately start using it.

> […] and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

You mean RFC 4291's ::ffff:0:0/96?

* https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5

* https://www.iana.org/assignments/iana-ipv6-special-registry/...

* https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv6

Anything but IPv6 it would seem.

I wish that Kubernetes had started as IPv6-only or IPv6-first. IPv6 is perfect for giving each pod its own address. There is more space for giving each host a subnet, or giving each pod its own address in the subnet.

That would have gotten rid of the CNI overlay networks. It would also made barrier between the internal and external networks. It would require running NAT64 and DNS64 in most clusters.

> I wish that Kubernetes had started as IPv6-only or IPv6-first

Seems a bit strange to me that they didn't, given how you'll want to use some sort of ingress anyway, so IPv4 could be delegated to those edge points.

> "It is remarkable, love," he said, looking at Nell for the first time, "how much money you can make shovelling back the tide." [ "Diamond Age" by Neal Stephenson ]

> Snap initially considered migrating to IPv6, but concerns about application readiness and interoperability led them to adopt dual-stack GKE nodes and GKE pods (IPv6 + Class E IPv4). This solution mitigated IP exhaustion and provided Snap with multiple years of IP address scale needed to support future growth and reduce operational overhead. In addition, this approach also aligned with Snap’s long-term strategy for migrating to IPv6.

Yet another horrible hack to avoid having to actually learn IPv6.

The first time someone calls you a horse, you punch him on the nose; the second time someone calls you a horse, you call him a jerk; but the third time someone calls you a horse, well then, perhaps it's time to go shopping for a saddle.

How does using both avoid learning v6?

Years of experience with "dual stack" organizations that completely neglect the IPv6 side or do stuff like install MITM firewalls that can't handle IPv6 so the addresses are only useful internally.

Who says they don't want to learn? When your provider doesn't support IPv6-only for all your purposes (I don't know about Google but Azure and AWS doesn't do that) then you'll just exhaust RFC1918 and not work on a solution for it?

Incredibly unsafe. If Class E is reserved "for future use", maybe that could include public use. The first rule of hardening production reliability is, make sure it doesn't just work, but that it will continue to work. Tomorrow, some customer of yours gets assigned addresses from Class E. Have fun untangling that.

Why not stop this bullshit and just transition to IPv6??

I'm not too worried about the Internet at large actually using Class E addresses. IPv4 is considered obsolete so there shouldn't be any "future use" coming out of the standards committee.

class E can't ever be used on the public internet anyway. too many existing firewalls are already configured to drop anything with a source address in range 224.0.0.0-255.255.255.255 (class D and E)

There's an RFC to use it in the Internet, unlikely to be ratified though.

Usually because your provider does not fully support IPv6 yet, which is the case at least with Azure and AWS, likely Google as well.

Interesting read, but it seems like a waste of time to keep finding little tricks and band aids with IPv4 when v6 exists.

> However not all enterprises or applications are ready for IPv6 yet

Ah yeah, there it is. Please, just fucking prioritize upgrading to IPv6 and be done with it. Frustrating.

Cloud providers need to hurry up as well, Azure still doesn't fully support v6 on their app services (web servers) either. It's in public preview but has been a roadmap item for longer. It also comes with certain caveats like what tiers can use it.

amazon (among others) is doing this for some time

rfc's have been written and forgotten, please calm down

djb on IPv6 incompatibility being a bad design choice: https://cr.yp.to/djbdns/ipv6mess.html

His points were wrong 22 years ago, and they continue to be wrong today. It's a poor document to cite as a rationale for avoiding IPv6.

Huh? It is not a rationale for avoiding IPv6. Quite the contrary. It is a critique on how IPv6 was designed without being interoperable with IPv4 address space. It is very clear that he was right given there are 22 more years of evidence of IPv4 still being very much with us, and foreseeable future.

Quote from the doc: “ Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place.” - this text is pretty much the definition of “IPv6 transition”.

Also from the document:

> Unfortunately, instead of simply allowing 16-byte A records, people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software.

"Simply". Yeah.

Until some non-upgraded client gets an 'extended-A' record response that's the "wrong" size (according itself) and drops the packet (which is the sane thing to do security-wise) and then you've just broken your DNS completely: IPv4 no longer works for some people, and neither does IPv4+.

So you have to wait until all client software understands extended-A records—but what's the motivation for enabling new client software if no one is enabling server-side records because there's no client software. Chicken-egg.

Which is one argument against IPv6: why enable client-side when there's no content, and why bother server-side if there are no client requests? Chicken-egg.

Yeah. “Why don’t you just…” :-)

djb has a lot of brilliant ideas and excellent implementations of them. But this is neither.

On the flip side this article could serve as a great example of a Nobel disease :-)

I wouldn't presume to criticize him in his areas of expertise. If he has thoughts on something involving crypto, darned if I'm going to be the one to say he's wrong. He's a sharp guy. He was speaking outside his wheelhouse here, though.

> He was speaking outside his wheelhouse here

He has written relatively well-known mail and DNS servers so I would not be that dismissive about him knowing a thing or two about internet RFCs.

I think the GP is taking the AAAA record overly literally and nitpicking the implementation detail. The analogy in djb proposal is MX records which fall back to A record. I don't think he would mind AAAA records that fall back to A record either, as long as the semantics are similar.

The main problem there is that what wished for was utterly impossible. RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt) section 3.4.1. "A RDATA format" defines an A record's data field as "A 32 bit Internet address." His change would require redefining that in a backward-compatible way, then incrementally upgrading every DNS server and client on the Internet to support both types of data in the same RDATA.

That sounds a whole awful lot like the exact problem he hoped it would solve.

And having written a nameserver and knowing what that ecosystem looks like, he knew that. And being famously security conscious (and competent), he knew what it would look like to get all the OS vendors to parse a 32 bit A record RDATA field as IPv4, and a 128 bit one as IPv6, and any other value as invalid, 100% of the time so that you didn't accidentally create a vulnerability by truncating addresses or such. It would've been chaos.

> I don't think he would mind AAAA records that fall back to A record either, as long as the semantics are similar.

He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote.

Further down after that he writes that the "client software, intermediate computers, and server software have all been upgraded to handle the client's extended address."

But what happens where there's software that is not upgraded? IMHO, if it's sane, it would reject the packet as malformed as security precaution. Congratulations, you've now broken DNS on the ('legacy') client. So you have to make sure every possible client is upgraded before you can even consider adding records with "IPv4+" addresses.

Or you could simply have two record types (e.g., A and AAAA) and legacy clients use one and updated clients the other, and you don't have to worry about breaking what already is working (plain-IPv4).

> He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote.

Sure, you can keep attacking the implementation detail here which he may or may not have overlooked. I would rather steelman his point, as highlighted by MX analogy, is to provide AAAA as an extension to A, not an independent parallel world. DNS client that's new enough would use AAAA-only, if present, and ignore A. As implemented today, there's no way for a server to "force" the client to use AAAA and treat A as legacy.

> So you have to make sure every possible client is upgraded before you can even consider adding records with "IPv4+" addresses

Yes, my understanding of his idea is for widely deployed servers to keep using an IPv4-visible address reachable from both v6 and v4 for a long time and clients will be first updated to IPv6 outside IPv4 window.

His idea, if I understand it right, is to do two transitions instead of one: 1) first, add 12 bytes to each address 2) then build out the IPv6 on this free space.

The problem is that (1) can not happen everywhere at once. So your “128bit IPv4” stack still needs a way to talk to “32 bit IPv4” stack, so you need to maintain somewhere a flag which one do you use.

So the problem is exactly the same as with the transition - you need dual stack everywhere, and a means to select which one to use.

I think the simplest analogy of this that makes the complexities more obvious to understand:

Imagine you have a network based on copper. (Twisted pair). Please upgrade the entire network to the optical fiber while maintaining the transparent connectivity between all the hosts at all times.

Edit to add:

bad analogy. Copper or fiber are sufficiently non-leaky to make the task relatively simple. Maybe a better one could be to migrate the hosts from IP to IPX. (Which is kinda similar to IPv6 sufficiently that it renders the analogy moot :)

> DNS client that's new enough would use AAAA-only, if present, and ignore A. As implemented today, there's no way for a server to "force" the client to use AAAA and treat A as legacy.

This is exactly how Happy Eyeballs works: request AAAA and A, and use AAAA if it returns.

Trying to force things one way or another is a recipe for a bad user experience.

Actually it is a little bit more subtle.

The intent with Happy Eyeballs was to focus on user experience: give IPv6 a slight initial advantage to hopefully only make only an IPv6 connection for the dual stack and not waste the network resources and CGNs bindings.

But at the same time, a short time after the start of the IPv6 connection, the IPv4 connection would also be initiated. Whichever connection wins, tilts the balance towards that address family for the next attempts.

This way the users on a broken or very slow IPv6 with fast IPv4 can still have a good experience, Internet Holy Wars notwithstanding.

Source: I am one of the two coauthors of the RFC6555.

Falling back to IPv4 if IPv6 does not succeed is literally the day 1 behavior of IPv6 transition. Except for TCP it may take a few minutes which is clearly unacceptable. So we wrote RFC6555. It still doesn’t help in the case of PMTUD black holes, but fixes the most obvious blunders. It’s still that you need to have a common protocol between the two endpoints, there is no way around it - so he just rephrases what is essentially “transition via dual stack” strategy but with his own words.

Once again - djb is a brilliant cryptographer, an application designer and coder, and I respect him very much for his genius there.

But I maintain that his thoughts on the topic of IPv6 transition unfortunately do not share this property, and reveal that he is completely ignorant of a lot of practical factors that are at play in that context.

It's almost always cited as exactly that: a reason why people are avoiding IPv6, as though it's proof that IPv6 is too hard to use, and that we could all be on it already if only we'd taken his advice.

It also completely misses the real reason we're not further along: people turned out to be willing to tolerate NAT's breakage. If we actually had to have a public IP per device, we'd have switched already. Instead, ISPs said hey, what if we put your entire house/apartment/office/city behind the same IP? And no one got guillotined or anything, so they did. DJB didn't mention that at all.

I found this humorous, the article literally says this:

"Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place."

As though this is any easier than just introducing IPv6 as a new, parallel protocol that does not have to interoperate (because IPv4 still works). I'm sure he can update his software and systems but what about the thousands of other programs and billions of other machines.

> I'm sure he can update his software and systems but what about the thousands of other programs and billions of other machines.

Well, empirically, we can see what we have now is that the software on billions of machines have been updated, but the transition has not completed. You have to eventually get there one way or another for the full transition, regardless of your transition methodology.

So, yes it may very well have been "easier" (as in shorter timeline) in the long term to accomplish the full transition under djb proposal.

“ As mentioned in Google VPC network valid IPv4 ranges, Class E addresses (240.0.0.0/4) are reserved for future use, as noted in RFC 5735 and RFC 1112 — however, that doesn’t mean you can’t use them today in certain circumstances.”

Wow. reserved means “kept aside”. Once someone starts using them, they stop being kept aside.

This means that de-facto they are private addresses now. I suppose it’s a pragmatic choice.

But, wow, so much for having interactions in relevant standards bodies, multistakeholder engagements, etc. Why bother. Classy. /s

Reply on news.ycombinator.com