Date: Mon, 28 Dec 1998 07:44:29 -0500 From: Christian Kuhtz <ck@ns1.adsu.bellsouth.com> To: Joe Abley <jabley@clear.co.nz>, "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: PPTP and FreeBSD Message-ID: <19981228074429.V1333@ns1.adsu.bellsouth.com> In-Reply-To: <19981228120057.A28852@clear.co.nz>; from Joe Abley on Mon, Dec 28, 1998 at 12:00:57PM %2B1300 References: <199812272119.QAA13600@o2.cs.rpi.edu> <19981228120057.A28852@clear.co.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981228074429.V1333>