Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Oct 2004 12:23:32 -0400
From:      "Patrick D. Feighery" <feighery@mitre.org>
To:        "'Brooks Davis'" <brooks@one-eyed-alien.net>
Cc:        freebsd-ipfw@freebsd.org
Subject:   RE: Divert and IPv6
Message-ID:  <200410201623.i9KGNdP07048@smtp-bedford.mitre.org>
In-Reply-To: <20041020151551.GB11477@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
I've looked into netfilter.  Unfortunately, I have not been able to find
sufficient documentation or sample code to start sinking my teeth into.
I've read man pages and the article in daemon news.  This technique appears
to have potential, however I've only found basic scripts that exercise some
basic features of netfilter.

Do you have some sample code I can look at on using ng_socket and ng_bpf?

Many thanks for the prompt response.

	Pat



-----Original Message-----
From: Brooks Davis [mailto:brooks@one-eyed-alien.net] 
Sent: Wednesday, October 20, 2004 11:16 AM
To: Patrick D. Feighery
Cc: freebsd-ipfw@freebsd.org
Subject: Re: Divert and IPv6

On Wed, Oct 20, 2004 at 10:19:30AM -0400, Patrick D. Feighery wrote:
>  
> 
> I have created a transparent transport layer Performance Enhancing Proxy
> (PEP) application to increase the performance of TCP applications over
> satellites and other challenged environment  based on the SCPS transport
> layer protocol (www.scps.org).   This PEP works by spoofing TCP
> applications.  Essentially, when the PEP see an incoming SYN, it spoofs
the
> connection and creates two separate transport layer connections,  one to
the
> end system and a second with an enhanced version of TCP with parameters
more
> appropriate and tuned for the challenged resource.  The peer PEP on the
far
> end of the challenged resource, terminates the enhanced TCP connection and
> opens up a third TCP connection to the actual destination.   Only the
source
> and destination IPv4 address are present in the IP packets that are sent
> though the network.   I have used the divert utility with great success to
> pass packets to/from kernel and application space in the PEP boxes.
> 
>  
> 
> When I ported this application to Linux, I  created a version based on the
> TAP interface and bridging.  A side effect of this method is PEP sees all
> traffic.
> 
>  
> 
> Now I have been tasked to port this application to IPv6.  What is the
status
> of divert for IPv6?  From some postings it does not appears to be
production
> quality yet.  If not, are there other techniques that I could use to pass
> data between the kernel and application space.  My initial implementation
> would assume no extension headers are present.

At this point we don't have IPv6 support for ipfw in the tree.  I've
posted patches based on work from one of Luigi's students, but they
aren't complete yet (they have routing problems when using dummynet and
currently IPv4 matching isn't working with them applied). These issues
are fairly high on my priority list so I certaintly expect something
workable within a month or so.  I hope to have it MFC'd in plenty of
time to have it well tested before 5.4.

As an alternative for now, you might take a look at using netgraph.  You
could tap the interfaces and use ng_bpf to sort only the traffic you
want before passing that part up via an ng_socket.

-- Brooks




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410201623.i9KGNdP07048>