Subject: PPP

From: "Bill Cunningham" <[email-masked]>
Date: Fri, 27 Dec 2002 11:19:39 -0500

Hey all,
    Other than rfc 1661, what rfc's should I look at to be up to date on
today's PPP? The rfc-editor has so many rfcs. Surely some must be
repetative.

---

From: James Carlson <[email-masked]>
Date: Fri, 27 Dec 2002 11:54:43 -0500

Bill Cunningham writes:
> today's PPP?

A lot, and the exact list depends on what you're trying to do.

> The rfc-editor has so many rfcs. Surely some must be
> repetative.

Uh, not exactly.

Making the rash assumption that you're trying to do IP over
asynchronous links (since you didn't indicate otherwise), you'll need
to look over at least these RFCs: 1662, 1332, 1334, 1994.  (RFC 1994
"obsoletes" 1334, but, in truth, there are still a lot of uses of PAP
in the world, so 1334 is still needed.)

You may need quite a few others.  Without details of what you're
trying to accomplish, it would be hard to make specific
recommendations of what to look at.  The lists are long.  For
instance, if you're in an MS environment, you might want 1877, 2118,
2433, 2637, 2759, 3078, and 3079 (note that 2118 and 3078 need 1962, a
standard, non-MS protocol).  Perhaps even a few others for IPX.

Some environments require SONET/SDH support, or OSINLCP, or even
AppleTalk.  You'll need to work that out first.

Of course, before you look at any of this, I strongly recommend that
you avoid reinventing the wheel.  Look around for free implementations
of PPP.  The protocols themselves aren't all that complex, but getting
all of the interactions right is quite hard.  The long-standing bugs
in many deployed implementations are a testament to this fact.  Adding
a new bug-ridden implementation to that list wouldn't necessarily be a
good thing.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Curtis Bemis <[email-masked]>
Date: Fri, 27 Dec 2002 09:05:39 -0800 (PST)

And, you were kind and definitely not self-serving  ;-)

I recommend "PPP Design, Implementation, and Debugging, 2nd Edition", 
James Carlson, Addison-Wesley, 2000, ISBN 0-201-70053-0, complete with a CD.

Curt...

-- 
________________________________________________________________________
*Curt Bemis                *      ||        ||      *Cisco Systems, Inc
*Phone: 561.741.0300       *    .||||.    .||||.    *San Jose, CA 95134
*Cell:  561.329.4769       * ..:||||||:..:||||||:.. *
*Email: [email-masked]   *   Cisco Systems, Inc.  * (home-Jupiter, FL)
_________________________________________________________________________

---

From: "Bill Cunningham" <[email-masked]>
Date: Fri, 27 Dec 2002 19:16:12 -0500

I guess I wasn't specific. But yes I don't want to reinvent the wheel. PPTP,
a MS protocol for linux is kinda what I'm looking at. I know PPTP is
proprietary, but something similar should work for linux. If it doesn't
already exist, and I'm not aware of it.

---

From: "Kory Hamzeh" <[email-masked]>
Date: Fri, 27 Dec 2002 16:26:24 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Bill Cunningham
> Sent: Friday, December 27, 2002 4:16 PM
> To: James Carlson
> Cc: [email-masked]
> Subject: Re: PPP
> 
> 

Look at L2TP. Does what PPTP does plus more and non-proprietary.

Kory

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 27 Dec 2002 16:29:31 -0800

Bill Cunningham [mailto:[email-masked]] writes:

> proprietary, but something similar should work for linux.

