Subject: RE: PPP

From: TOMSON ERIC <[email-masked]>
Date: Mon, 4 Mar 2002 12:12:35 +0100

I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite.

It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...).

PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc.

Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) :  LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...).

E.T.

(*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model.

--- The basic answer ends here ---

Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network.

--- The extended answer ends here ---

-----Original Message-----
From: vint cerf [mailto:[email-masked]]

IP is encapsulated in PPP for all practical purposes. PPP can support
multiple protocols on a single point to point link in the same way
ethernet can support multiple protocols

vint
At 08:01 AM 3/1/2002 -0500, Bill Cunningham wrote:
>Is IP actually encapsulated in PPP, or is PPP and IP sent out at the same
>time at different protocol layers? Kinda holding hands in a sense to each
>other.

---

From: grenville armitage <[email-masked]>
Date: Mon, 04 Mar 2002 09:39:01 -0800

Layering dogma get all confused and convoluted when faced with
engineering ingenuity. At what layer is ATM in the old Cells
in Frames spec? Or PPP when running ppp sessions over TCP?
Or <blah> over MPLS frames over PPP (over TCP)? Or....?

PPP is a layer below the one it serves, and a layer above the
one it uses. Just like most other protocols.

cheers,
gja 
-- 
Grenville Armitage
http://gja.space4me.com

---

From: Brian Lloyd <[email-masked]>
Date: Mon, 04 Mar 2002 08:49:20 -0800

>to the TCP/IP protocol suite.

Other than it was designed for IP and the other stuff came along for the 
ride.  PPP was a relatively early product of the IETF and specifically 
designed for IP.

>It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols 
>(like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...).
>
>PPP succeeded SLIP by bringing extended features : SLIP could only 
>encapsulate IP while PPP can encapsulate several protocols, PPP supports 
>authentication while SLIP didn't, etc.
>
>Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to 
>be implemented on existing lower layers (1 and 2) :  LAN (Ethernet, Token 
>Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...).

This is a common misconception.  The "lower layers (1 and 2)" that you 
mention are often completely routable networks in and of themselves.  You 
can even encapsulate IP within IP therefore IP is operating at layer 2 from 
that interpretation.  Ethernet is regularly routed now (people call it 
switching but a rose by any other name ...).  So all of these, including 
PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, 
transport, application) or layers 1-3b in the ISORM.

This problem plagues developers working with PPP for the first time because 
they keep thinking in terms of PPP being only a link-layer protocol.  If 
they would remember that PPP operates at the network layer then they would 
stop making stupid mistakes like a badly-designed L2TP.

