IPv6 day and tunnels

Brett Frankenberger rbf+nanog at panix.com
Mon Jun 4 16:35:03 UTC 2012


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.

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




More information about the NANOG mailing list