IPv6 day and tunnels
Masataka Ohta
mohta at necom830.hpcl.titech.ac.jp
Mon Jun 4 20:07:50 UTC 2012
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
More information about the NANOG
mailing list