Date: Wed, 19 Nov 2008 15:24:02 -0500 From: Randall Stewart <rrs@lakerest.net> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Thinking about UDP and tunneling Message-ID: <ECBF82BC-8F72-48EC-8E27-BA72AC8543C3@lakerest.net> In-Reply-To: <20081119153532.GB2910@onelab2.iet.unipi.it> References: <D72E9703-C8E7-4A21-A71E-A4B4C2D7E8F4@lakerest.net> <20081119153532.GB2910@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 19, 2008, at 10:35 AM, Luigi Rizzo wrote: > 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. Interesting idea, but the destination of the packets MAY NOT be the same box the fw/nat is on. So this means I now have to enable ipfw/nat on all boxes that want to have tunneling.. Not exactly very friendly... > > >> 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. I think it must be Paolo.. I will give him a ping R > > > cheers > luigi > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ECBF82BC-8F72-48EC-8E27-BA72AC8543C3>