[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200708020443.l724hDXg000916@toshiba.co.jp>
Date: Thu, 02 Aug 2007 13:43:12 +0900 (JST)
From: Yasuyuki KOZAKAI <yasuyuki.kozakai@...hiba.co.jp>
To: nakagawa.msy@...s.nec.co.jp
Cc: netdev@...r.kernel.org, davem@...emloft.net,
yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH 2.6.23-rc1][NETFILTER] nf_conntrack_reasm: adding
icmpv6_send code(TIME EXCEEDED).
Hi,
From: Masayuki Nakagawa <nakagawa.msy@...s.nec.co.jp>
Date: Wed, 01 Aug 2007 19:53:20 -0700
> I ran the TAHI conformance test on a kernel, which CONFIG_NF_CONNTRACK_IPV6
> is enabled. And then it showed a result including a couple of failure.
> The all of failed items are related to TIME EXCEEDED.
>
> The test procedure is here.
> Tester Target
> | |
> |-------------------------->|
> | Echo Request |
> | (1st fragment) |
> | |
> | wait for 65 sec. |
> | |
> |<--------------------------|
> | ICMPv6 Error |
>
> (1) Tester sends a first fragment of ICMPv6 echo request to Target.
> (2) Wait for over 60 sec.
> (3) If target replies a ICMPv6 error message(Time Exceeded) to Tester,
> then this test is success, otherwise it's failure.
>
> The reason of the failure is very simple, it's because icmpv6_send code are
> missing in nf_ct_frag6_expire function(nf_conntrack_reasm.c).
> The change is to add the missing code.
>
> In RFC2460, the specification regarding Time Exceeded is described,
> but it's defined as "should". So, there is no specification violation here.
> Therefore I'm not sure whether this change is appropriate or not.
>
> I will appreciate any comments. Thanks.
Main usage of nf_conntrack_ipv6 is for firewall today. I think that silently
sending error is not preferable. Moreover, RFC2460 says
4.5 Fragment Header
The Fragment header is used by an IPv6 source to send a packet larger
than would fit in the path MTU to its destination. (Note: unlike
IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path -- see section 5.)
This means that IPv6 router doesn't send Too Big error for forwarded
packets.
At least it's better to be configurable if people want to do that.
Second idea is to pass such fragments to next network processing instead of
dropping them. But I'm not sure that it is possible.
-- Yasuyuki Kozakai
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists