Date: Wed, 19 Nov 2008 16:35:32 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Randall Stewart <rrs@lakerest.net> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <20081119153532.GB2910@onelab2.iet.unipi.it> In-Reply-To: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 19, 2008 at 10:00:27AM -0500, Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? the way (not the only one, but one way) this kind of things can be done now is have ipfw select the traffic, and pass it to one in-kernel natd instance, and after the work that Paolo Pisati did for SoC 2005 (it think) the mechanism is extensible in a relatively easy way to provide specific functions to do the mmbuf manipulation. > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... there isn't really a owner, over time different people including myself have worked on various aspects of the code -- if your changes affect only natd extensions then Paolo Pisati (piso@) is probably a good starting contact. You may want to have a look at the recent and not-so-recent commit history to see who did other relevant pieces of work such as dealing with locking, improving performance in SMP and so on. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081119153532.GB2910>