The IPv4+ could pass through a router that doesn't know about it - the cloud host that receives that packet could interpret it in a special way, in fact you could stuff additional data into the next layer of the stack for routing - it's not like many services beyond TCP would need to support the scheme.
> The IPv4+ could pass through a router that doesn't know about it
It couldn't do that reliably. We don't have any flags left for that that. Options are not safe. We've got one reserved flag which is anyways set to 0, so that's not safe either.
There's the reserved bit (aka the evil bit[1]). Are you saying gear out there drops packets with reserved bit set to 1? Wouldn't surprise me, just curious.
Seems like IPv4+ would have been a good time to use that bit. Any IPv4+ packets could have more flags in the + portion of the header, if needed.
That bit is currently defined as "Bit 0: reserved, must be zero", so there will be network gear out there, that either drops the packet otherwise or resets the bit to 0 when forwarding.
That makes it effectively impossible to ever use then, so a waste of a bit. Too bad they made that mistake when writing the spec. Would have been better if they specified it like most APIs, ie ignore if you get it, carry it if you forward, and set it to zero if you send it.
It depends what you want to achieve. If we had some feature which is actually incompatible and needed everything else to set it to 0, then it would be perfect. It's not a mistake when you don't predict the future.
