Hacker News new | ask | show | jobs
by j1elo 80 days ago
In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.

What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.
4 comments
throw0101c 80 days ago
> What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it.

Like:

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

link
Hikikomori 80 days ago
They did that. Problem is that an ipv4 only host can't talk to ipv6. Adding more bits to ipv4 creates a new protocol just like ipv6 and has the same transition issues.
link
zamadatix 80 days ago
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....

& the following section for the follow-up embedding.

link
yrjrjjrjjtjjr 79 days ago
The protocol field in the ipv4 header seems like a reasonable choice. A value would be associated for ipv6 and if that value is chosen then additional header data follows the ipv4 header.
link
Dagger2 79 days ago
Perhaps you could use 41, the value already associated with doing this.

(What's up with people constantly suggesting that v6 should do things that it already does?)

link
yrjrjjrjjtjjr 78 days ago
That's similar to, but not exactly what we were discussing. In particular 6in4 has a full ipv6 header after the ipv4 header, but here the suggestion was instead that supplementary infomation would follow. For example, the most significant address bits could be stored in the ipv4 header and the least significant ones in the new part.
link
Dagger2 78 days ago
That's not meaningfully different. It would just amount to a slightly less redundant representation of the same data -- the steps needed to deploy it would be the same, and you'd still have all the same issues of v4 hosts not understanding your format.
link
icedchai 79 days ago
Not really reasonable. That would 1) Make routing inefficient because routers have parse an additional, non-adjacent, non-contiguous header to get the source and destination addresses. 2) Break compatibility because there would exist "routers" that do not understand ipv6 headers. They receive your ipv4 with v6 packet and send it somewhere else.

The result is basically the same situation we are in today, except much more hacky. You'd still have to do a bunch of upgrades.

link