From owner-freebsd-current Sun Dec 27 15:01:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13996 for freebsd-current-outgoing; Sun, 27 Dec 1998 15:01:24 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fep1-orange.clear.net.nz (fep1-orange.clear.net.nz [203.97.32.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13988 for ; Sun, 27 Dec 1998 15:01:19 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep1-orange.clear.net.nz (1.5/1.11) with ESMTP id MAA12245; Mon, 28 Dec 1998 12:00:57 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.1/8.9.1) id MAA28942; Mon, 28 Dec 1998 12:00:57 +1300 (NZDT) Date: Mon, 28 Dec 1998 12:00:57 +1300 From: Joe Abley To: "David E. Cross" Cc: freebsd-current@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: PPTP and FreeBSD Message-ID: <19981228120057.A28852@clear.co.nz> References: <199812272119.QAA13600@o2.cs.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199812272119.QAA13600@o2.cs.rpi.edu>; from David E. Cross on Sun, Dec 27, 1998 at 04:19:39PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 27, 1998 at 04:19:39PM -0500, David E. Cross wrote: > I had looked into this at the past, and read the relavent RFCs and MS > documentation on it. It is a bad joke, all the way arround. First it uses a > modified version of the GRE protocol (that is why I asked about GRE support > in the kernel way back when), as an encapsulation around the PPP packets. But, to be fair, GRE has been extended in a reasonable-looking and backward- compatible way. I don't personally agree with the methodology either, and would have preferred to see sequence numbers present in a further protocol header between GRE and PPP, leaving GRE as it is, but oh well... > It > also must have a TCP connection between the client and the server to act as > a controll connection. If that control connection is lost for whatever reason > , the tunel is closed. I don't really see why this is such a bad thing. The use of the TCP session is a bit clunky, but if the network is unstable enough that a TCP connection carrying minimal data cannot survive, then the tunnel probably _ought_ to be closed. > Oh yes, one last thing, the GRE portion of the tunel, > where the data actually goes, has an ack/nak, sliding window and retransmit > system (again, outlined in the MS documentation). The tunnel end-points do _not_ do retransmissions, but they do operate some (barely-specified) end-to-end flow control. > While I think this would > be a good thing to have, just to be compatible, and ideally as a part of a > larger 'iptunel' packagel; it is *alot* of work. I agree - it is a pretty nasty protocol, but has the advantage of widespread userbase support - show me one other tunnelling client which is ready and waiting on as many desktops as PPTP (even if the users don't know it's there). I've been looking at draft-ietf-pppext-pptp-07.txt and I don't thing that the PPTP elements look particularly difficult to code. A high-performance PPTP Network Server (PNS) implementation on FreeBSD could be made using existing PPP stacks, with the proviso that the tunnel creation/teardown would involve process switching (for the userland portions of PPP), and a server that was required to support a large number of simultaneously-active tunnels would correspondingly need a large number of kernel ppp/tun interfaces available (one per tunnel). A generic kernel tunnel interface would make this easier. Just some thoughts :) Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message