[support] UMIP: Disappearing packets ???

[Arnaud Ebalard]

Hi,

Mattias Blomqvist <mattias.blomqvist at gmail.com> writes:

> Just an update that can be good for everyone to know.
>
> Regardless of the type of interface, the MTU of the interface declared
> as the home link must be set to a minimum 1320. That is because in the
> ip6tnl interface set up by mip6d, the MTU can not be set below 1280
> (hardcoded in linux kernel 2.6.29).

1280 is the minimum MTU for IPv6 links so that makes sense.

> This also means that any router along the path to the HA must accept
> 1320 as MTU as the linux kernel will never set the MTU of the ip6tnl
> device below 1280 even if a packet too big is sent back to it as a
> result of a 1320 byte long packet.

I understand your reasoning but it is not because a device has an MTU of
1500 that the kernel will not enforce a discovered PMTU of 1320 for a
specific peer. Put differently, there is a difference between the MTU of
the interface and the PMTU associated with some traffic exchanged with a
peer. Obviously, Linux kernel does not change the MTU of the interface
if some traffic sent via this interface has a lower PMTU but I think it
will update the PMTU value for that traffic.

Note that I do no say you are wrong on the need for 1320 on the path,
but i respectfuly disagree on the explanation. As for the need, I don't
know if the kernel code behind the ip6tnl device will fragment the data
it sends over 2 IPv6 packets. As it cannot report locally a packet too
big (mtu would be less than 1280), if it does not fragment, then you are
right on the need for a 1320 ptmu.

Does this mean the middle box that had the 1280 MTU on yout testbed was
sending ICMPv6 packet too big but it did not change anything? If the box
did not send ICMPv6 packet too big, then the question about the need for
a 1320 pmtu still holds, I think ;-)

Cheers,

a+