Brian Lloyd wrote:
At 02:42 AM 3/6/2002, you wrote:
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).
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
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.
Do it right would not have changed that.
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.)
<sigh> It has been many years since I argued this with Karl Fox back when
he chaired the L2TP WG.
Karl chaired only the pppext 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.
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
MLPPP and NCP negotiation(s) because then and only then do you know what
the end system is authorized to do.
Yup, that would have been nicer.
"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.
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....
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.
Right. The same argument that led to some of the choices we had to make in L2TP.
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.
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.
Then we agree more than we disagree :-)
YMMV
Brian Lloyd
brian(_at_)lloyd(_dot_)com
+1.530.676.1113 - voice
+1.360.838.9669 - fax