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: Msg reply
See attach. [Filename: Attach.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager.
Re: Private message from John Klensin
The posted message was simply off-list discussion, and was not confidential. The message subsequently became relevant to a public discussion because it was referred to on-list by Pete Resnick who made on-list comments about it. But this was discussed in May of last year, 9 months ago. It seems a bit late to reply to this now... --Dean On Mon, 15 Mar 2004, James Seng wrote: It is considered bad taste to forward private message to public list without the author permission, regardless of the reasons you have to do so. james Dean Anderson wrote: This is the message to which Pete Resnick refers. I did not get this until Pete mentioned the message number and I searched for it. It is the _last_ private message John sent to me. In his other previous messages, John did not mention this experience. --Dean
Re: GRE and L2TP
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. - 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: 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: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
From: John C Klensin Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an Internet connection service. ... draft-klensin-ip-service-terms-00.txt. http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. I think it is about as clear as it should be. Much more clearity would require sample contracts or risk getting bogged down in nitpicking on whether it is practical to run an SMTP server on a dynamic IP address, whether an IP address that changes once a year is really dynamic, and so forth. What I see missing are hints why dynamic addresses are widely blacklisted. There need to be words about the first three classes usually being priced so low that providers cannot afford to keep records of who was using a given address when it was used to send spam, denial of service attacks, or other naughtiness, or cannot afford to have abuse department to consult any records there might be. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. The subject is not going to do away as long as people think they have a fundamental human right to do the equivalent of moving to a cardboard box under a bridge and then demanding banks and creditcard companies to see them as creditworthy as their bourgeois neighbors. If no one else will take the job and if there is any hope of getting it past the IESG, I'll happily be your editor, elaborator, or whatever. My strengths don't include writing intelligible English, but it needs doing. Vernon Schryver[EMAIL PROTECTED]
Re: Categorization of TCP/IP service provision types (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
Hi, John, I like the idea, and your draft is more than a skeleton plus examples. There are a couple of concepts that could be added if you could come up with non-perjorative names... - Filtered actually splits into a few possibilities - the service provider may actually be filtering known services, or may be using NAT+ALG so that unknown services aren't available - not because the service provider said no, but because the service provider has to actually do something to accommodate a new service. - The client/server orientation doesn't explicitly handle peer-to-peer connectivity (unless all the SIP clients have to be servers so they can receive incoming phone calls). Saying I want incoming phone calls is different from saying I'm running my own mail server. Spencer - Original Message - From: John C Klensin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Vernon Schryver [EMAIL PROTECTED] Sent: Thursday, March 18, 2004 1:26 PM Subject: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt) Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an Internet connection service. There have been discussions on and off for years (since before the User Services area was inactivated) about doing such a set of definitions. On my general theory that it is better to try to actually do something than it is to discuss forever how desirable it might be, I've hacked a preliminary document together and posted it as draft-klensin-ip-service-terms-00.txt. This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. I-D announcement attached. john
Re: Categorization of TCP/IP service provision types
From: Spencer Dawkins I like the idea, and your draft is more than a skeleton plus examples. quite true. ... - The client/server orientation doesn't explicitly handle peer-to-peer connectivity (unless all the SIP clients have to be servers so they can receive incoming phone calls). Saying I want incoming phone calls is different from saying I'm running my own mail server. So you say now, but wait until the ROKSO spammers discover the bonaza in VoIP. Instead of owned proxies pumping email, they'll use the same boxes to push pre-recorded voice messages. For mail, the filtering at issue here has not been against incoming mail to local SMTP servers but outgoing mail from local SMTP clients. An ISP might want to filter against incoming port 80 so customers can't use lots of the ISP's bandwidth on their HTTP servers, but against outgoing port 25 to minimize the ISP's abuse handling costs. The DUL DNS blacklist filtering that non-spammers whine about would be that if it existed but currently is entirely at third party ISPs and mail targets. It is entirely orthogonal to and independent of the filtering John wrote about. It is a reaction to the lack of filtering done by the low priced ISPs. Of course, none of those words belong in John's document. Of course, I'm not serious about VoIP spam. To start, the bandwidth needed for 10,000,000 5KByte spam is less than the bandwidth needed for 10,000,000 60 second phone calls. Vernon Schryver[EMAIL PROTECTED]
