5 ms·

> IPv6 is as backward compatible as is possible within this constraint. Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers

> IPv6 is as backward compatible as is possible within this constraint. Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html FWIW I couldn't find the link to that post until finding it on one of the comments here, https://news.ycombinator.com/item?id=33894933 https://news.ycombinator.com/item?id=33894933 . That whole thread has lots of good commentary. I still don't understand how people can defend ipv6. I remember the "we better get ready to switch to ipv6" noise a quarter century ago when I started my career. And yet we're still talking about how v4 addresses are worth billions. Ipv6 has been an unmitigated disaster. The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.

welterde 3y ago
That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. This is just not possible. Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.
- j16sdiz 3y ago
  IPv6 is adding lots of complexity IPv4 never have to deal with. SLACC, interface-specific link-local address both look good in paper but cause lots real life headache. When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.
  - cbsmith 3y ago
    You can use DHCPv6 instead of SLAAC. Plenty of people seem to find SLAAC preferable... and interface-specific link-local addresses are key to making it work so...
- hn_throwaway_99 3y ago
  > Overall we are now much further into the IPv6 migration than djb ever envisioned. That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago. > is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks. I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/ https://xkcd.com/927/
  - welterde 3y ago
    I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion). It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server? One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
    - OJFord 3y ago
      I don't feel strongly about it, but my reading of the complaint is that the implication is it should've been something like an address in 240.0.0.0/4 plus more bits. Then to IPv4 it looks like a reserved for future use address (and we declare we're done with IPv4 now, there will be no (other) future use) but to (this hypothetical variant of) IPv6 it's a longer address. I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain. I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
- dataflow 3y ago
  > That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim. Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server) My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6. How can this work? Well, there are two scenarios: 1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa. 2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.) Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range. This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space. Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
  - welterde 3y ago
    The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6. The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
- butlerm 3y ago
  That document is not a proposal, it is a problem statement. It goes without saying that IPv4 only clients - every single one of them - would need to be upgraded in some fashion to support a larger address space. The issue is how to do that while remaining incentive compatible. The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem. The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number. And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.
  - dataflow 3y ago
    This is a really nice explanation, especially with the phone number analogy, thanks for writing it.
  - Symbiote 3y ago
    In the UK in the 1990s, all landlines phone numbers were prefixed with a 1, to create space for mobile phones and do on. Other changes were made in the early days, like the introduction of dialing, then long distance dialing.
lmm 3y ago
> Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.
- hn_throwaway_99 3y ago
  > It's a dumb post, to the point I think it must be a deliberate troll. Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.
  - oblio 3y ago
    Bernstein is known for being very... opinionated. For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.
  - growse 3y ago
    DJB's brilliance at some things doesn't make them immune from saying very silly things about other things.
    - hn_throwaway_99 3y ago
      I'm not saying he's right in all areas, and while it's certainly fine to disagree with his viewpoint, saying his essay "must be a deliberate troll" is laughable nonsense, especially since summarizing "my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is a silly mischaracterization of what djb actually said.
xorcist 3y ago
It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals which looked like today's IPv6 came. Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6. Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas. There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay. It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.
- butlerm 3y ago
  It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process. I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes. That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago. All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net. Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything. There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly. And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.
greyface- 3y ago
> The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads. Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".

welterde 3y ago

That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. This is just not possible. Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.

j16sdiz 3y ago
IPv6 is adding lots of complexity IPv4 never have to deal with. SLACC, interface-specific link-local address both look good in paper but cause lots real life headache. When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.
- cbsmith 3y ago
  You can use DHCPv6 instead of SLAAC. Plenty of people seem to find SLAAC preferable... and interface-specific link-local addresses are key to making it work so...
hn_throwaway_99 3y ago
> Overall we are now much further into the IPv6 migration than djb ever envisioned. That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago. > is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks. I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/ https://xkcd.com/927/
- welterde 3y ago
  I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion). It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server? One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.
  - OJFord 3y ago
    I don't feel strongly about it, but my reading of the complaint is that the implication is it should've been something like an address in 240.0.0.0/4 plus more bits. Then to IPv4 it looks like a reserved for future use address (and we declare we're done with IPv4 now, there will be no (other) future use) but to (this hypothetical variant of) IPv6 it's a longer address. I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain. I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.
dataflow 3y ago
> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim. Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server) My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6. How can this work? Well, there are two scenarios: 1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa. 2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.) Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range. This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space. Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
- welterde 3y ago
  The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it? The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6. The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).
butlerm 3y ago
That document is not a proposal, it is a problem statement. It goes without saying that IPv4 only clients - every single one of them - would need to be upgraded in some fashion to support a larger address space. The issue is how to do that while remaining incentive compatible. The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem. The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number. And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.
- dataflow 3y ago
  This is a really nice explanation, especially with the phone number analogy, thanks for writing it.
- Symbiote 3y ago
  In the UK in the 1990s, all landlines phone numbers were prefixed with a 1, to create space for mobile phones and do on. Other changes were made in the early days, like the introduction of dialing, then long distance dialing.

lmm 3y ago

> Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.

hn_throwaway_99 3y ago
> It's a dumb post, to the point I think it must be a deliberate troll. Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.
- oblio 3y ago
  Bernstein is known for being very... opinionated. For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.
- growse 3y ago
  DJB's brilliance at some things doesn't make them immune from saying very silly things about other things.
  - hn_throwaway_99 3y ago
    I'm not saying he's right in all areas, and while it's certainly fine to disagree with his viewpoint, saying his essay "must be a deliberate troll" is laughable nonsense, especially since summarizing "my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is a silly mischaracterization of what djb actually said.

xorcist 3y ago

It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals which looked like today's IPv6 came. Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6. Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas. There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay. It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.

butlerm 3y ago
It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process. I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes. That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago. All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net. Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything. There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly. And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.

greyface- 3y ago

> The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads. Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".