[support] UMIP: Disappearing packets ???

[Mattias Blomqvist]

Hi,

On Thu, May 14, 2009 at 1:29 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> 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 ;-)

The setup on the MN was the following after starting mip6d.
ip6tnl1<->outgoing interface (XX)<->.....<->HA
ip6tnl1 had a MTU of 1280.
interface XX had a MTU of 1280. (TUN/TAP interface in tun mode)

The middle box did not send packet too big since the packets never left the MN.

There were no fragmentation of IPv6 packets. That means that ip6tnl1
accepted an IPv6 packet of size 1280, added the outer IPv6 header
resulting in a size of 1320. But the kernel didn't send this to
interface XX since it has a MTU of 1280. Setting the MTU of XX to 1320
solved the problem.

So much for getting the packets to actually leave the MN.

If a router on the way report a packet too big with an MTU of 1280, as
far as I can tell it would end up in ip6_tnl_err here:
http://lxr.linux.no/linux+v2.6.29/net/ipv6/ip6_tunnel.c#L387
But the PMTU will never be set below 1280 which means the ip6tnl1
interface will always accept packets of size 1280, encapsulate them
and send them on their way with size 1320.

I don't know if the linux kernel doesn't fragment as is required by
RFC 2473 (see chapter 7.1(b)) or if mip6d sets up the ip6tnl interface
in such a way that it doesn't fragment?
mip6d sets IP6_TNL_F_IGN_ENCAP_LIMIT on the tunnel. Anything to do with this?

BR,
Mattias