IPv6 day and tunnels

Mon Jun 4 21:23:13 UTC 2012

> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Monday, June 04, 2012 1:08 PM
> To: Templin, Fred L; nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
> 
> 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.

There are several factors to consider. First, each tunnel
ingress chooses its initial Identification value (or values)
randomly and independent of all other tunnel ingresses.
Secondly, the packet arrival rates at the various tunnel
ingresses are completely independent and in no way
correlated. So, while an occasional reassembly collision
is possible the 32-bit Identification value would make it
extremely rare. And the variability of packet arrivals
between the tunnel endpoints would make it such that a
string of consecutive collisions would never happen. So,
I'm not sure that a randomly-chosen "skip" value is even
necessary.

> > 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.

Outer fragmentation cooks the tunnel egresses at high
data rates. End systems are expected and required to
reassemble on their own behalf.

> > 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.

Non-overlapping fragments are disallowed for IPv6, but
I think are still allowed for IPv4. So, IPv4 still needs
the unique IDs by virtue of rate limiting.

> > 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.

I don't see any operational guidance recommending the
tunnel ingress to configure an MRU of 1520 or larger.

Thanks - Fred
fred.l.templin at boeing.com

> 						Masataka Ohta