[153285] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Masataka Ohta)
Mon Jun 4 16:10:09 2012
Date: Tue, 05 Jun 2012 05:07:50 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>,
"nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65D374A8428@XCH-NW-01V.nw.nos.boeing.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
