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@lloyd.com > +1.530.676.1113 - voice > +1.360.838.9669 - fax