IPv6 day and tunnels

Mon Jun 4 19:26:04 UTC 2012

> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Monday, June 04, 2012 12:06 PM
> To: nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
> 
> Templin, Fred L wrote:
> 
> > Also, when
> > IPv4 is used as the outer encapsulation layer, the 16-bit ID
> > field can result in reassembly errors at high data rates
> > [RFC4963].
> 
> As your proposal, too, gives up to have unique IDs, does that
> matter?

This is taken care of by rate limiting at the tunnel
ingress. For IPv4-in-(foo) tunnels, rate limit is 11Mbps
which may be a bit limiting for some applications. For
IPv6-in-(foo) tunnels, rate limit is 733Gbps which
should be acceptable for most applications.

> 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
(src,dst) pair. 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. 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.

> > Additionally, encapsulating a 1500 inner packet in
> > an outer IP header results in a 1500+ outer packet - and the
> > ingress has no way of knowing whether the egress is capable
> > of reassembling larger than 1500.
> 
> Operators are responsible to have tunnel end points with
> sufficient capabilities.

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!

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

> >> (With IPv4 in IPv4 tunnels, this is what I've always done.  1500 byte
> >> MTU on the tunnel, fragment the outer packet, let the other end of the
> >> tunnel do the reassembly.  Not providing 1500 byte end-to-end (at least
> >> with in the network I control) for IPv4 has proven to consume lots of
> >> troubleshooting time; fragmenting the inner packet doesn't work unless
> >> you ignore the DF bit that is typically set by TCP endpoints who want
> >> to do PMTU discovery.)
> >
> > Ignoring the (explicit) DF bit for IPv4 and ignoring the
> > (implicit) DF bit for IPv6 is what I am suggesting.
> >
> > Thanks - Fred
> > fred.l.templin at boeing.com
> >
> >>> I presume no one here would object to clauses 1) and 2).
> >>> Clause 3) is obviously a bit more controversial - but,
> >>> what harm would it cause from an operational standpoint?
> >>
> >>       -- Brett
> >
> >
> >
> 