IPv6 tunnel MTU of 1480 not effective

[Kevin Oberman]

On Thu, May 9, 2013 at 2:06 AM, <sthaug at nethelp.no> wrote:

> > However I'm only able to send IPv6 packets from my host that fit an MTU
> > of 1280 even though I've set the tunnel interface and per-route MTU to
> > 1480, based on the "outer" ethernet connection having an MTU of 1500.
> > Hurricane Electric supports this and I've set the MTU to 1480 on their
> > side as well.
> >
> > This issue is evident when I try to send IPv6 pings larger than 1280
> > bytes to the remote tunnel peer.  The outgoing echo request is chopped
> > into two fragments, while the response comes back in one fragment, as
> > follows:
> >
> > % ping6 -c 1 -s 1432 2001:470:1f08:84f::1
> > PING6(1480=40+8+1432 bytes) 2001:470:1f09:84f::2 --> 2001:470:1f08:84f::1
> > 1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.514 ms
>
> This is a "feature" (i.e. it's documented). See the ping6 -m option:
>
> -m      By default, ping6 asks the kernel to fragment packets to fit into
>         the minimum IPv6 MTU.  The -m option will suppress the behavior
>         in the following two levels: when the option is specified once,
>         the behavior will be disabled for unicast packets.  When the
>         option is more than once, it will be disabled for both unicast
>         and multicast packets.
>
> In my opinion this behavior badly breaks POLA, and should be removed
> (i.e. the current -m behavior should be the default).
>
> I have no great hope in getting this changed, though...
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> _
>
Thanks, Steiner.

I complained about this at least a couple of years ago and was told by the
developer (I don't recall exactly who any more) that it was right and would
not be changed. I really would love to see this reconsidered before IPv6
becomes much more popular as it will simply cause confusion, but I, too,
fear that it is a lost cause.

Please prove me wrong!
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com