Date: Mon, 28 Dec 1998 12:00:57 +1300 From: Joe Abley <jabley@clear.co.nz> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-current@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: PPTP and FreeBSD Message-ID: <19981228120057.A28852@clear.co.nz> In-Reply-To: <199812272119.QAA13600@o2.cs.rpi.edu>; from David E. Cross on Sun, Dec 27, 1998 at 04:19:39PM -0500 References: <199812272119.QAA13600@o2.cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981228120057.A28852>