[ianburrell]

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading.

The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix.

Also, extending IPv4 address space has the problem that bake the misallocation into IPv6. IPv4 is broken in the small chunks that makes the routing table large. It also means that new organizations will have a hard time getting address space cause they need to get IPv4 addresses.

[dangerlibrary]

"The length is the problem, IPv6 format is more compact."

"IPv4 still can't access IPv6. IPv6 can't access IPv4."

I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

[wtallis]

Making IPv4 addresses be a valid subset of IPv6 addresses would do nothing to help an IPv4 host reply to a packet from a host with a non-IPv6 address. Solving the "problem" of one-way communication without handling two-way communication is not worth anybody's time and effort.

[ianburrell]

The IPv6 address format uses hex, that is always going to be shorter than decimal. I like that it is fixed width, has zero compression, and is distinct from IPv4.

It is physically impossible for IPV4 32-bit addresses to access IPv6 with 128-bit addresses. Accessing IPv4 from IPv6 requires middleware to translate IPv6 to IPv4 and IPv4 response back to IPv4. That is NAT64.

[AnthonyMouse]

> If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

This is already the case. The format for representing IPv4 addresses in IPv6 is to encode the first 96 bits of the address as ::ffff and the last 32 bits as the IPv4 address, e.g. 192.0.2.128 as ::ffff:192.0.2.128. You can also encode the last 32 bits as hex if you want (::ffff:c000:0280 is the same address) but then it's less obvious what the IPv4 address is.

The problem is that every IPv6 address is not a valid IPv4 address, because the IPv4 address space is smaller so there is no way to do that without some kind of NAT or similar, which also exists but sucks in various ways.

[RiverCrochet]

This is like saying you want to put 16 gallons of liquid in a 4-gallon bucket. It just ain't gonna fit. You need a bigger bucket. Because a lot of people are still using carts that only hold 4-gallon buckets, let them keep using the 4-gallon ones until they get tired of paying IPXO for the 4-gallon bucket rental when the 16-gallon ones are free.

[AnthonyMouse]

The real trouble here is that the entities that need more addresses and the ones not supporting IPv6 aren't the same ones. In particular, a lot of large companies basically need one IPv4 address and they can NAT their whole organization behind it. Meanwhile ISPs and hosting providers need lots of IP addresses but can't switch entirely to IPv6 because their customers demand the ability to communicate with those companies that still only support IPv4.

But the government could probably fix it without even mandating anything. They should just... stop using IPv4. Does your company have to file tax forms with the IRS website? Only available via IPv6, so better get your network to support it.

[yjftsjthsd-h]

To some degree, no it's not a choice; you can't fit a 128-bit address in 32 bits. However, to the degree that it is possible, that exists; NAT64 does make every valid IPv4 address a valid IPv6 address.

[bongodongobob]

You talk about networking as if this is just about updating a regex somewhere. 32 bits is 32 bits, there's no way around that. IPv4 addresses not being valid IPv6 addresses has nothing to do with anything.