>E.T.
>
>(*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 
>4 Switch : it doesn't depend on the protocol suite above, so we always 
>refer to the vendor- technology- protocol-independent OSI reference model.

I love watching people slavishly adhere to this or that model of 
layering.  Layering is a convenience, not a religion.  (Actually, I got 
that backwards.)  With the widespread use of encapsulating one networking 
or internetworking protocol in another, the whole concept of rigid layering 
goes out the window.  The cry of, "its a network layer; its a link layer," 
should be right up there with, "its a dessert topping; its a floor wax!"

>Now a small yet technical recall : when data comes from an application to 
>be transported on a physical medium (copper cable, fiber optics, radio 
>waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP 
>(Layer 3)

ISO spent a lot of time trying to sell the 7-layer model and then didn't 
know how to backtrack when they discovered that there were really two 
network layers when you interconnect dissimilar networks using an 
internetworking protocol.  ATM, FR, Ethernet, etc., are all routable 
layer-3 protocols in their own regard so they opted to break layer three 
into three sublayers. (It is really three layers by their reckoning but ISO 
already had so much invested in the "ISO Seven Layer Reference Model [tm]" 
that they couldn't really switch to the "ISO Nine Layer Reference Model 
Formerly Known As The Seven Layer Reference Model [tm].")

>that encapsulates it in a datagram/packet and specifies the destination 
>network+host address. Then it's forwarded to PPP (Layer 2) that 
>encapsulates it in a frame and specifies the way bits are organized to 
>travel through the physical medium. Then it's forwarded to some Layer 1 
>technology that converts the bits into a specific signal using a specific 
>encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches 
>the physical medium to be physically transported through the network.

To some extent you are right but your model needs to accommodate things 
like L2TP which tunnels traffic at layer 1|2 (depending on the model of the 
day) in a layer 4 (transport) protocol, or IP tunneled in IP.  It is 
probably better to be able to keep the concept of duality in your mind, 
i.e. when you hold you tongue one way it looks like a link protocol but 
when you hold your tongue a different way it looks like a transport 
protocol.  I suspect that something like this gave early physicists fits 
when they were faced with the duality of nature.

So trying to be rigid in your categorization of any protocol is likely to 
cause you heartburn down the road (ask ISO).  It is far better to 
understand where it makes sense to put interfaces and then perform the 
functions that need to be performed.

>ethernet can support multiple protocols

And, no, as the above quote shows, Vint did not say that PPP does not 
belong to the TCP/IP protocol suite.  He just says that PPP usually 
encapsulates/transports IP datagrams as its payload.  His comment that PPP 
and Ethernet are functionally equivalent is interesting if you mull over 
all the ramifications of that statement.

Brian Lloyd
[email-masked]
+1.530.676.1113 - voice
+1.360.838.9669 - fax

---

From: "Bill Cunningham" <[email-masked]>
Date: Tue, 5 Mar 2002 10:02:22 -0500

whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP
and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore
faster than TCP. They are encapsulated in IP, which is put into the data
bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent
at that level. BTW I have 56K dial-up no ISDN or DSL.
----- Original Message -----
From: "Brian Lloyd" <[email-masked]>
To: "TOMSON ERIC" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 04, 2002 11:49 AM
Subject: RE: PPP

> >I couldn't say it shorter and more clearly than Vint : PPP does NOT
belong
> >to the TCP/IP protocol suite.
>

---

From: Christopher Evans <[email-masked]>
Date: Tue, 05 Mar 2002 23:02:24 -0800

Here is a question that will tax your synapes to bursting point!

How is PPP and TCP/IP libs "wired" together?  Like, DO I (OSI 8) call TCP
and it calls IP and down the 
chain till it spills over and gets real physical (OSI 1)? I am confused.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 06 Mar 2002 11:42:07 +0100

> stop making stupid mistakes like a badly-designed L2TP.

I don't see how classification of PPP as a layer 2, layer 3, or any other layer
would have had an affect on how we designed L2TP (perhaps it would have affected
the name of the protocol though). Layers aside, PPP was already deployed and it
was pretty obvious what we wanted to do - make it run over IP without the
installed base of PPP clients being made aware of it. How would you have done
this that is substantially different than L2TP? (As an aside, of the list of
obscene things we did have to do to make L2TP work, the worst were more due to
badly implemented PPP stacks than anything else.)

Tunneling, particularly L2 tunneling, is by its very definition a "layer
violation". The perfect world where this is not necessary or desirable does not
exist beyond textbooks and laboratories. So here we are in the real world,
tunneling not just PPP but a plethora of L2 or L2-like layers. 

- Mark

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 6 Mar 2002 11:19:30 +0000 (GMT)

On Tue, 5 Mar 2002, Bill Cunningham wrote:

> faster than TCP.

Well, that's wrong.

TCP and UDP depend on IP and are part of the suite, in UDP checksums
are optional but turning them off is often shown to be a bad idea, and
UDP can be faster than TCP because it doesn't have Nagle or congestion
control or weird ack timings. This is well-documented in a vast number
of places.

> They are encapsulated in IP, which is put into the data
> at that level.

bitstreams, frames, and Layer 1 are completely different things.

> BTW I have 56K dial-up no ISDN or DSL.

I have no contrary evidence.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brian Lloyd <[email-masked]>
Date: Wed, 06 Mar 2002 09:10:21 -0800

At 02:42 AM 3/6/2002, you wrote:
>the name of the protocol though).

PPP actually consists of two distinct and separate sets of protocols.  The 
LCP and its negotiation should be totally separate from the NCPs and their 
negotiation.

>Layers aside, PPP was already deployed and it
>installed base of PPP clients being made aware of it.

Do it right would not have changed that.

>How would you have done

<sigh> It has been many years since I argued this with Karl Fox back when 
he chaired the L2TP WG.  At that time he agreed but also said that there 
was too much water under the bridge to fix L2TP at that time so it was 
going to go forward in its subtlely-broken form.  I haven't looked at it 
since then.  I don't even remember the lexicon so I will undoubtedly sound 
uninformed.

The LCP negotiation should take place with the L2TP equivalent of the 
NAS.  That is independent of anything else that happens and nothing 
associated with that needs to be communicated to the edge device at the 
target network.  The authentication phase then takes place so you can do 
authorization and configuration.  Once that is complete you can do the 
MLPPP and NCP negotiation(s) because then and only then do you know what 
the end system is authorized to do.

"But MLPPP is negotiated during LCP," you say!  Right.  That is broken and 
I helped make it broken and, in retrospect, I am *really* sorry I did.

So, as I said, this is water under the bridge and it isn't going to 
change.  Any attempt to do so would be met with a barrage of "but we have 
lots of systems in the field and this would break them" arguments.

>tunneling not just PPP but a plethora of L2 or L2-like layers.

There is nothing wrong with tunneling per-se.  In fact, it solves many 
problems.  IMHO tunneling is a good thing.  My comments had only to do with 
the fallacy of rigid layering, how many people don't really understand 
layering, and as a side issue, how PPP was really a suite of protocols at 
different layers and how that affects MLPPP and L2TP.

YMMV

Brian Lloyd
[email-masked]
+1.530.676.1113 - voice
+1.360.838.9669 - fax

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 07 Mar 2002 08:59:40 +0100

Brian Lloyd wrote:
> he chaired the L2TP WG.  

Karl chaired only the pppext WG.

> At that time he agreed but also said that there
> authorization and configuration.  

That would have been nice, but, the requirements were that it be possible for
user authorization be completed at the LNS (the edge device at the target
network), and at the LAC (NAS). In addition, we could not require the user to
enter a username and password twice. You simply had to be able to drop in L2TP,
and everything look the same as it did before to the end user. 

> Once that is complete you can do the

Yup, that would have been nicer.

> I helped make it broken and, in retrospect, I am *really* sorry I did.

That's OK, we'll forgive you ;-)

Barring redesign of PPP, getting around the wrong things being located in the
LCP negotiation would have been made a little easier if we had been allowed to
go through LCP negotiation twice. So, you could have LCP negotiated at the LAC,
forward any necessary link parameters to the LNS so that it could set them
correctly during "LCP round 2", and then renegotiate LCP at the LNS to get
things like MLPPP and perhaps authentication type which should have been
designed into the negotiation process later. But -- and here is the point about
broken PPP stacks -- at the time there were a lot of PPP stacks which would
simply roll over and die if you tried to reneogtiate LCP after you had already
begun (yes, in great violation to what it says in RFC 1661). This wasn't
discovered until L2TP came along because before that, you really didn't see LCP
renegotiation occur very much. But, it was way too late as there were so many
clients in the field with this bug. So, we ended up with Proxy LCP and Proxy
Authentication like you see them today. There's not much else you can do if you
want to complete PPP negotiation at the LNS, but *start* it at the LAC so that
you can get the "@domain" portion of the username to determine where to tunnel
the user. Sigh... Yes, if we had thought about running PPP over IP from the
beginning, things might have looked very different in general... A more seperate
link layer negotiation would have been one of them. But, PPP isn't nearly as
difficult as, say, TDM over IP ;-)

