RE: IPv6 day and tunnels

["Templin, Fred L" <Fred.L.Templin () boeing com>]

Hi Brett,

> -----Original Message-----
> From: Brett Frankenberger [mailto:rbf+nanog () panix com]
> Sent: Monday, June 04, 2012 9:35 AM
> To: Templin, Fred L
> Cc: nanog () nanog org
> Subject: Re: IPv6 day and tunnels
>
> On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
> >
> > 3) For IPv6 packets between 1281-1500, break the packet
> >    into two (roughly) equal-sized pieces and admit each
> >    piece into the tunnel. (In other words, intentionally
> >    violate the IPv6 deprecation of router fragmentation.)
> >    Assumption is that the final destination can reassemble
> >    at least 1500, and that the 32-bit Identification value
> >    inserted by the tunnel provides sufficient assurance
> >    against reassembly mis-associations.
>
> Fragmenting the outer packet, rather than the inner packet, gets around
> the problem of router fragmentation of packets.  The outer packet is a
> new packet and there's nothing wrong with the originator of that packet
> fragmenting it.
>
> Of course, that forces reassembly on the other tunnel endpoint, rather
> than on the ultimate end system, which might be problematic with some
> endpoints and traffic volumes.

There are a number of issues with fragmenting the outer packet.
First, as you say, fragmenting the outer packet requires the
tunnel egress to perform reassembly. This may be difficult for
tunnel egresses that are configured on core routers. 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]. 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.
 
> (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 () 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