From owner-freebsd-net Wed Feb 9 12: 8:15 2000 Delivered-To: freebsd-net@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by builder.freebsd.org (Postfix) with ESMTP id E05074183 for ; Wed, 9 Feb 2000 12:07:59 -0800 (PST) Received: from trooper.velocet.net (trooper.velocet.net [216.126.82.226]) by sabre.velocet.net (Postfix) with ESMTP id 67B2A137F68 for ; Wed, 9 Feb 2000 15:07:29 -0500 (EST) Received: (from dgilbert@localhost) by trooper.velocet.net (8.9.3/8.9.3) id PAA66031; Wed, 9 Feb 2000 15:07:29 -0500 (EST) (envelope-from dgilbert) From: David Gilbert Message-ID: <14497.51456.635308.156936@trooper.velocet.net> Date: Wed, 9 Feb 2000 15:07:28 -0500 (EST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5Wcwg9B2VV" Content-Transfer-Encoding: 7bit To: freebsd-net@freebsd.org Subject: L2tp thoughts an implementations. X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --5Wcwg9B2VV Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Probably about the third mailing list that I have send the message below to, but Archie recomended that I forwarde it on here. Anyways... I also recently said: Archie> Yes, that sounds like a good idea (though I don't know much Archie> about VLAN). VLan is an exceedingly simple protocol. As I understand it, you add a 4 byte "number" to a raw ethernet packet. The 4 byte number is the vlan number. Having finished some of the packet munging stuff for l2tp, I'd have to say that this is so exceedingly simple, it might be worth just putting inside the ethernet node itself... maybe. I suppose it could go either way. Now... I started vaguely wondering to myself if we could create a ng_route node... which would have a routing table similar to the kernel's. This would give you CISCO-like vlan power --- you'd create a "vrouter" by attaching certain vlans to a route node. (which is also a relavant, but separate topic for this list --- it would seem that netgraph tech would make a more "appropriate" or "correct" vlan config ... considering the possibilities) --5Wcwg9B2VV Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <14497.40372.136664.641305@trooper.velocet.net> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid From: David Gilbert Subject: Netgraph and l2tp Date: Wed, 9 Feb 2000 12:02:44 -0500 (EST) Netgraph is seriously cool technology. I think we've briefly touched on this before, but I've been spending most of my week creating an l2tp node for it, so I thought I'd comment more on it's structure and use. For further reading, see your local FreeBSD (or NetBSD, but I believe Theo has rejected it) machine or http://www.FreeBSD.org/cgi/man.cgi?query=netgraph&apropos=0&sektion=0&manpath=FreeBSD+3.4-RELEASE&format=html Anyways, l2tp is somewhat like pptp in that encapsulates ppp over UDP. It is unlike pptp in that it encapsulates many PPP connections over one UDP tunnel. From RFC-2661: +-----+ +-----+ | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | | LAC | | LNS | | #######Control Connection######## | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | +-----+ +-----+ ... and I'm implementing the "LNS" (for now). Basically, in the ADSL case, remote system to LAC is PPPoE and the LAC then forwards the PPP frames inside the L2TP tunnel. What this means at my end that I have to manage the L2TP "glue," but the majority of the processing concerns stripping off the L2TP header (or adding it) with the remainder of the processing being straight PPP. Now, netgraph already has the following general PPP setup: ksocket <--> ppp <--> bpf <--> iface (UDP) ^ (ng0) | v socket <--> mpd (userland) mpd manages the whole lot, communicating through the ng_socket node. MPD does authentication and other administration, but the ng_ppp node does all the regular PPP stuff. Encryption and/or compression are provided by hooks on the ng_ppp node (hooks and nodes for this arn't shown). The ng_bpf node is simply present to detect packets to bring up the link on certain kinds of traffic. Now... to do L2TP, we're modifying this picture somewhat. In the following <-=> means "one to many." ksocket <--> l2tp <-=> ppp <--> iface ^ // | // v / socket <--> mpd In this case, mpd manages one (or more) l2tp nodes which each manage many (potentially thousands) of ppp nodes. I'm axeing the bpf node since the remote end will always initiate the connection. The cool part of this is that everything but the l2tp "glue" is already written. I've had to learn a few things about mbufs to work on ng_l2tp, but I'm getting around it. I've been thinking lately of working on adding vlan hooks to ethernet interfaces when I'm done this ... there already is vlan stuff in FreeBSD, but it would appear more elegant to use the netgraph stuff (and painfully simple) to do vlans. Using netgraph would also allow me to (basically) create vrouter type capability in FreeBSD. (In doing this, you might connect the vlan10 hook of fxp0 to the vlan35 hook of fxp1 --- effectively bridging the vlan. With a few more netgraph nodes, you could mix in things like bpf and/or some forms of firewalling or routing netgraph nodes.) Anyways... enough cool toys for now. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ --5Wcwg9B2VV-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message