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