Templin, Fred L wrote:
As your proposal, too, gives up to have unique IDs, does that matter?
This is taken care of by rate limiting at the tunnel
No, I'm talking about: Note that a possible conflict exists when IP fragmentation has already been performed by a source host before the fragments arrive at the tunnel ingress.
Note that, with your draft, a route change between two tunnels with same C may cause block corruption.
There are several built-in mitigations for this. First, the tunnel ingress does not assign Identification values sequentially but rather "skips around" to avoid synchronizing with some other node that is sending fragments to the same
I'm talking about two tunnels with same "skip" value.
Secondly, the ingress chooses random fragment sizes for the A and B portions of the packet so that the A portion of packet 1 does not match up properly with the B portion of packet 2 and hence will be dropped.
You can do so with outer fragment, too. Moreover, it does not have to be random but regular, which effectively extend ID length.
Finally, even if the A portion of packet 1 somehow matches up with the B portion of packet 2 the Internet checksum provides an additional line of defense.
Thus, don't insist on having unique IDs so much.
It is recommended that IPv4 nodes be able to reassemble as much as their connected interface MTUs. In the vast majority of cases that means that the nodes should be able to reassemble 1500. But, there is no assurance of anything more!
I'm talking about not protocol recommendation but proper operation. Masataka Ohta