MS Windows has supported ipv6 since 2008 and Linux has supported it since 2005. So why is it that your system is still using ipv4 to connect to the internet?

This is a response to : https://github.com/becarpenter/misc/blob/main/why6why.md https://lobste.rs/s/m0c78b/why_is_ipv6_so_complicated

The doc is insightful, but it misunderstands why ipv6 is still a pain.

It is also wrong about the “ipv8” option, which is actually nicely illustrated with the adoption of DNS-SEC and longer ATM frames.

Note that the https://www.ietf.org/archive/id/draft-thain-ipv8-00.html draft the author is refering to was written by somebody who is completely incompetent. The second and fourth sentence of the Abstract of the draft: “Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache.” and: “Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route.”

Errors/unreachable systems

Even today using a ipv6 only connection is completely unworkable.

Since not all services on the internet use ipv6, the need remains to have a fall-back. This is called the dual-stack. But since all services offer ipv4, it takes longer to use ipv6 and it is more error-prone to use. This means that there is a incentive for the user/support to disable ipv6 or even not enable it from the start. “Connection error? Please remove ipv6 from the network settings, and try again, says the support desk” .. and then never enable it, since why would you? In short normal users have no incentive to enable ipv6, but do have a incentive to disable it. Dual-stack has created so many problems that most browsers simply use the ipv4 connection if both ipv4 and ipv6 are available. The “Happy Eyeballs” algorithm is suppose to fix this, but so far without much success.

But now you ask: What about half of the internet traffic being ipv6?

This reflects the fact that more than half of all traffic is now from mobile devices. Mobile carriers use ipv6 or Carrier-grade NAT for all the mobile connections, since they don’t have enough ipv4 addresses. They use a protocol soup (NAT64/DNS64/CLAT/464XLAT) with ONLY ipv6 to make this work for your phone. Since your phone is only one device it only needs one 1 IP, since you are not going to run servers on it or have local devices that need a network.

So yes, simple client devices such as phones can use ipv6 if the clients network (ISP) compensates for it. But a simple client is not a server or a network.

NAT is Delegation

Why are people using ipv4 in their home/office networks?

The answer is: Frictionless delegation is not a bug, but a feature.

In a office or a home network things are different. Every system needs to have it’s own persistent IP. People and network admins also like to keep networks separated. Your network probably only has a single ipv4 address, and no ipv6 IP, or no ipv6 prefix. From the point of view of a system administrator it is much simpler to create one or more internal networks, and connect those to a router to the internet.

The most important thing to remember for this normal setup is that you don’t have to ask (and pay) the internet provider for more addresses (or wait for them to implement it). This is the reason why traditionally a router with NAT became the default. It also did not help that any Windows system that was connected to the internet was literally hacked in 10 minutes by automated exploit scanners. Another reason is that people like that their devices have a fixed local network address.

If you don’t think you use ipv4 in your network/home, then check. You are in for a surprise.

In short: People use NAT (even unknowingly) because it matches their organizational structure.

Network security

Nowadays it is possible to get a ipv6 prefix with most providers which you could configure on a router, but why would you? Most people don’t see the need for their printer or even desktop systems to be directly reachable from the internet. ipv6 proponents point out that you can firewall all incoming traffic by default, and that NAT is not a firewall, which is a pedantic argument: in practice people use it as such, and it seems to work fine for them. People use NAT as a firewall.

ipv6 proponents will point out that NAT was only a ‘ugly hack’ solution, to which the rest of the world replies: “We don’t care”.

Although it is now possible to use NAT with ipv6 (NAT66, created 16 years after ipv6), the IETF ipv6 workgroup has been extremely hostile towards NAT from the start. This because the explicit goal of ipv6 is to do away with NAT (restore end to end communications). IPv6 proponents argument against people not wanting to expose their private servers to the internet is that they should simply use a firewall, and make sure they don’t make any mistakes. This sounds a lot like: “ipv6, your TV is one typo away from being hacked”.

People use NAT in practise as a security (and organization) boundary.

Servers and ipv6

For a server on the internet there no incentive to use a ipv6 adres. This because while a ipv4 adres is required, ipv6 is optional, since the client systems can be relied upon to fall back to IPv4.

For server software other issues might come into play. Examples:

What if you use a SMTP-server/cluster with a RBL configuration (ipv4 only) ? Or another reputation system?

Another reputation system could be build, but the fact that that ipv6 addresses are inexhaustible, means that blacklisting is not an option anymore. This might seem theoretical, but as somebody who maintained a dual-stack spam-filter cluster I can attest that we only got spam on the ipv6 interfaces. I also points to another issue, which is: it is not just a matter of just adding a interface with ipv6, but all the software needs to be adjusted.

What if you use a transaction system that logs the connecting IP-address in a database?

