Date: Wed, 20 Oct 2004 08:15:51 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: "Patrick D. Feighery" <feighery@mitre.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: Divert and IPv6 Message-ID: <20041020151551.GB11477@odin.ac.hmc.edu> In-Reply-To: <200410201419.i9KEJbY17016@smtp-bedford.mitre.org> References: <200410201419.i9KEJbY17016@smtp-bedford.mitre.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?20041020151551.GB11477>