There are even other "bugs in the field" we have had to code around with IPCP
negotiation, and don't even get me started on ACCM mapping....

> lots of systems in the field and this would break them" arguments.

Right. The same argument that led to some of the choices we had to make in L2TP.

> different layers and how that affects MLPPP and L2TP.

Then we agree more than we disagree :-)

---

From: Brian Lloyd <[email-masked]>
Date: Thu, 07 Mar 2002 08:39:40 -0800

>Karl chaired only the pppext WG.

Then at the time L2TP or the precursor discussions were done within the 
PPPEXT WG because the discussion was with Karl.

>network), and at the LAC (NAS).

Thank you for reminding me.  LNS and LAC were the terms I was looking for.

WRT authentication, there is no reason not to do it in both places.  Let 
the protocol carry the information.

>In addition, we could not require the user to
>enter a username and password twice. You simply had to be able to drop in 
>L2TP, and everything look the same as it did before to the end user.

I agree that is the more desirable scenario.

>Yup, that would have been nicer.

Yes, it would.

>That's OK, we'll forgive you ;-)

Thank you.  It may seem silly but that has really bugged me for a number of 
years.  I hate the thought of having done flawed work.

>Barring redesign of PPP, getting around the wrong things being located in 
>the LCP negotiation would have been made a little easier if we had been 
>allowed to go through LCP negotiation twice. So, you could have LCP 
>negotiated at the LAC,

But you wouldn't have needed to do LCP negotiation twice.  The LAC 
negotiates LCP because that is the terminus of the link.  The LAC 
communicates the options negotiated back to the LNS.  Remember, the LCP 
options negotiate only indicate what the client is willing to accept 
therefore it doesn't really matter what it negotiates.  It is just there to 
prevent its peer from sending something it can't handle.

>designed into the negotiation process later.

Right.  That is the crux of the problem.

>But -- and here is the point about broken PPP stacks -- at the time there 
>were a lot of PPP stacks which would simply roll over and die if you tried 
>to reneogtiate LCP after you had already begun (yes, in great violation to 
>what it says in RFC 1661). This wasn't discovered until L2TP came along 
>because before that, you really didn't see LCP renegotiation occur very much.

<sigh> But we did know.  The argument was that it took too long to 
negotiate PPP as it was so anything we did to speed it up was necessary.  I 
have kicked myself for caving in to that argument for many years now.

>But, it was way too late as there were so many clients in the field with 
>this bug. So, we ended up with Proxy LCP and Proxy Authentication like you 
>see them today.

