anderstrier

> In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other. The specifications could have defined a functionally equivalent public IPv6 address for each public IPv4 address, embedding the IPv4 address space into the IPv6 address space; but they didn't.

Why didn't they? What are the arguments against this solution?

You would have to upgrade the software and OS of systems using IPv4-only to understand the IPv6 IP header. (Which is much simpler than upgrading to support IPv6 AND assigning IPv6 addresses)

I guess the bigger problem is that all routers in the path between an IPv6-only host and an IPv4-only host would have to support IPv6 to parse the destination IPv4/IPv6 address and make the proper routing decision.

This would make "IPv6 to IPv4 and vice-versa" traffic only work for some, depending on which ISPs has upgraded their equipment to support IPv6, and which IPv4-only hosts has upgraded their software+OS to support IPv6. This could result in IPv6 getting a very bad reputation, further delaying adoption.

Anything I am missing?

Thanks! I guess I should keep blogging then :)

I remember being able to overwhelm my first "home router" with the "Browse for servers" tab in Counter Strike 1.6! It would fetch a list of all servers from Steam, and then connect to them individually, eventually killing my router.

Consider sending Aussie Broadband a link to my blog post. It should be a simple fix for them to raise the timeout, which should fix the problem for all their customers.

They will increase their "TCP established connection idle-timeout" from 1 hour to 2 hours and 4 minutes as I requested.

This shouldn't make much difference for them. Most connections are closed within a few seconds anyways. Long lived connections with no traffic are rare.

With no data whatsoever, I'm guessing less that 1% increase in NAT table size.

Please read the post. My ISP already confirmed the problem, and told me that they expect to roll out a fix this week. I live in Denmark, and here it is fairly common that ISPs do Carrier-grade NAT.

I describe those workarounds in my post as well. But that only solves the problem for me.

Making my ISP fix the underlying issue - that their TCP connection idle-timeout is too short - will make sure all their customers won't have to encounter this problem.

Symptoms: apt-get update hangs, and the appstreamcli process is using 100% CPU.

Fix described here: https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/157...