4 ms·
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 da
by yrjrjjrjjtjjr 6mo 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.
- icedchai 6mo agoNot 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.
- Dagger2 6mo agoPerhaps 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?)
- deleted 6mo ago[deleted]
- yrjrjjrjjtjjr 6mo agoThat'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.
- Dagger2 6mo agoThat'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.