IPv4 Fragmentation in a IPIP6 tunnel
Pietro Paolini
pulsarpietro at aol.com
Mon Nov 4 06:17:17 EST 2013
Hello,
I investigated better the problem, the MTU (WAN and LAN side) is 1500 bytes, I am running a test which send a packet of 1496 bytes LAN side and is not fragmented.
The problem appears because the size of the IPv6 header plus the payload (1496 bytes) is greater then the MTU (1500), at that point the IPv4 packet is fragmented while my expectation is that just the IPv6 should be. I placed a printk in the ip_fragment function and I can see that the packet is fragmented over there, my expectation is that piece of code should not been ever executed since i am sending over IPv6, I would remark that I don't have a fully understanding of the linux kernel networking stack implementation.
Where should the IPv6 fragmentation be done ?
Pietro Paolini
pulsarpietro at aol.com
-----Original Message-----
From: Fan Du <fan.du at windriver.com>
To: Pietro Paolini <pulsarpietro at aol.com>
Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>; p.paolini <p.paolini at genexis.eu>
Sent: Thu, Oct 31, 2013 10:39 am
Subject: Re: IPv4 Fragmentation in a IPIP6 tunnel
Hi Pietro
On 2013年10月30日 23:02, Pietro Paolini wrote:
> Hello everyone,
> I am working for an embedded Linux firmware running on a CPE and I am
> using an IP4 over IPv6 tunnel configured as following:
>
> ip -f inet6 tunnel add tun1 mode ipip6 remote XX:XX:XX local XX:XX:XX
> dev eth0
>
> And it works fine until I don't try to test the fragment case: I send a
> too big UDP packet and my expectation - and requirement (sob) - would
> be a IPv6 packet fragmentation but what I get is a double
> fragmentation (IPv4 and IPv6), then, summarizing:
>
> IPv4 --> [IPv4-1-segment][IPv6] [IPv4-2-segment][IPv6]
I didn't manage to test this, but a first glance make me think your expectation
has one requirement:
UDP packet + IPv4 header doesn't not exceed mtu of IPv4 src->dst, *AND* UDP
packet + IPv4 header exceed the IPv6 tunnel mtu.
UDP packet first has to fit into IPv4 layer size(phase 1), and then tunneled in
IPv6 style(phase 2). So two kinds of mtu involved here.
> Looking at the kernel code - which in I am not an expert - I observed
> that the function ip_finish_output :
>
> #if defined(CONFIG_NETFILTER)&& defined(CONFIG_XFRM)
> /* Policy lookup after SNAT yielded a new policy */
> if (skb_dst(skb)->xfrm != NULL) {
> IPCB(skb)->flags |= IPSKB_REROUTED;
> return dst_output(skb);
> }
> #endif
> #if defined(CONFIG_INET_IPSEC_OFFLOAD)
> if ((skb->ipsec_offload == 0)&&
> skb->len> ip_skb_dst_mtu(skb)&& !skb_is_gso(skb))
> #else
> if (skb->len> ip_skb_dst_mtu(skb)&& !skb_is_gso(skb))
> #endif
> return ip_fragment(skb, ip_finish_output2);
> else
> return ip_finish_output2(skb);
>
> Does not care about it, it just fragments if the MTU does not match.
>
> Is there any options to disable the fragmentation on IPV4 ? I am
> misconfiguring something ? Why does the ipip6 has this wrong behavior ?
>
> Thanks in advance,
> Pietro.
>
> Pietro Paolini
> pulsarpietro at aol.com
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
--
浮沉随浪只记今朝笑
--fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20131104/6be13651/attachment.html
More information about the Kernelnewbies
mailing list