Not only do you need to add another regex (Google for ipv6 regex versus ipv4 regex), but you can’t just increase the length of the database field to accommodate the IP, since it’s a completely different notation. Now imagine that a organization paid for custom software, but they do no have budget/prio to rewrite the software. This might not be normal for members for the IETF, but other people live in TheRealWorld(tm). This could have been prevented if ipv6 was not so radically different from IPv4.

What if you do not keep the ipv4 and ipv6 firewalls in sync?

You could get hacked though a ipv6 port that should be closed, but which can now be exploited. Why take the change?

What if a router in the whole chain (client or server) simply drops al ipv6 traffic?

Customers get extremely long timeouts before they switch to ipv4. Customers complain, the network admin gets the blame and simply decides to disable ipv6 to get rid of all potential problems.

Just as with client connections, there are hundreds or thousands of other small examples to give of why ipv6 complicates or disables things. I can testify that when network problems arise on a (new) VPS, they always turn out to be ipv6 problems. Since these problems are often outside of my control, and time is short, the sane and smart thing to do is simply disable ipv6. Yes, that is what people do in TheRealWorld(tm).

The point is that for normal operators of servers there is no incentive to enable ipv6 on their servers. It can and actually will create problems though, which creates incentives to just simply disable ipv6.

NB: Server operators actually were in favor of ipv6 adaptation, because every ssl connection required a unique ip-address, due to the way how ssl/tls negotiation works, but this has been fixed with SNI.

ipv6 changed everything

When I say that ipv6 changed everything, I don’t mean that in a positive “This changes everything!” way. The DNS records are different (A versus AAAA), the adres notation is different ( 127.0.0.1 versus ::1/128 ), the whole address-space is different, the kernel calls and structures are different. DHCP is different (DHCP vs SLAAC/NDP/DHCP6). In short everything is different. It is as if everybody was using Novel Netware, and they are now asked to switch to AppleTalk, but don’t worry: You can run a dual stack.

The author refers to this as “Did the IPv6 designers go mad?” (the Second-system effect), but states that ipv6 is actually not so different / complex:

Quote:

“The objective answer is “not much.” First of all, ipv6 really is a conservative design - it doesn’t change the basic IP model of connectionless packet switching with topological addresses.”

Stating that ipv6 is not so different, since it also is a stateless globally routed protocol is enough to make me spill my coffee and misses the point that the changes that were made all “leak though” to the user and application layers. They could have changed a lot as long as it stays inside of the TCP/IP abstraction. If only wireshark and the TCP stack and the number of octets for a IP-adres would have changed, we would not be here discussing why ipv6 is still lacking adoption. So yes, for a router the routing logic might still be more or less the same, but everything else has deep changes.

It was actually worse, since IPsec and DiffServ(QoS), Multicasting and RSVP were also mandatory part of ipv6. They tried to handle every possible problem in ipv6.

So no, IPv6 is not a upgrade of ipv4, but a completely new system, which uses a different protocol, different names, different notations, different configuration, different security models, different discovery, different software, different everything. It’s like replacing IPX/SPX with AppleTalk.

“Did the IPv6 designers go mad?” Hell, yes!

Adaptation does not have to be painful

The author asserts that since there is always “some change” in the protocol, you might as well have something something radically different. He claims that this is “mathematically inevitable”, which is the equivalent of your doctor saying that since you need to have your appendix removed, and this will cause some inconvenience, he will also replace your legs with tracked treads. But don’t worry: its mathematically exactly the same!

He even states:

Quote:

“the basic difficulties of ipv6 transition and coexistence have nothing to do with the design of ipv6”

This despite the fact that ipv6 is radically different from ipv4 in every possible way. Anybody who works in TheRealWorld(tm) knows that his assertion is not true.

It also begs the question: Could we have updated to a ipv8 protocol?

The author claims that this would be as complex as designing a completely new protocol"

“Just adding bits to the address isn’t as simple as it seems.”

What if we would have adopted something like ipv4x https://owl.billpg.com/ipv4x/ ?

Some frame-protocols and edge routers would have to be updated. But this would be a normal part of the ways systems are upgraded. Routers and servers/PCs could quite fast be upgraded to be able to enable this extension, but this might not everywhere be enabled (if for example the ATM router did not yet implement RFC2492). But the moment the router was updated, it could have enabled the new protocol extension. It would also have been a small change to change DNS resolver libraries to use AAAA records by default, which could use ipv6 AND ipv4 addresses. Routers could have simply have enabled ipv8, without any problems or any breaking backwards compatibility whenever ready. This because existing traffic works as it did before, and this silent upgrade would have been done without anybody actually useing it. This is not th same as “Flag Day”, since it does not require everything to be updated, and it also works if only the end-points are upgraded. Even if not all end-points are upgraded: It would work with most services, especially if almost all servers would enable it. Servers would still deploy ipv4 adresses, since they would have to be reachable for all clients, but once most existing servers would have enabled the extension, any ipv4x client would not experience any problems.

