[Top] [All Lists]

Re: IPv6 fragmentation and IPv6 header parsing

To: Harald Welte <laforge@xxxxxxxxxxxx>
Subject: Re: IPv6 fragmentation and IPv6 header parsing
From: Brad Chapman <kakadu@xxxxxxxxxxxxx>
Date: Tue, 31 Jul 2001 20:27:20 -0400
Cc: netfilter-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <3B64B076.6090709@xxxxxxxxxxxxx> <20010729212317.I1486@xxxxxxxxxxxxxxxxxxxxxxx> <3B65914B.3070403@xxxxxxxxxxxxx> <20010731031710.J1486@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.7 i586; en-US; C-UPD: MaxLinux0301) Gecko/20001107 Netscape6/6.0
Mr. Harald,

Harald Welte wrote:

On Mon, Jul 30, 2001 at 12:54:35PM -0400, Brad Chapman wrote:

That's exactly what I was afraid of. The problem is that in order to implement connection tracking _without_ fragment handling for IPv6, one would
have to implement something like the options below:

   - No fragment handling; just configure your PMTU to a proper link size and
     NF_DROP fragmented packets; they belong to a broken implementation.
     This one is probably the most compliant with RFC2460, but if you must
     have fragmenting, you would need to run ip6_conntrack on an internal
     gateway and configure an external one to do relevant source fragging.

I guess you misunderstood something about IPv6. Having fragments is totally
legal, just routers don't fragment on-the-fly. But if one of the end nodes
of the connections want to fragment, they are allowed (but discouraged)
to do so.

Well, okay. I was under the impression that if you configured your low-level hardware to a decent PMTU size and somebody was doing fragmenting, that it was
broken and didn't deserve to be tracked. What do you mean by "discouraged" ?

- skb_clone() packets. Hold original; defrag copy, push into connection tracking subsystem. If packet makes it through, delete copy
     and release original. This one is not as bad as defragging original
     packets, but it is in violation of RFC2460 and sounds kludgy and bloaty.

well... it is a hack, yes.  If it really is in violation of the RFC - I'm not
As long as the conntrack does not send the defragmented copy of the packet,
but just delays the delivery of the fragmented original packets it could be
ok, IMHO. (The defragmented packet would only be used for conntrack internally).

   That could be a major problem. How much of a delay would be reasonable?
Something like (time to pass through conntrack) + (time to skb_clone() packet) ?

Another idea would be to defragment the packet internally while forwarding
all fragments which don't have the 'final fragment' bit in the IPv6 header
set. After we receive the last fragment of the packet, we send the internally defragged copy of the whole packet through conntrack. If the
decision of some policy says the packet is to be DROPPEd, we just never send
the last fragment, in which case the receiver has to drop all fragments after
60 seconds (or something like that, RFC2460 is more precise).

Ahhh. That makes sense. So you just grab the fragment header, and look for
the final fragment bit. Thus, the code path would be:

  - fragmented packet arrives at ip6_conntrack_in()
  - ip6_conntrack_in() scans frag header, looking for `final fragment' bit
  - not there: send it onward         there: stop forwarding
- ip6_conntrack_in() calls ip6_ct_gather_frags(), who calls ip6_reassembly()
  - we send the defragmented packet through conntrack
- NF_ACCEPT: send the final fragment onward NF_DROP: drop the final fragment

Is this correct? If not, then please point me in the correct direction ;-)

I don't think that this is a good solution either, but just needs to be
taken into consideration.

   - Rewrite the entire codebase to work properly with fragmented packets.
     Add functions like ip6_frag_scan() to scan fragmented packets, and
     change all packet-related stuff to use fragment functions to locate
     relevant packet data. TBH, that sounds frightening and personally, I
     wouldn't want to implement it.

Yes. This is what I would like to see in a 2.5.x rework of the whole conntrack, while also lifting it to a layer-3-protocol independent layer
(which would be needed for IPv4 <-> IPv6 NAT needed by lots of transition

Well, that's another thing entirely, and would have to wait until 2.5 is mandated.
OT1: does anybody know if Linus thinks it's time to open a 2.5 tree?

   If given a choice, and told that doing constant defrag/refrag of IPv6
   packets is slow, inefficient, and in violation of the RFCs (as I have been
   told), I would choose the first option.

I would most likely go for the 'defragment internally, delay fragments'
approach.  You have to take care of possible DoS attacks, be aware.

I agree. Anything like what we've just discussed would have to wait until you (or someone on the list) figured out a good way to select packets for trackage. OT2: any ideas? I can think of one already, but Henrik Nordstrom told me it would
add some overhead.

   BTW, what about header parsing? Am I at least doing that correctly?

sorry, didn't have the time to go through that.

Please have a look. Kis-Szabo Andras helped me out a lot on this, but I would
also like to ask someone who lives, breathes, and eats IPv6 ;-)


P.S.: Mr. Harald, I didn't know you subscribed to netdev....

;) well, I guess everybody related to linux networking development is subscribed here. And certainly all netfilter core team members fit within
that group...

Maybe I should subscribe as well..... ;-) Anyway, AOTB is great discussion for now, but I have started to play with the code and have found some more bugs in either ip6_conntrack, the ethertap setup, or the testsuite packet generators. Plus, the ip6t_state module is giving me fits about `unrecognized arguments' >:-(
I'll have to compile with -D0 and pore over the logs for a while......


<Prev in Thread] Current Thread [Next in Thread>