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