Bug 11797 - IPv6 conntrack treats neighbour and router solicitation packets as invalid
Summary: IPv6 conntrack treats neighbour and router solicitation packets as invalid
Alias: None
Product: Networking
Classification: Unclassified
Component: Netfilter/Iptables (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_netfilter-iptables@kernel-bugs.osdl.org
Depends on:
Reported: 2008-10-20 15:24 UTC by Marek Szuba
Modified: 2008-11-05 05:28 UTC (History)
0 users

See Also:
Kernel Version: 2.6.25
Tree: Mainline
Regression: ---

A patch to add the two ICMPv6 solicitation types to the "valid new" list. (459 bytes, patch)
2008-10-20 15:29 UTC, Marek Szuba
Details | Diff

Description Marek Szuba 2008-10-20 15:24:32 UTC
Latest working kernel version: N/A
Earliest failing kernel version: since introduction of IPv6 conntrack?
Distribution: all
Hardware Environment: all
Software Environment: IPv6 + netfilter + IPv6 conntrack
Problem Description:

The only two ICMPv6 packet types which IPv6 conntrack allows at present to initiate new connections are "echo request" and "node information query"; all other types appearing in this context are considered invalid. In particular, this includes two neighbour-discovery types specified in RFC 2461: "router solicitation" and "neighbour solicitation" - meaning that if a server drops all INVALID packets early in its INPUT or OUTPUT chain of IPv6 netfilter's filter table, neither of the two can be received from clients. Given that router solicitation is used for stateless network autoconfiguration and neighbour solicitation is an IPv6 equivalent of ARP requests, having these two dropped can be quite bad - especially the latter, as it pretty much kills IPv6 over Ethernet.

Steps to reproduce:

1. Obtain an IPv6 address assigned to an Ethernet interface of host A (link-local will do);
2. If necesssary, flush all ip6tables filter chains on host A and set their policies to ACCEPT;
3. From host B on the same Ethernet network, ping6 the aforementioned IP address to verify that everything works;
4. On host A, run something like "ip6tables -I INPUT 1 -m state --state INVALID -j DROP";
5. Try to repeat step 3. This time the ping should fail and counters associated with the aforementioned rule should increment;
6. Repeat all the above using OUTPUT instead of INPUT, with the same final result.
Comment 1 Marek Szuba 2008-10-20 15:29:05 UTC
Created attachment 18387 [details]
A patch to add the two ICMPv6 solicitation types to the "valid new" list.

Attaching a proposed solution to the problem - the patch adds "router solicitation" and "neighbour solicitation" to the list of ICMPv6 types IPv6 conntrack considers allowed to initiate new connections.

PS. This problem was discovered and (hopefully) fixed collaboratively by Łukasz Stelmach <steelman@post.pl> and myself, please attribute both of us should the patch make it into the kernel tree.
Comment 2 Patrick McHardy 2008-10-21 10:14:25 UTC
Thanks for the report and patch. This makes sense to me, but please send the patch and the problem description to netfilter-devel@vger.kernel.org and CC Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>, who is more knowledgable about this subject than me (bugzilla doesn't allow me to CC him myself).

Comment 3 Marek Szuba 2008-11-05 05:28:32 UTC
According to this post by Yasuyuki Kozakai to netfilter-devel


the issue requires a more complex solution. As such, this bug report was requested to be rejected.

Note You need to log in before you can comment on or make changes to this bug.