To enable ipv8 on existing ipv4 servers you would only need a recent kernel, which would not change anything except that it would recognize the new package format and use the embedded ipv8 adres part. This is all it would take to be ipv8 compatible on a server. No configuration needed.

All of these changes would have been non-breaking. Nothing would have broken or required a completely new protocol stack next to ipv4 if the changes in ipv6 were not so radically different from ipv4.

In fact: many changes in internet protocols happened this way. SMTP used to deliver mail to the A record of a system, until MX gave the option to administrators to specify priority. People used IMAP and only used IMAPs if this was supported and enabled. STMP uses Enhanced SMTP, and STARTLS if supported and enabled.

Non-breaking upgrade paths are normal, not the exception for most internet protocols.

But the author states that:

“Two minutes of thought show that this third requirement has only two solutions: 3A. Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. 3B. Translation, in which something translates addresses between the old and new protocols. "

One look at almost every protocol the internet ever had shows that there is a obvious extra choice, which is to extend the protocol. It could have used a IP option https://en.wikipedia.org/wiki/Internet_Protocol_Options to specify that this packet has a extended adres. If fact: the Address Extension option for ipv7 https://www.rfc-editor.org/rfc/rfc1475 could actually be used.

“IPv7 was a proposal for TP/IX: The Next Internet. It left as much of the IPv4 architecture as possible in place. It expanded the address space from 32-bits to 64-bits. That was a jump from 4.3 billion to about 18 quintillion addresses."

NB: it is worthwhile to read the ipv7 rfc https://www.rfc-editor.org/rfc/rfc1475 objectives. It foreshadows all the problems that ipv6 has.

The ipv6 authors must have know this rfc but all warnings, and simply dumped the problem of transitioning onto the world to figure out. Since then all kinds of Alphabet extra protocols have been created to help with transitioning (NAT-PT, NAPT-PT, 4in6Lightweight, 4over6, 6in4, 6over4, DS-Lite, 6rd, 6to4, NAT64, DNS64, Teredo, SIIT, MAP, TSP4rd) which have made things more complicated, not less. Just reading what people are expected to know and do to transition to ipv6 is enough to give you a headache.

And if I read the sentiment of the author correctly, then they are still in denial.

DNSSEC

The authors assertion about every change taking decades is incorrect : DNSSEC adoption has started later than ipv6 (in 2010), and is actually growing steadily without the ipv6 drama. The reason for this is that DNSSEC allows for a phased rollout, without breaking backwards compatibility. Resolvers that adopt DNSSEC are more secure, but resolvers who don’t use it still function.

See: https://blog.apnic.net/2023/09/18/measuring-the-use-of-dnssec/

And this despite the fact that ipv6 has a big economic driver, which is that ipv4 addresses have run out since 2019. https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-pool/

DNSSEC does not have this drive, but is actually getting adoption, without requiring a economic incentive.

Conclusion

The author and I do share this conclusion: “The main reason for ipv6, and its only real reason for existence, was bigger addresses.”

But we do not share his conclusion:

Quote:

“The problems of coexistence were inevitable, and it was hard to find the best (or rather, least bad) solutions. Most of the difficulties of ipv6 implementation and deployment are not the result of the details of ipv6 design. Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994. Both dual stack deployment and translation (of protocol plus addresses) were mathematically inevitable. No alternative choice can possibly avoid these issues.”

The author is trying to make the claim that there is no change in complexity between a protocol that bumps up the number from 4 to 5 with additional 128bit address length, and a completely different protocol. In a ipv8 world most of the code and protocol behavior would have stayed the same, and applications would have just needed to add a longer address length for the IP (the ipv4 address space would have become part of the ipv8 address space).

If a ipv6 had not insisted in changing everything, a simple upgrade path would have been possible. A protocol upgrade is NOT the same as a dual stack. Or even if it would: It would have been something that could have been enabled without any drama, just like the transition from HTTP to HTTPS has done.

In a ipv8 world, TCP/IP stacks would have been upgraded without drama. Kernel and library calls would have been changed to take into account the longer length, and applications would have been encouraged to use them, just as everybody is now using 64 bit time stamps on Unix. A application that refuses to use the new calls would only see the last 32bits of addresses, which would give collisions when the new address space is actually used, but which would be a incentive for the app to be fixed. All of the nuts and bells would be in place long before actual new ranges would be given out. And after that all existing traffic stays the same. Only when a ipv8 packet is encountered does the stack have to process it as such, which drastically reduces the number of problems users of the mixed ipv4/ipv8 stack could encounter. If after 10 years the usage of ipv8 is completely normal, vendors could switch to only send ipv8 by default.

