From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 22:55:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580F31065672 for ; Wed, 19 Nov 2008 22:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1306C8FC14 for ; Wed, 19 Nov 2008 22:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5D88841C670; Wed, 19 Nov 2008 23:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id BcSXH-ouIL0w; Wed, 19 Nov 2008 23:55:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6446941C667; Wed, 19 Nov 2008 23:55:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 0379A444888; Wed, 19 Nov 2008 22:50:48 +0000 (UTC) Date: Wed, 19 Nov 2008 22:50:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Randall Stewart In-Reply-To: Message-ID: <20081119224027.U61259@maildrop.int.zabbadoz.net> References: <49245EE3.2000700@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: Thinking about UDP and tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 22:55:08 -0000 On Wed, 19 Nov 2008, Randall Stewart wrote: Hi, [UDP tunneling of "foo"] I am not following this thread at all but the transport_udp_input(mbuf, offset) jumped into my eyes. > Not sure what netgraph does... what is wanted is this in comes > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ ... > +-----+ > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function > > This changes the above to > +-----+ > | IP | > +-----+ ... > +-----+ > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. easy > to > drop a UDP header in out output... So I see things like this spring here and there and people start introducing more hacks on top of hacks on top of hacks these days to cicumvent dumb NAT setups. Right. No. So why the heck not use one of the dozend possibilities that you can find on rfc-editor.org to encapsulate whatever you want into UDP in a well defined protocol way rather than introducing yet another UDP-encap for yet another protocol? Stuffing X into UDP means having a policy to identify the next ULP possibly by port combinations, identify out of sequence data, identify randomly forged pakets insert into your stream, fragemation, \ldots \ldots \ldots possibly handshake all this first by the means of the ULP, \ldots \ldots \ldots reinventing the wheel over and over again. Ignore my 0.02CAD. /bz -- Bjoern A. Zeeb If you have a hammer, everything looks like a nail.