Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment

[YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>]

(2010/03/25 18:23), Jozsef Kadlecsik wrote:

>> First of all. in "sane" setup, people should configure according
>> to their own requirements.  They may or may not want send back
>> icmp packet.  And, even if the core is to send icmp back, the
>> state would be correctly assigned.
>
> I meant the state of the fragmented packets. If we let the uncompleted
> fragments to enter conntrack, as far as I see their state will be INVALID.
> Or should we add an exception and set their state to UNTRACKED in
> conntrack?

Got it.  INVALID seems fine to me so far
while further consideration might be needed.

>> For my conclusion, first option is just to drop
>> uncompleted fragments as we do today.  Second option
>> would be  to forward them to the next process so that
>> core code could send ICMPv6 etc. or, we could have
>> new code to send ICMPV6_TIME_EXCEED in REJECT target.
>> In longer term, I think it is better to introduce
>> per-exthdr hooks.
>
> I agree with your conclusion too, except a few question.
>
> It is unclear for me how can you forward the packets to the next process:
> above you pointed out that in defrag/reassembly before conntrack we do not
> know yet whether the packets are destined to the host or not. So again,
> how would you let through the fragments on conntrack then?
>
> I don't know how could the REJECT target help in any way.

Argh, more explanation.

If you unconditionally send ICMPv6, behavior would be
broken.

If you do really want to send ICMP in netfilter,
you could pretend additional rules in filter table.
For example, ICMP to be sent back only if other exthdrs
do not exist, and other packets to be silently dropped.

This cannot be our clean/final/full answer, so I said it'd
be better to introduce per-exthdr hooks in longer term.

Regards,

--yoshfuji