IPv6 tunnel MTU of 1480 not effective

[JINMEI Tatuya / 神明達哉]

At Sat, 11 May 2013 22:09:49 -0700,
Kevin Oberman <rkoberman at gmail.com> 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.
[...]
> 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.

What's "this" (to reconsider)?  That ping6 fragments outgoing packets
at 1280 octets (by default)?  Or, more in general whether any outgoing
IPv6 packet can initially honor the interface MTU?

If it's the former, I personally believe the default behavior makes
more sense because IPv6 doesn't have the concept of "don't fragment
bit", so any packet/fragment larger than 1280 octets could be dropped
at an intermediate router.  In theory, we could recover from that
situation if that router sent an ICMPv6 packet too big message and
the kernel performed path MTU discovery (which in my understanding is
not the case for non connected sockets like the one ping6 uses), but
even if PTMU discovery worked, some initial echo requests would still
be lost.  As a user, I wouldn't like to bother to wonder the reason
for the packet loss if my main concern is reachability check (that
would be my primary purpose for using ping6).

The same argument applies to non connected UDP sockets, and, in fact,
DNS server implementations behave exactly like ping6 in that sense
(fragmenting large DNS responses at 1280 octets), and exactly for that
reason.

If it's the latter, I thought at least TCP (if not also for other
connected sockets) honors the best possible MTU, starting from the MTU
of the outgoing interface.  If it doesn't, I agree with you; it should
be fixed, and I don't think it's a lost cause.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.