Re: GRE and L2TP
Rohit Gupta wrote: Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. GRE is an encapsulation. If you can manually provision or have some other "out of band" mechanism that does everything L2TP and PPP would otherwise do for you, then by all means use GRE - or IP in IP for that matter as your scenario with fixed IP addresses for all mobile clients (which I would think is a showstopper from the start) does not obviate the need for a GRE shim either. L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically establishing and maintaining the emulation of these PPP sessions. This is very different than GRE (though there are some ways to deploy L2TP between two routers to make it look like it is doing what GRE typically does in a bit more of a dynamic manner, though this is really a subset of L2TP's overall functionality). Since you indicate that this is for a mobile environment, you might want to look at using Mobile IP. My whole point is that i want to know as to what is the burning need to have L2TP! This question probably has more to do with whether you need PPP. If you do, L2TP could work for you to transport that PPP session (or many PPP sessions) over an IP network. If not, I see no reason for you to be burning with need for L2TP! - Mark Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: L2TP Deployment Scenario?
Rohit Gupta wrote: Hi, L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically Since L2TP is so strongly tied with PPP, can i assume that it will be *mostly* used when a user dials (ISDN/modem) into the ISP network (LAC) to contact the corporate network. It tends to be used rather often for PPPoA and PPPoE in DSL environments these days as well. Can I then connect a small branch office to the corporate network using L2TP? Does it make any sense doing that. Sure, in some cases. > I am now talking of a deployment scenario. Do you ever have two branches connected via L2TP? A number of small routers on the market today have the ability to initiate an L2TP session from the router to an LNS. > I searched the internet and found only scenarios wherein a remote access user dials into the ISP to access the corporate network using L2TP. Is the former possible? Look for "L2TP voluntary tunneling" or "client-initiated L2TP" Also, if you are going to be running L2TP over the Internet and you are worried about folks hacking the connection, you would want to secure the L2TP tunnel with IPsec transport mode as defined in RFC3193. In theory, one could have a small office with some < 10 users connected to switch which in turn dials into the ISPs network. Is this possible? If you are using L2TP over IP to connect to an ISP to get IP access you likely have a bit of a chicken and egg problem. But, yes, if you already have IP connectivity from one ISP, but want to use L2TP to connect to another ISP (perhaps with some other value add on their network) it is *possible* if the ISP allows L2TP connections from your router. Typically, an ISP would accept L2TP connections only from a wholesale access provider (or in some cases from their own PC client). In any case, you'd probably have to find a very knowledgable person at your ISP to talk to this about as it likely isn't standard practice. - Mark With regards, Rohit P.S. And thanks to everybody for responding both on the list and offline! __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: GRE and L2TP
Stewart Bryant wrote: W. Mark Townsley wrote: Rohit Gupta wrote: Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. GRE is an encapsulation. If you can manually provision or have some other "out of band" mechanism that does everything L2TP and PPP would otherwise do for you, then by all means use GRE - or IP in IP for that matter as your scenario with fixed IP addresses for all mobile clients (which I would think is a showstopper from the start) does not obviate the need for a GRE shim either. L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically establishing and maintaining the emulation of these PPP sessions. This is very different than GRE (though there are some ways to deploy L2TP between two routers to make it look like it is doing what GRE typically does in a bit more of a dynamic manner, though this is really a subset of L2TP's overall functionality). Since you indicate that this is for a mobile environment, you might want to look at using Mobile IP. My whole point is that i want to know as to what is the burning need to have L2TP! This question probably has more to do with whether you need PPP. If you do, L2TP could work for you to transport that PPP session (or many PPP sessions) over an IP network. If not, I see no reason for you to be burning with need for L2TP! - Mark Mark I think that the correct comparison in Rohit's case is not between L2TP and GRE, but between L2TPv3 and GRE. As we both know L2TPv3 is better suited to VPN apps than GRE because of its highly functional control plane, and mild security enhancements. I was under the impression during this thread that Rohit was referring to L2TP as defined in RFC2661, not L2TPv3 (currently draft-ietf-l2tpext-l2tp-base-11.txt) which is certainly not so closely tied to PPP. Thanks, - Mark - Stewart Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: IETF #53 Schedule Stability
Pekka Savola wrote: > > On Sun, 24 Feb 2002, Eric Burger wrote: > [snip] > > While it's true that one should try to "see everything", it's hard to > > imagine, for example, how a junior engineer working on an implementation of > > wireless ad-hoc networks has much of an interest in ENUM. > [snip] > > What most people seem to be missing is the real work is done outside of > the WG meetings. You can quite well participate in the IETF process > without ever (or once or twice a year) being present. Personally, in some > wg's I've been to, a lot of MIC time is used by people who 1) like their > own voice, and/or 2) haven't read the drafts. > > If you want a focused view, participation isn't necessary. (An IMO stupid > remnant here is that you have to present the works if they're to be > adopted as WG items.) You don't have to present works for them to be adopted as WG items. Presenting a work does, sometimes, help the WG chair(s) determine interest level and consensus of the WG, particularly if the issue is contentious and the right people are present at the meeting (e.g. people who have read the draft and care). So, while it can help the author's cause to present, it is not (nor ever has been that I know of) a requirement. > If you want a general view (perhaps in addition to > the focused one), coming to the meetings might help. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: IETF #53 Schedule Stability
Pekka Savola wrote: > > On Mon, 25 Feb 2002, W. Mark Townsley wrote: > > > What most people seem to be missing is the real work is done outside of > > > the WG meetings. You can quite well participate in the IETF process > > > without ever (or once or twice a year) being present. Personally, in some > > > wg's I've been to, a lot of MIC time is used by people who 1) like their > > > own voice, and/or 2) haven't read the drafts. > > > > You don't have to present works for them to be adopted as WG items. > > > > Presenting a work does, sometimes, help the WG chair(s) determine interest level > > and consensus of the WG, particularly if the issue is contentious and the right > > people are present at the meeting (e.g. people who have read the draft and > > care). So, while it can help the author's cause to present, it is not (nor ever > > has been that I know of) a requirement. > > Well, I haven't been around all that many years, but I don't recall a > single case in a few WG's I'm participating that an unpresented work would > have been adopted.. sure, it's not written down anywhere, but sometimes > custom is stronger than law... It could certainly be the convention of the WG Chairs in those (or even most) groups. But, it is still not an IETF mandate. Cheers, - Mark > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: PPP
Brian Lloyd wrote: > > At 03:12 AM 3/4/2002, you wrote: > >I couldn't say it shorter and more clearly than Vint : PPP does NOT belong > >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. 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 > > >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!" > > >--- 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) > > 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 > pr
Re: PPP
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.) > > 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 > diffe
Re: PPP
Brian Lloyd wrote: > > At 11:59 PM 3/6/2002, you wrote: > > > 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. > > Then at the time L2TP or the precursor discussions were done within the > PPPEXT WG because the discussion was with Karl. > > > > 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). > > 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. > > > > 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. > > Yes, it would. > > > > "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 ;-) > > 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. 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 > 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. 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. > > >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. > > 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. > > 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. 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...). > > >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
Is there a per-wg chair email list maintained?
i.e., [EMAIL PROTECTED], [EMAIL PROTECTED], etc. in order to reach the current WG chairs for just that WG. Thanks, - Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: (oops) Is there a per-wg chair email list maintained?
Sorry for spamming the world with this, I meant to just ask [EMAIL PROTECTED] - Mark W. Mark Townsley wrote: i.e., [EMAIL PROTECTED], [EMAIL PROTECTED], etc. in order to reach the current WG chairs for just that WG. Thanks, - Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
