From owner-freebsd-current Mon Dec 28 04:44:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA28082 for freebsd-current-outgoing; Mon, 28 Dec 1998 04:44:53 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA28077 for ; Mon, 28 Dec 1998 04:44:51 -0800 (PST) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id HAA00351; Mon, 28 Dec 1998 07:44:29 -0500 (EST) Message-ID: <19981228074429.V1333@ns1.adsu.bellsouth.com> Date: Mon, 28 Dec 1998 07:44:29 -0500 From: Christian Kuhtz To: Joe Abley , "David E. Cross" Cc: freebsd-current@FreeBSD.ORG Subject: Re: PPTP and FreeBSD References: <199812272119.QAA13600@o2.cs.rpi.edu> <19981228120057.A28852@clear.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981228120057.A28852@clear.co.nz>; from Joe Abley on Mon, Dec 28, 1998 at 12:00:57PM +1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Dec 28, 1998 at 12:00:57PM +1300, Joe Abley wrote: > > 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... Why do you need sequence numbers in the tunneling protocol when you're doing IP over MCMLPPP? > > 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. That is nonsense. A TCP connection adds latency that you *DO NOT* want. And today we have and use technology already which does provide full redundancy and load sharing regardless of whether it is TCP or UDP. In fact, TCP doesn't by you squat. Think of what the stack looks like: TCP/UDP TCP/UDP IP IP PPP or PPP L2TP L2TP [IPSec] [IPSec] IP IP PPP [..] FR/ATM How many layers of ack would you like? > 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. PPP is what's inside of L2F and L2TP, therefore you already got all those things covered. You guys are worrying about non-issues. PPTP is braindead use L2TP. > > 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. It's the responsibility of the payload, which is IP afterall. Not an issue. Further, your latency overhead would be much worse (and gain nothing) if you had tunneling protocol retransmits. > 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). L2TP will make it to those desktops very quickly. Just try to trust me on that one. > 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. Don't waste your time. L2TP is to replace PPTP. Cisco and Microsoft sponsored the L2TP development (and merger of L2F (cisco) and PPTP (Microsoft)). The L2TP backoffs have also finished and you will see much more L2TP than PPTP has ever seen very soon (not counting existing L2F services converted to L2TP). PPTP sucks because it is a session per use (do to the fact that they are all client initiated, and not NAS initiated like L2F/L2TP) > 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). I don't see what the issue is. With L2TP, you have one session per LAC/LNS association. What's the issue with supporting, say, 64 concurrent sessions? > A generic kernel tunnel interface would make this easier. tun? Cheers, Chris -- Frisbeetarianism, n.: The belief that when you die, your soul goes up on the roof and gets stuck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message