[support] UMIP: Disappearing packets ???

[Mattias Blomqvist]

Hi,

On Thu, May 14, 2009 at 3:56 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> Hi,
>
> Mattias Blomqvist <mattias.blomqvist at gmail.com> writes:
>
>> 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)
>
> ok, had forgotten the tunnel iface was on you mn.
>
>> 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?
>
> Well, rereading the document, in your specific case and in theory, the
> tunnel XX is the one that should send the ICMPv6 packet too big to the
> ip6tnl iface. Then the ip6tnl iface should update associated pmtu and
> fragment packets that are over that value once encapsulated. Well, in
> theory.

The tunnel XX sends ICMPv6 packet too big as it should if it actually
receives the packet! It cannot send ICMPv6 packet too big if there is
no packet delivered to it... :)
The problem here was that the packet never arrived to the tunnel XX.
Probably because the kernel compared the packet size with the tunnel's
MTU.

RFC 2473, chapter 7.1(b) specifies that in this case the tunnel entry
point which is ip6tnl must fragment the packet. Which doesnt seem to
happen. Why? I don't know. It's kernel stuff anyway.

> I don't have much time to look at the code but this is an interesting
> question. Note that I initially had the same kind of issue when using
> miredo as my connection mean for umip. My /etc/miredo/client-hook now
> has a forced MTU of 1400.

And I forced my tunnel to an MTU of 1320. The problem will be if a
router on the way to the HA has a MTU of 1280...

>> mip6d sets IP6_TNL_F_IGN_ENCAP_LIMIT on the tunnel. Anything to do
>> with this?
>
> I don't have the time to look at what ip6ip6_tnl_xmit() and
> ip6_tnl_xmit2() will do with it
> ( http://lxr.mstier.de/linux/source/net/ipv6/ip6_tunnel.c#1018 )

I took a second look. IP6_TNL_F_IGN_ENCAP_LIMIT only effects the
encapsulation limit as far as I can tell. Not the fragmentation.

/Mattias