How about L2TP (http://www.l2tpd.org/)?

> If it doesn't

---

From: Frank Cusack <[email-masked]>
Date: Fri, 27 Dec 2002 18:45:10 -0800

> Look at L2TP. Does what PPTP does plus more and non-proprietary.

PPTP is not proprietary.  L2TP is, though.  Freely available, stable, unix
implementations of PPTP do exist.  http://pptpclient.sourceforge.net/
is a popular client implementation, http://www.poptop.org/ is a popular
server implementation.

/fc

/fc

---

From: Barney Wolff <[email-masked]>
Date: Fri, 27 Dec 2002 22:00:33 -0500

On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote:
> 
> PPTP is not proprietary.  L2TP is, though.

You seem to have a very odd definition of proprietary.  Both protocols
are published, but PPTP is strictly under Microsoft's control, while
L2TP is a standards-track IETF effort.  If sourceforge is your criterion,
both protocols are there.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

---

From: "Kory Hamzeh" <[email-masked]>
Date: Fri, 27 Dec 2002 19:50:22 -0800

> Behalf Of Barney Wolff

Took the words right out of my mouth. Thank you.

Kory

---

From: Frank Cusack <[email-masked]>
Date: Fri, 27 Dec 2002 20:37:49 -0800

> both protocols are there.

Yes, I guess I'm using a different (incorrect) definition of proprietary.
What I really meant was, PPTP is freely implementable.  L2TP is not.

I can write and publish an implementation of PPTP, without being beholden
to Microsoft whereas I must license L2TP from Cisco.  Of course, please
correct me if Cisco has granted no-cost license terms to anyone for L2TP.

/fc

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 27 Dec 2002 21:19:22 -0800

> What I really meant was, PPTP is freely implementable.  L2TP is not.

??

> correct me if Cisco has granted no-cost license terms to anyone for L2TP.

L2TP is is sole subject of RFC 2661.  Cisco holds no IPR WRT L2TP, nor does
it license it to or from anybody.

---

From: Frank Cusack <[email-masked]>
Date: Fri, 27 Dec 2002 22:06:28 -0800

> it license it to or from anybody.

Thank you for that clarification.  My confusion has been that L2TP is
derived from L2F, for which Cisco holds patent 5,918,019.  The text
of the patent ends with:

  Having described and illustrated the principles of the invention in a
  preferred embodiment thereof, it should be apparent that the invention
  can be modified in arrangement and detail without departing from such
  principles. I claim all modifications and variation coming within the
  spirit and scope of the following claims.

Are you stating that L2TP is sufficently different from L2F as to not
differ "in arrangment and detail without departing from such principles"?
[I do not know L2TP vs L2F well enough to give my own opinion.]

Given your history with the ietf, and your association with Cisco, I will
take your statement at face value.

Cisco issued a statement to the ietf saying that *if* any IPR claims for
L2TP apply they will issue license terms in non-discriminatory fashion.
Such a statement clearly leaves the door open for possible future legal
action.  Up till now, I don't think there has been any clear statement
that L2TP does not infringe; e.g. the book _L2TP_ by Richard Shea has
a section warning of possible patent issues.  Perhaps you could have
Cisco issue a statement to the IETF saying that L2TP does not infringe
on the L2F patent?

/fc

---

From: Barney Wolff <[email-masked]>
Date: Sat, 28 Dec 2002 01:58:58 -0500

> it license it to or from anybody.

L2TP != L2F and I don't know that even L2F would require a license.
Something of a moot point, these days.

---

From: James Carlson <[email-masked]>
Date: Sun, 29 Dec 2002 22:13:16 -0500

> it license it to or from anybody.

I would very much like to hear a clear statement from Cisco's lawyers
on this subject.  The last such public communication that I know of
was this one:

	http://www.ietf.org/ietf/IPR/CISCO-L2TP

This certainly leaves the situation a lot less clear than you seem to
be indicating, at least to me.

For what it's worth, I personally know several folks who've been
contacted by lawyers involved in L2TP IPR litigation (including
myself), and who are thus quite adverse to implementing any part of
that standard for that reason.  Talking to lawyers about IPR is not an
enjoyable part of the job.  If Cisco is not pursuing these claims,
then I think that'd be wonderful news to make known more widely so
that the standard can become more widely used.

> Something of a moot point, these days.

It doesn't matter what magic letters you use to identify the protocol,
nor what RFC numbers get assigned.  It doesn't matter if you think you
invented the protocol independently.  It doesn't matter if you think
the protocol is "dead" or a "moot point."  What matters when you are
forced to defend what you've done in court, as I am reliably told by
the law folk around me, are the individual claims made by the patent,
the validity of those claims as determined by the court, and whether
what you've done infringes on *any* of the valid claims in the patent.
US Patent 5,918,019, assigned to Cisco and cited by some 32 other L2TP
patents as prior art, includes these claims (I have omitted a few that
are related to L2F authentication; see www.uspto.gov for the full
text):

1. A method for creating a virtual dial-up session from a remote client to a
local network through an internet service provider, comprising: establishing
a point-to-point link between the remote client and the internet service
provider using a link level protocol; and

conducting a layer 2 forwarding protocol between the internet service
provider and the local network that projects the point-to-point link from
the internet service provider to the local network thereby creating a
virtual direct dial-up session between the remote client and said local
network.
[...]
3. A method according to claim 1 wherein the link level protocol comprises
at least one of a point-to-point protocol (PPP) and a serial line interface
protocol (SLIP).

4. A method according to claim 3 wherein the forwarding protocol projects a
link control protocol (LCP) from the internet service provider to the local
network.
[...]
8. A method according to claim 1 wherein the internet service provider is
connected to at least one of a public switched telephone network access and
an integrated services digital network access.
[...]
9. A method according to claim 1 wherein projecting the point-to-point link
includes the following steps:

establishing a layer 2 tunnel between the internet service provider and the
local network;

encapsulating the link level protocol in the forwarding protocol;

forwarding the encapsulated link level protocol through the tunnel;

stripping the forwarding protocol from the link level protocol and
processing the link level protocol with the local network as a direct
point-to-point connection with the remote client.

10. A method according to claim 1 including identifying the remote client as
one of a virtual dial-up client and an internet service provider client and
conducting the forwarding protocol only for the virtual dial-up client.

11. A method for establishing a virtual direct dial-up link with a network
access server, comprising:

conducting a point-to-point protocol session with remote clients;

identifying remote clients having virtual dial-up addresses;

authenticating remote clients having authorized access to a home gateway
according to a layer 2 forwarding protocol;

establishing a layer 2 tunnel connection with the home gateway for
authenticated remote clients; and

projecting the point-to-point protocol session through the layer 2 tunnel to
the home gateway according to the layer 2 forwarding protocol thereby
establishing a virtual direct dial-up link to the home gateway.
[...]
13. A method according to claim 11 wherein the step of projecting comprises
encapsulating the point-to-point protocol session in a layer 2 forwarding
protocol header and transmitting the encapsulated point-to-point session
through the layer 2 tunnel.

14. A method according to claim 13 wherein the layer 2 forwarding protocol
header includes a multiplex identification field for multiplexing multiple
remote clients through the layer 2 tunnel at the same time.

15. A method according to claim 13 wherein the layer 2 forwarding protocol
header includes a client ID field for demultiplexing multiple tunnels.

16. A method according to claim 13 wherein the layer 2 forwarding protocol
header includes a packet key for transmitting encrypted authentication
responses between the network access server and the home gateway.

17. A virtual dial-up system, comprising:

an internet infrastructure;

a dial-up server connected to the internet infrastructure;

a private local network;

a home gateway connected between the private network and the internet;

a remote client connected to the dial-up server, the remote client
conducting a point-to-point link level session with the dial-up server; and

a virtual dial-up protocol operating on the dial-up server for automatically
projecting the link level session from the dial-up server to the home
gateway thereby establishing a virtual direct dial-up session between the
remote client and the private local network through the internet
infrastructure.
[...]
24. A network access server, comprising:

an input receiving a point-to-point protocol session with a remote client;

an output connected to an internet infrastructure for transferring
information using an internet protocol; and

a processor and memory connected between the input and the output for
conducting a layer 2 forwarding protocol that projects the link level
session through the internet infrastructure to a local network independently
of the internet protocol.

25. A network access server according to claim 24 wherein the processor
attaches a forwarding protocol header to the point-to-point protocol
session.

26. A network access server according to claim 25 wherein the processor
negotiates a tunnel through the internet infrastructure to the local network
and transmits the forwarding protocol header and the point-to-point protocol
session over the tunnel.

27. A network access server according to claim 26 wherein the tunnel is
established independently of a dial-up phone number used by the remote
client for dialing up the network access server.

28. A home gateway, comprising:

an input connected to an internet infrastructure for receiving
point-to-point link level packets encapsulated in a virtual dial-up protocol
and transported using an internet protocol;

an output connected to a local network; and

a processor connected between the input and the output for conducting a
direct dial-up point-to-point link session through the internet
infrastructure to a remote client according to the virtual dial-up protocol
independently of the internet transport protocol.

29. A home gateway according to claim 28 wherein the processor establishes a
tunnel connection with a remote client according to the virtual dial-up
protocol.

30. A home gateway according to claim 29 wherein the processor authenticates
the remote client according to the virtual dial-up protocol prior to
establishing the tunnel connection.

If you feel that you can implement L2TP without running afoul of any
of those claims, then please be my guest.