Thinking about UDP and tunneling
rrs at lakerest.net
Wed Nov 19 12:24:09 PST 2008
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)
>> 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
More information about the freebsd-net