I know: add more ugliness in order to deal with other ugliness.  I 
preferred the old days where people found problems, fixed them, and the 
fixes then found their ways into new versions, usually with a 
backward-compatibility switch.  I reject the argument, "but we have lots of 
systems in the field; we can't fix them now."  Engineers from Microsoft 
(among others but they come immediately to mind) has been known to use that 
argument.  It is specious because they then turn around and reissue code on 
a regular basis to fix other bugs in their products.

>There's not much else you can do if you want to complete PPP negotiation 
>at the LNS, but *start* it at the LAC so that you can get the "@domain" 
>portion of the username to determine where to tunnel the user. Sigh... 
>Yes, if we had thought about running PPP over IP from the beginning, 
>things might have looked very different in general... A more seperate link 
>layer negotiation would have been one of them. But, PPP isn't nearly as 

This reared its ugly head when we started to do multilink PPP.  The problem 
was *very* clear then.  Pointing out that LCP and NCP were really 
completely separate protocols and represented different layers is what made 
it possible to resolve the deadlock in the WG at that time.

>negotiation, and don't even get me started on ACCM mapping....

You know, sometimes you just tell people, "this is the way it is done so 
make your implementation conform."

>Right. The same argument that led to some of the choices we had to make in 

Yes, but I wanted to get this off my chest after all these years.

>Then we agree more than we disagree :-)

I suspect so.  I find that, when people talk an *engineering* problem 
through to its real conclusion, they are more in accord than not.

Brian Lloyd
[email-masked]
+1.530.676.1113 - voice
+1.360.838.9669 - fax

---

From: Andrew McGregor <[email-masked]>
Date: Sun, 10 Mar 2002 10:21:20 +1300

That top-layer-calls-next-layer etc ad-nauseam model seems to have been one 
of the original ideas for how to implement a stack.

Actual current implementations do all kinds of wierd stuff, but mostly pass 
around accumulating collections of buffers; so the payload buffer doesn't 
get copied to accomodate each new header, instead the kernel has a second 
buffer to contain the header (and later layers can add more).  What gets 
passed around (by way of various queues and internal plumbing schemes) is a 
structure of pointers to pieces of packet, which gets put together on 
transmission, often by the DMA engine in the device or by the device driver.

The layering is just a conceptual model for the logic of what is going on, 
and has no resemblance to the flow of control in a typical actual 
implementation.  There are simple educational implementations that follow 
the layering fairly closely, and they are interesting to read but tend not 
to be practical for high performance applications.

--On Tuesday, 5 March 2002 11:02 p.m. -0800 Christopher Evans 
<[email-masked]> wrote:

>> whoa, it's in the TCP/IP suite, it's not. So let me get this straight.
>> TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is
>> therefore faster than TCP. They are encapsulated in IP, which is put
>> into the data bitstream of a PPP frame. Layer 1 is the physical layer,
>> are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 12 Mar 2002 08:43:46 +0100

Brian Lloyd wrote:
> negotiates LCP because that is the terminus of the link. 

Not just that, the LAC may also need to get authentication information from the
user so that it can know which LNS to forward to. 

> The LAC
> communicates the options negotiated back to the LNS.  

That's what we do now. Please read section 4.4.5 of RFC2661.

> Remember, the LCP

But, if the LNS, say, want's to do some different authentication... Say, PAP
with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP
LCP, which should be OK except that it used to break a lot of PPP clients.

> have kicked myself for caving in to that argument for many years now.

Then let me give you a collective kick from all of the l2tp developers out there
;-)

I thought it was just a bug. I remember telling Robert Webster about this little
problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back
and made an on-the-fly bugfix for it and afterwards it worked great. Note that
Robert worked at Shiva then, and maintained code for the PPP stack that for a
while was the original code base for much of the dialup client industry (e.g.
Windows, OS/2, and probably some others...).

> make your implementation conform."

Until the customer calls you and says "Your access equipment doesn't work with
my customer's MAC clients. Fix it or we aren't buying any more equipment from
you." 

In this particular case, the MAC was actually being too strict to the spec with
regard to ACCM... We were able to get by with every other more lenient PPP
implementation on the planet (except maybe some versions of OS/2), but not the
MAC. So, we made some clarifications in the protocol that are actually decent
refinements from a hardline perspective. It didn't bother me so much from a
purist standpoint given that we were doing something that was actually more
correct, though not entirely necessary as evidenced by the majority of PPP
clients in operation at the time.

> Yes, but I wanted to get this off my chest after all these years.

I hope you feel better. We don't want any tense pilots in the skies grumbling
over their past protocol design mistakes. ;-)

If you really want to excercise your noodle, think about what can happen if IPCP
retries start dropping options from a config request after 2 or 3 retries (but
we can take that offline if you really care).

> through to its real conclusion, they are more in accord than not.

Oui, d'accord.

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 12 Mar 2002 08:43:46 +0100

Oui, d'accord.

- Mark