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 was written by somebody who is either a crackpot, or completely incompetent.

Errors/unreachable systems

Even today using a ipv6 only connection is generating errors.

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 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” .. and then never enable it, since why would you? In short normal users have no incentive to enable ipv6, and do have a incentive to disable it.

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) to make this work for your phone. Since your phone is only one device it only needs one 1 IP, or even only a single local-net IP, since you are not going to run servers on it.

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

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”.

People use NAT in practise as a security 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.

There are hundreds or thousands of other small examples to give of why ipv6 complicates or disables things.

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-adress, 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 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 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.”

He misses the point that the changes that were made all “leak though” to the 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 logic might still be more or less the same, but everything else has deep changes.

ipv6 is not a upgrade of ipv4, but a completely new system, which uses a different protocol, different names, different notation, different discovery, different everything. It’s like replacing IPX/SPX with AppleTalk.

Adaptation does not have to be painful

This is were we come back to the article. The author basically asserts that since there is always some change in the protocol, you might as well have something something radically different.

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?

Some frame-protocols and all routers would have to be updated. But this would be a normal part of the ways systems are upgraded. Routers and servers/PC could quite fast be upgraded to be able to run a dual stack, 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. It would also have been a small change to change DNS resolvers 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.

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.

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 stil 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 me 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. "

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

“The ipv6 transition mechanisms [TRAN] 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. "

The author 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:

Port based traffic shaping and firewalls and existing VPNs and CDNs are 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 have extra protocols on top of ipv4/ipv8 to implement extra functionality, this does not have to be done in ipv6. Things like 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?

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.
2. Make a transition path from 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.