In my opinion the redesign of IPv6 was perfectly fine. The IPv6 headers are significantly simpler that those of IPv4 and much easier to process at great speed.

There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.

IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.

▲

fanf2 16 minutes ago | parent | next [-]

There are several ways to map the IPv4 address space into the IPv6 address space, going right back to the first IPv6 addressing architecture RFC. Every compatibility protocol added a new one.

IPv6 added IPSEC which was backported to IPv4.

IPv6 tried to add easy renumbering, which did’t work and had to be discarded.

IPv6 added scoped addresses which are halfbaked and limited. Site-scoped addresses never worked and were discarded; link-scoped addresses are mostly used for autoconfiguration.

IPv6 added new autoconfiguration protocols instead of reusing bootp/DHCP.

▲

throw0101d 43 minutes ago | parent | prev | next [-]

> The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.

> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]

* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

▲

xorcist 2 hours ago | parent | prev [-]

> The IPv4 32-bit address space should have been included in the IPv6 address space,

That's ... exactly how IPv6 works?

Look at the default prefix table at https://en.wikipedia.org/wiki/IPv6_address#Default_address_s... .

Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.

	▲	iso1631 2 hours ago \| parent [-]
		> You still need a dual stack configuration though, there's nothing getting around that when you change the address space Yes there is, at least outside of the machine. All you need to do is have an internal network (100.64/16, 169.254/16, wherever) local to the machine. If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. This can be even more hidden than things like internal docker networks. Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1 When the packet arrives at a router with v6 and v4 on (assume your v4 address is 2.2.2.2), that does a 6:4 translation, just like a router does v4:v4 nat The packet then runs over the v4 network until it reaches 1.0.0.1 with a source of 2.2.2.2, and a response is sent back to 2.2.2.2 where it is de-natted to a destination of 2001:1 and source of ::ffff:100.1 That way you don't need to change any application unless you want to reach ipv6 only devices, you don't need to run separate ipv4 and ipv6 stacks on your routers, and you can migrate easilly, with no more overhead than a typical 44 nat for rfc1918 devices. Likewise you can serve on your ipv6 only devices by listening on 2001::1 port 80, and having a nat which port forwards traffic coming to 2.2.2.2:80 to 2001::1 port 80 with a source of ::ffff:(whatever) (using colons as a deliminator wasn't great either, you end up with http://[2001::1]:80/ which is horrible)