Such a path is actually still possible. Applications which support ipv6 would not have to be adjusted, which is the fast majority of them.

Head in the Sand

To add insult to injury:

Quote:

“The community should avoid wasting time on such proposals.”

This after the author earlier statements: (the document was written to adres this)

Quote:

“every year or two people propose alternatives to ipv6 (“ipv8” is a generic name for such proposals, which mainly involve 8-byte addresses) because they have asked themselves that question”

Quote:

“Incidentally, “ipv8” proponents often ask why ipv6 didn’t simply stick some extra bits on the front of ipv4 addresses, instead of inventing a whole new format. Actually, we tried that: the “IPv4-Compatible ipv6 address” format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition. "

He refers to this, RFC3513 https://www.rfc-editor.org/rfc/rfc3513#section-2.5.5 which defines a way to tunnel ipv6 over ipv4, not “extra bits on the front of ipv4 addresses”:

“The ipv6 transition mechanisms include a technique for hosts and routers to dynamically tunnel ipv6 packets over IPv4 routing infrastructure. ipv6 nodes that use this technique are assigned special ipv6 unicast addresses that carry a global IPv4 address in the low-order 32 bits.”

That is not “trying a approach that simply sticks some extra bits on the front of ipv4 addresses”, but a full fledged transition to another protocol (ipv6), with some added tunneling. It is difficult to believe that the author is making this argument in good faith.

The author also seems to miss that everybody out there who is not part of the IETF ipv6 commission can see that ipv6 has so far been a failure. Despite the fact that ISP’s have no other choice than to adopt ipv6 (ipv4 address shortage) they only do so reluctantly, and others actually do not move at all. People are voting with their feet. Everybody else can see this, which is why they propose ipv8, so the world can move forward again.

The decision to actively disallow NAT is a political decision. There is nothing technical about it. I understand that the IETF does not like NAT (who does?), but stop trying to force it.

The decision to add all kinds of other features that are not required and make other breaking changes is also not a technical decision. I understand that the IETF wanted to rethink IP and add things that could be good, but this is not required.

The decision to have 2 completely different IP-spaces which do not overlap and have completely different notation is a political decision. I also don’t like a extremely long 1.1.1.1.1.1.1.1.1.1.1.1.1 dot notation, just as I don’t like OID addresses, but we can deal with them, and allow applications to use this and a shorthand afterwards.

Quote:

“Finally, it’s worth remembering that ipv4 is itself no longer simple. Compared with 1994, we now have a whole lot of complications: subscriber-side NAT, carrier-grade NAT, firewalls, IPsec, VPNs, Differentiated Services, link-local addresses, content distribution networks, etc.”

The author is making the case that ipv4 implementations are no longer simple if they want to implement all of the IPv4 extensions. This is not truth, since all the possible client devices out there actually have no need to implement all the extra extensions: Your phone is not going to need Carrier Grade NAT.

Port based traffic shaping and firewalls and existing VPNs and CDNs are also doing just fine, thank you. We don’t need ipv6 to have those, or don’t want them (IPsec is a complete clusterf*ck, that is why we use HTTPS and VPNs). We can (and do) have extra protocols on top of ipv4/ipv8 to implement extra functionality, this does not have to be done in ipv6. Things like GC NAT are not simple, but a simple system with a ipv4 (or ipv8) stack does not need to have NAT (we can put that complexity in the router).

Again: I understand that the IETF does not like NAT, but trying to force the world to stop using it has been one of the reasons why ipv6 adaption has never reached a critical point.

The IETF would be wise to spend some time and energy into venturing out in the world, and examining how people actually use networks.

Postscript: It turns out that DJB wrote more or less the same thing in 2002 : https://cr.yp.to/djbdns/ipv6mess.html. 24 years later, and nothing much has changed.

How to move forward?

“Insanity is doing the same thing over and over again and expecting different results” (Not by Albert Einstein).

1. Make a ipv8 standard that uses 128 bit addresses to finally address the ipv4 shortage. See https://owl.billpg.com/ipv4x/ for a more sane approach that could actually work. Just adding bits to the address might not be as simple as it seems, but it beats the alternative.

2. Stop caring how the world looked in 1994 and stop caring about the features that ipv6 is suppose to bring. There is only one feature we need, and that is a longer adres space.

3. Acknowledge that the IPv6 designers went mad. Then make a transition path from a ipv8 to ipv9. ipv9 should have all the features that ipv8 and ipv6 have so that adopting ipv9 does not break anything, but adds extra features.

Another, more insteresting path could be to use a new, tor or i2p like protocol to provide end-to-end security, pubkey based routing and anonymity.

This protocol would not care about the network it is running on. And as long as enough interconnects are availible, this everything could reach everything. It would however breakup the internet in at least two parts. Ironically, this would mean that the persons who most wanted to safe the internet (the ipv6 people) would end up breaking it.