From owner-l2tp@diameter.org Wed Nov 1 09:24:14 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09079 for ; Wed, 1 Nov 2000 09:24:13 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA1DBsw05593 for l2tp-list; Wed, 1 Nov 2000 05:11:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA1DBjB05587 for ; Wed, 1 Nov 2000 05:11:46 -0800 Received: from iaehv.iae.nl (iaehv.IAE.nl [194.151.64.2]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA13268 for ; Wed, 1 Nov 2000 04:17:21 -0800 (PST) Received: from exchange1.industree.nl (simac1.iae.nl [194.151.73.56]) by iaehv.iae.nl (Postfix) with ESMTP id A16A27CF0 for ; Wed, 1 Nov 2000 13:17:18 +0100 (CET) Received: by EXCHANGE1 with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Nov 2000 13:14:16 +0100 Message-ID: <0361C92ECB4FD311976A0000F87C295087CAE9@EXCHANGE1> From: Adriaan van den Brand To: "'l2tp@ipsec.org'" Subject: L2TP over NAPT question Date: Wed, 1 Nov 2000 13:14:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C043FD.40715A32" Sender: owner-l2tp@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C043FD.40715A32 Content-Type: text/plain; charset="iso-8859-1" Hi, Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) connection? We see some problems in the setup phase of the tunnels. For NAPT, we use a Linux 2.2 kernel (with IP masquerading). Best regards, Adriaan van den Brand ------_=_NextPart_001_01C043FD.40715A32 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) connection? We see some problems in the setup phase of the tunnels. For NAPT, we use a Linux 2.2 kernel (with IP masquerading).
 
Best regards,
Adriaan van den Brand
 
------_=_NextPart_001_01C043FD.40715A32-- From owner-l2tp@diameter.org Thu Nov 2 00:52:08 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03165 for ; Thu, 2 Nov 2000 00:52:08 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA24D4O06881 for l2tp-list; Wed, 1 Nov 2000 20:13:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA24C1B06875 for ; Wed, 1 Nov 2000 20:12:02 -0800 Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id TAA14242 for ; Wed, 1 Nov 2000 19:17:45 -0800 (PST) Received: from cosinecom.com (IDENT:proxyuser@011.cosine.nttpc.gr.jp [202.229.42.11] (may be forged)) by center.mshindo.net (8.9.3/3.7W/00041811) with SMTP id MAA51038; Thu, 2 Nov 2000 12:29:57 +0900 (JST) Date: Thu, 02 Nov 2000 12:18:03 +0900 (JST) Message-Id: <20001102.121803.78701362.mshindo@mshindo.net> To: Adriaan.van.den.Brand@industree.nl Cc: l2tp@ipsec.org Subject: Re: L2TP over NAPT question From: Motonori Shindo In-Reply-To: <0361C92ECB4FD311976A0000F87C295087CAE9@EXCHANGE1> References: <0361C92ECB4FD311976A0000F87C295087CAE9@EXCHANGE1> X-Mailer: Mew version 1.95b30 on XEmacs 21.1 (Canyonlands) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Adriaan, L2TP encapsulates everything (ie. control & data msg) using UDP, so it's much more NAT-friendly than other tunneling protocols based on GRE ,IP-in-IP, IPsec, etc. However, there might be some cases where NAT doesn't work with L2TP. L2TP (over IP/UDP) works in the following way in terms of a port number usage (assuming a LAC initiates a tunnel creation): LAC LNS .xxx SCCRQ .1701 --------------------------> .xxx SCCRP .yyy <-------------------------- .xxx SCCCN .yyy ---------------------------> Here, .xxx and .yyy represent UDP port numbers. L2TP protocol allows .xxx and .yyy to be arbitarily chosen. Once .xxx and .yyy are determined, this pair will never change during the tunnel lifetime. A port number usage like this is very similar to what is used in tftp. Most implementations use 1701 for .xxx (but some don't) and almost all implementations also use 1701 for .yyy. However, there's a (very small) possibility that .yyy happens to be something different from 1701. In this case, if there is a NAT between the LAC and LNS, such a NAT will be confused and very likely to be unable to do NAT properly, unless it does some special treatment for L2TP packets (some clever NAT box does this for tftp, BTW). Cosidering the fact that .yyy being something other than 1701 is quite rare, L2TP *should* work with NAT, I would say. BTW, what are you using as a LAC and LNS? Regards, From: Adriaan van den Brand Subject: L2TP over NAPT question Date: Wed, 1 Nov 2000 13:14:15 +0100 > Hi, > > Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) > connection? We see some problems in the setup phase of the tunnels. For > NAPT, we use a Linux 2.2 kernel (with IP masquerading). > > Best regards, > Adriaan van den Brand =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= From owner-l2tp@diameter.org Thu Nov 2 07:38:29 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02318 for ; Thu, 2 Nov 2000 07:38:28 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA2AQdJ07111 for l2tp-list; Thu, 2 Nov 2000 02:26:39 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA2AQNB07105 for ; Thu, 2 Nov 2000 02:26:23 -0800 Received: from iaehv.iae.nl (iaehv.IAE.nl [194.151.64.2]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id BAA14564 for ; Thu, 2 Nov 2000 01:32:07 -0800 (PST) Received: from exchange1.industree.nl (simac1.iae.nl [194.151.73.56]) by iaehv.iae.nl (Postfix) with ESMTP id 46ECA7D64; Thu, 2 Nov 2000 10:31:45 +0100 (CET) Received: by EXCHANGE1 with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Nov 2000 10:28:41 +0100 Message-ID: <0361C92ECB4FD311976A0000F87C295087CAED@EXCHANGE1> From: Adriaan van den Brand To: "'Motonori Shindo'" , Adriaan van den Brand Cc: l2tp@ipsec.org Subject: RE: L2TP over NAPT question Date: Thu, 2 Nov 2000 10:28:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C044AF.494FB560" Sender: owner-l2tp@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C044AF.494FB560 Content-Type: text/plain; charset="iso-8859-1" Adriaan, L2TP encapsulates everything (ie. control & data msg) using UDP, so it's much more NAT-friendly than other tunneling protocols based on GRE ,IP-in-IP, IPsec, etc. However, there might be some cases where NAT doesn't work with L2TP. L2TP (over IP/UDP) works in the following way in terms of a port number usage (assuming a LAC initiates a tunnel creation): LAC LNS .xxx SCCRQ .1701 --------------------------> .xxx SCCRP .yyy <-------------------------- .xxx SCCCN .yyy ---------------------------> Here, .xxx and .yyy represent UDP port numbers. L2TP protocol allows .xxx and .yyy to be arbitarily chosen. Once .xxx and .yyy are determined, this pair will never change during the tunnel lifetime. A port number usage like this is very similar to what is used in tftp. Most implementations use 1701 for .xxx (but some don't) and almost all implementations also use 1701 for .yyy. However, there's a (very small) possibility that .yyy happens to be something different from 1701. In this case, if there is a NAT between the LAC and LNS, such a NAT will be confused and very likely to be unable to do NAT properly, unless it does some special treatment for L2TP packets (some clever NAT box does this for tftp, BTW). Cosidering the fact that .yyy being something other than 1701 is quite rare, L2TP *should* work with NAT, I would say. BTW, what are you using as a LAC and LNS? LAC & LNS: Redback SMS500 Enternet500 for client The NAT/PAT is located inside a cable modem. It doesn't have application support other than HTTP, so I guess that's the problem. It is mainly designed for provisioning purposes. Regards, Adriaan From: Adriaan van den Brand Subject: L2TP over NAPT question Date: Wed, 1 Nov 2000 13:14:15 +0100 > Hi, > > Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) > connection? We see some problems in the setup phase of the tunnels. For > NAPT, we use a Linux 2.2 kernel (with IP masquerading). > > Best regards, > Adriaan van den Brand =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= ------_=_NextPart_001_01C044AF.494FB560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: L2TP over NAPT question

Adriaan,

L2TP encapsulates everything (ie. control & data = msg) using UDP, so
it's much more NAT-friendly than other tunneling = protocols based on
GRE ,IP-in-IP, IPsec, etc. However, there might be = some cases where
NAT doesn't work with L2TP.

L2TP (over IP/UDP) works in the following way in = terms of a port
number usage (assuming a LAC initiates a tunnel = creation):


   = LAC           &nb= sp;            = LNS
     = .xxx       = SCCRQ        .1701
     = -------------------------->

     = .xxx       = SCCRP         .yyy
     = <--------------------------

     = .xxx       = SCCCN         .yyy
     = --------------------------->


Here, .xxx and .yyy represent UDP port numbers. L2TP = protocol allows
.xxx and .yyy to be arbitarily chosen. Once .xxx and = .yyy are
determined, this pair will never change during the = tunnel lifetime. A
port number usage like this is very similar to what = is used in tftp.

Most implementations use 1701 for .xxx (but some = don't) and almost all
implementations also use 1701 for .yyy. However, = there's a (very
small) possibility that .yyy happens to be something = different from
1701. In this case, if there is a NAT between the = LAC and LNS, such a
NAT will be confused and very likely to be unable to = do NAT properly,
unless it does some special treatment for L2TP = packets (some clever
NAT box does this for tftp, BTW).

Cosidering the fact that .yyy being something other = than 1701 is quite
rare, L2TP *should* work with NAT, I would say. =

BTW, what are you using as a LAC and LNS?




LAC & LNS:
        Redback = SMS500
        Enternet500 for client

The NAT/PAT is located inside a cable modem. It = doesn't have application support other than HTTP, so I guess that's the = problem.

It is mainly designed for provisioning = purposes.

Regards,
Adriaan



From: Adriaan van den Brand = <Adriaan.van.den.Brand@industree.nl>
Subject: L2TP over NAPT question
Date: Wed, 1 Nov 2000 13:14:15 +0100

> Hi,
> 
> Has anyone got experience in running L2TP = tunnels over a NAPT (NAT/PAT)
> connection? We see some problems in the setup = phase of the tunnels. For
> NAPT, we use a Linux 2.2 kernel (with IP = masquerading).
> 
> Best regards,
> Adriaan van den Brand

=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D= --=3D--=3D--=3D--=3D
 +----+----+    
 |.. .|    = |     Motonori Shindo
 |_~__|    = |    
 | .. |~~_~|     Sr. = Systems Engineer
 | .  |    = |     CoSine Communications Inc.
 +----+----+    
 C o S i n e     = e-mail:  mshindo@cosinecom.com
Communications
=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D--=3D= --=3D--=3D--=3D--=3D

------_=_NextPart_001_01C044AF.494FB560-- From owner-l2tp@diameter.org Mon Nov 6 23:46:42 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15118 for ; Mon, 6 Nov 2000 23:46:41 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA73Bt617399 for l2tp-list; Mon, 6 Nov 2000 19:11:55 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA73BoB17393 for ; Mon, 6 Nov 2000 19:11:50 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id SAA27101 for ; Mon, 6 Nov 2000 18:17:49 -0800 (PST) From: zong.zaifeng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256990.000CAE48 ; Tue, 7 Nov 2000 10:18:30 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256990.000CACA6.00@mail.zhongxing.com> Date: Tue, 7 Nov 2000 10:18:16 +0800 Subject: Who can give me an example of outcoming call Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Dear All: I want to know the usage of the outcoming call, it seems so abstract for me. So I want some examples to help me understand it, who can give me an example? Thank you in advance ZZF From owner-l2tp@diameter.org Tue Nov 7 04:26:49 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23170 for ; Tue, 7 Nov 2000 04:26:48 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA773Yl17539 for l2tp-list; Mon, 6 Nov 2000 23:03:34 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA772FB17533 for ; Mon, 6 Nov 2000 23:02:15 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id WAA27389 for ; Mon, 6 Nov 2000 22:07:24 -0800 (PST) From: zong.zaifeng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256990.00218E2A ; Tue, 7 Nov 2000 14:06:30 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256990.00218CA6.00@mail.zhongxing.com> Date: Tue, 7 Nov 2000 14:06:17 +0800 Subject: Question about session establishment Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Hello, I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a LAC Incoming Call States table, I want to ask is that when will the state go to established state? After sending ICCN or after sending ICCN and recieving acknowledgement correspond to this ICCN(e.g.a ZLB)? TIA ZZF From owner-l2tp@diameter.org Tue Nov 7 08:43:10 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10656 for ; Tue, 7 Nov 2000 08:43:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA7BqMl17747 for l2tp-list; Tue, 7 Nov 2000 03:52:22 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA7BpXB17741 for ; Tue, 7 Nov 2000 03:51:33 -0800 Received: from omail01.samsung.co.kr (omail01.samsung.co.kr [203.254.197.73]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id CAA27610 for ; Tue, 7 Nov 2000 02:57:28 -0800 (PST) From: sudheer@samsung.co.kr Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id TAA06728; Tue, 7 Nov 2000 19:58:11 +0900 (KST) X-OpenMail-Hops: 2 Date: Tue, 7 Nov 2000 19:57:24 +0900 Message-Id: In-Reply-To: <48256990.00218CA6.00@mail.zhongxing.com> Subject: (Reply) Question about session establishment MIME-Version: 1.0 TO: l2tp@ipsec.org, zong.zaifeng@mail.zte.com.cn Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 7 Nov 2000 14:06:17 +0800" ;Modification-Date="Tue, 7 Nov 2000 19:57:18 +0900" Content-Transfer-Encoding: 8bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, The Session state moves to the Established state after receiving the ZLB corresponding to the ICCN sent. Sudheer. Hello, I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a LAC Incoming Call States table, I want to ask is that when will the state go to established state? After sending ICCN or after sending ICCN and recieving acknowledgement correspond to this ICCN(e.g.a ZLB)? TIA ZZF From owner-l2tp@diameter.org Tue Nov 7 11:16:30 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17977 for ; Tue, 7 Nov 2000 11:16:30 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA7Dia417993 for l2tp-list; Tue, 7 Nov 2000 05:44:36 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA7DiVB17987 for ; Tue, 7 Nov 2000 05:44:31 -0800 Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA28958 for ; Tue, 7 Nov 2000 04:50:32 -0800 (PST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 7 Nov 2000 12:49:17 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-29) id MAA21608; Tue, 7 Nov 2000 12:49:15 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C1256990.004592C3 ; Tue, 7 Nov 2000 13:39:55 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Fabio Poggi" To: l2tp@ipsec.org Message-ID: Date: Tue, 7 Nov 2000 13:40:24 +0100 Subject: L2TP/UDP/IP model question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk L2TP protocol, in RFC 2661, indicates that UDP/IP stack as one of the transport media for a tunnel. So we can have L2TP/UDP/IP/PHY. L2TP is a particular case of Tunnel over IP. RFC 2667 ("Tunnel over IP MIB") section 4.1.1 states: "Each logical interface (physical or virtual) has an ifEntry in the Interfaces MIB. Tunnels are handled by creating a logical interface (ifEntry) for each tunnel. These are then correlated, using the ifStack table of the Interfaces MIB, to those interfaces on which the local IPv4 addresses of the tunnels are configured." But ifStack model states that only physical interfaces under routing protocol have to be present in these tables. So how can I interpret the above RFC 2667 statement ? Does we have to model l2tpifindex and ifindex of the physical interface under UDP with a single entry into the ifstack table ? Thanks. Regards From owner-l2tp@diameter.org Wed Nov 8 09:28:25 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15530 for ; Wed, 8 Nov 2000 09:28:24 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA8CvFI18995 for l2tp-list; Wed, 8 Nov 2000 04:57:15 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA8Cu9B18989 for ; Wed, 8 Nov 2000 04:56:09 -0800 Received: from spmler2.mail.eds.com (spmler2.mail.eds.com [194.128.225.188]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA01711 for ; Wed, 8 Nov 2000 04:02:06 -0800 (PST) Received: from nnse.eds.com (nnse-2.eds.com [192.168.1.1]) by spmler2.mail.eds.com (8.11.1/8.11.1) with ESMTP id eA8C1g604867; Wed, 8 Nov 2000 12:01:43 GMT Received: from nnse.eds.com (localhost [127.0.0.1]) by nnse.eds.com (8.11.1/8.11.1) with ESMTP id eA8C1h525455; Wed, 8 Nov 2000 12:01:43 GMT Received: from gbspm002.exemhub.exch.eds.com ([207.37.51.200]) by nnse.eds.com (8.11.1/8.11.1) with ESMTP id eA8C1hw25449; Wed, 8 Nov 2000 12:01:43 GMT Received: by GBSPM002 with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 12:01:39 -0000 Message-ID: From: "Leone, Guido" To: "'Adriaan van den Brand'" Cc: l2tp@ipsec.org Subject: R: L2TP over NAPT question Date: Wed, 8 Nov 2000 12:01:35 -0000 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by charizard.diameter.org id eA8Cu9B18990 Sender: owner-l2tp@diameter.org Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id eA8CvFI18995 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15530 GRE is a "protocol" (number 47) in itself (not using TCP or UDP to encapsulate) : why are you saying that it cannot be as "NAT-friendly" as L2TP ? Regards, Guido. > -----Messaggio originale----- > Da: Adriaan van den Brand [SMTP:Adriaan.van.den.Brand@industree.nl] > Inviato: giovedì 2 novembre 2000 10.29 > A: 'Motonori Shindo'; Adriaan van den Brand > Cc: l2tp@ipsec.org > Oggetto: RE: L2TP over NAPT question > > Adriaan, > > L2TP encapsulates everything (ie. control & data msg) using UDP, so > it's much more NAT-friendly than other tunneling protocols based on > GRE ,IP-in-IP, IPsec, etc. However, there might be some cases where > NAT doesn't work with L2TP. > > L2TP (over IP/UDP) works in the following way in terms of a port > number usage (assuming a LAC initiates a tunnel creation): > > > LAC LNS > .xxx SCCRQ .1701 > --------------------------> > > .xxx SCCRP .yyy > <-------------------------- > > .xxx SCCCN .yyy > ---------------------------> > > > Here, .xxx and .yyy represent UDP port numbers. L2TP protocol allows > .xxx and .yyy to be arbitarily chosen. Once .xxx and .yyy are > determined, this pair will never change during the tunnel lifetime. A > port number usage like this is very similar to what is used in tftp. > > Most implementations use 1701 for .xxx (but some don't) and almost all > implementations also use 1701 for .yyy. However, there's a (very > small) possibility that .yyy happens to be something different from > 1701. In this case, if there is a NAT between the LAC and LNS, such a > NAT will be confused and very likely to be unable to do NAT properly, > unless it does some special treatment for L2TP packets (some clever > NAT box does this for tftp, BTW). > > Cosidering the fact that .yyy being something other than 1701 is quite > rare, L2TP *should* work with NAT, I would say. > > BTW, what are you using as a LAC and LNS? > > > > > LAC & LNS: > Redback SMS500 > Enternet500 for client > > The NAT/PAT is located inside a cable modem. It doesn't have application > support other than HTTP, so I guess that's the problem. > > It is mainly designed for provisioning purposes. > > Regards, > Adriaan > > > > From: Adriaan van den Brand > Subject: L2TP over NAPT question > Date: Wed, 1 Nov 2000 13:14:15 +0100 > > > Hi, > > > > Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) > > connection? We see some problems in the setup phase of the tunnels. For > > NAPT, we use a Linux 2.2 kernel (with IP masquerading). > > > > Best regards, > > Adriaan van den Brand > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > +----+----+ > |.. .| | Motonori Shindo > |_~__| | > | .. |~~_~| Sr. Systems Engineer > | . | | CoSine Communications Inc. > +----+----+ > C o S i n e e-mail: mshindo@cosinecom.com > Communications > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > From owner-l2tp@diameter.org Wed Nov 8 22:01:30 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24794 for ; Wed, 8 Nov 2000 22:01:29 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA917qA19457 for l2tp-list; Wed, 8 Nov 2000 17:07:52 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA916pB19451 for ; Wed, 8 Nov 2000 17:06:52 -0800 Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id QAA02320 for ; Wed, 8 Nov 2000 16:12:56 -0800 (PST) Received: from acc.com (calcium.dev.acc.am.ericsson.se [129.192.57.200]) by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id QAA11899 for ; Wed, 8 Nov 2000 16:11:28 -0700 (PPET) Message-ID: <3A09ED50.F22CAC84@acc.com> Date: Wed, 08 Nov 2000 16:18:24 -0800 From: Evan Caves X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@ipsec.org Subject: Re: (Reply) Question about session establishment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit No. The session FSM steps immediately to "established" after sending the ICCN. evan - sudheer@samsung.co.kr wrote: > > Hi, > > The Session state moves to the Established state after receiving the ZLB corresponding to the ICCN sent. > > Sudheer. > > Hello, > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > LAC Incoming Call States table, I want to ask is that when will the state go to > established state? After sending ICCN or after sending ICCN and recieving > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > TIA > > ZZF From owner-l2tp@diameter.org Thu Nov 9 02:22:19 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02912 for ; Thu, 9 Nov 2000 02:22:19 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA96dv419692 for l2tp-list; Wed, 8 Nov 2000 22:39:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA96dsB19686 for ; Wed, 8 Nov 2000 22:39:54 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id VAA02590 for ; Wed, 8 Nov 2000 21:45:59 -0800 (PST) From: pan.peisheng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256992.001FB6EB ; Thu, 9 Nov 2000 13:46:24 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256992.001FB505.00@mail.zhongxing.com> Date: Thu, 9 Nov 2000 13:46:12 +0800 Subject: question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk When we create L2tp tunnel,if we identify our receive window size is 1, Can we receive 4 control messages one time? From owner-l2tp@diameter.org Thu Nov 9 03:27:28 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01421 for ; Thu, 9 Nov 2000 03:27:28 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA97bs419780 for l2tp-list; Wed, 8 Nov 2000 23:37:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA97boB19774 for ; Wed, 8 Nov 2000 23:37:50 -0800 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id WAA02624 for ; Wed, 8 Nov 2000 22:43:57 -0800 (PST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id WAA17549; Wed, 8 Nov 2000 22:41:46 -0800 (PST) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id WAA16441; Wed, 8 Nov 2000 22:41:43 -0800 (PST) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Nov 2000 22:40:58 -0800 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A03414FB@mailserver.shastanets.com> From: Vipin Jain To: "'pan.peisheng@mail.zte.com.cn'" , l2tp@ipsec.org Subject: RE: question Date: Wed, 8 Nov 2000 22:40:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk no, unless other end is mis-behaving! -----Original Message----- From: pan.peisheng@mail.zte.com.cn [mailto:pan.peisheng@mail.zte.com.cn] Sent: Wednesday, November 08, 2000 9:46 PM To: l2tp@ipsec.org Subject: question When we create L2tp tunnel,if we identify our receive window size is 1, Can we receive 4 control messages one time? From owner-l2tp@diameter.org Thu Nov 9 04:14:58 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21385 for ; Thu, 9 Nov 2000 04:14:57 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA98RL719863 for l2tp-list; Thu, 9 Nov 2000 00:27:21 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA98RIB19857 for ; Thu, 9 Nov 2000 00:27:18 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id XAA02661 for ; Wed, 8 Nov 2000 23:33:24 -0800 (PST) From: zong.zaifeng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256992.0029885C ; Thu, 9 Nov 2000 15:33:38 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org, evan@acc.com Message-ID: <48256992.002986F6.00@mail.zhongxing.com> Date: Thu, 9 Nov 2000 15:33:39 +0800 Subject: Re: (Reply) Question about session establishment Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk But if the ICCN was lost and need to be retransmitted, the LAC has entered established state but the LNS still hasn't. During the period of retransmitting ICCN, data packets maybe send to LNS, how will LNS handle this data packets? because the session in LNS still hasn't established, so it maybe ignore these packets. Do you think this case isn't important? No. The session FSM steps immediately to "established" after sending the ICCN. evan - sudheer@samsung.co.kr wrote: > > Hi, > > The Session state moves to the Established state after receiving the ZLB corresponding to the ICCN sent. > > Sudheer. > > Hello, > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > LAC Incoming Call States table, I want to ask is that when will the state go to > established state? After sending ICCN or after sending ICCN and receiving > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > TIA > > ZZF From owner-l2tp@diameter.org Thu Nov 9 06:14:38 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08920 for ; Thu, 9 Nov 2000 06:14:38 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA99VTP20008 for l2tp-list; Thu, 9 Nov 2000 01:31:29 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA99VPB20002 for ; Thu, 9 Nov 2000 01:31:25 -0800 Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id AAA02720 for ; Thu, 9 Nov 2000 00:37:32 -0800 (PST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id AAA20992; Thu, 9 Nov 2000 00:35:07 -0800 (PST) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id AAA23384; Thu, 9 Nov 2000 00:35:03 -0800 (PST) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 00:34:19 -0800 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A03414FE@mailserver.shastanets.com> From: Vipin Jain To: "'zong.zaifeng@mail.zte.com.cn'" , l2tp@ipsec.org, evan@acc.com Subject: RE: (Reply) Question about session establishment Date: Thu, 9 Nov 2000 00:34:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk If LAC waits for Ack from LNS, what would it do with the data packets LNS might have sent before it sent ZLB Ack? Given the fact that ZLB Ack could be delayed, where as ICCN isn't. Assuming most of the times ICCN will get to LNS, it would be more efficient to assume tunnel in established when ICCN is sent and not wait for ZLB Ack. -- vipin -----Original Message----- From: zong.zaifeng@mail.zte.com.cn [mailto:zong.zaifeng@mail.zte.com.cn] Sent: Wednesday, November 08, 2000 11:34 PM To: l2tp@ipsec.org; evan@acc.com Subject: Re: (Reply) Question about session establishment But if the ICCN was lost and need to be retransmitted, the LAC has entered established state but the LNS still hasn't. During the period of retransmitting ICCN, data packets maybe send to LNS, how will LNS handle this data packets? because the session in LNS still hasn't established, so it maybe ignore these packets. Do you think this case isn't important? No. The session FSM steps immediately to "established" after sending the ICCN. evan - sudheer@samsung.co.kr wrote: > > Hi, > > The Session state moves to the Established state after receiving the ZLB corresponding to the ICCN sent. > > Sudheer. > > Hello, > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > LAC Incoming Call States table, I want to ask is that when will the state go to > established state? After sending ICCN or after sending ICCN and receiving > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > TIA > > ZZF From owner-l2tp@diameter.org Thu Nov 9 07:50:20 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10860 for ; Thu, 9 Nov 2000 07:50:19 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA99sj420053 for l2tp-list; Thu, 9 Nov 2000 01:54:45 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA99sfB20047 for ; Thu, 9 Nov 2000 01:54:41 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id BAA02750 for ; Thu, 9 Nov 2000 01:00:48 -0800 (PST) From: pan.peisheng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256992.00318EC4 ; Thu, 9 Nov 2000 17:01:18 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256992.00318DAF.00@mail.zhongxing.com> Date: Thu, 9 Nov 2000 17:01:20 +0800 Subject: question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk question 1:In L2tp,whether Proxy Authen Name means remote user or LAC or LNS? question 2:In L2tp,ppp remote end must first LCP negotiate with LAC,then LAC create L2tp tunnel with LNS,so whether Proxy LCP AVPs are useless? From owner-l2tp@diameter.org Thu Nov 9 10:10:14 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02797 for ; Thu, 9 Nov 2000 10:10:13 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9BouS20228 for l2tp-list; Thu, 9 Nov 2000 03:50:56 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9BoqB20222 for ; Thu, 9 Nov 2000 03:50:52 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id CAA02840 for ; Thu, 9 Nov 2000 02:56:59 -0800 (PST) From: pan.peisheng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256992.003C3239 ; Thu, 9 Nov 2000 18:57:30 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256992.003C308B.00@mail.zhongxing.com> Date: Thu, 9 Nov 2000 18:57:32 +0800 Subject: ´ð¸´: Re: (Reply) Question about session establishment Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=cyHO4fu00TPg4E04PdmL74Evs5ZyQFXAa7yID6gZJtW7ywfDYiEvULpm" Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk --0__=cyHO4fu00TPg4E04PdmL74Evs5ZyQFXAa7yID6gZJtW7ywfDYiEvULpm Content-type: text/plain; charset=gb2312 Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id eA9BouS20228 Content-Transfer-Encoding: quoted-printable I think it is not very comfortable,but you have to bear it until more eff= ective ideas to be made. |--------+----------------------------> | | zong.zaifeng@mail.| | | zte.com.cn | | | | | | 00-11-09 03:33 PM | | | | |--------+----------------------------> >--------------------------------------------------------| | | | =CA=D5=BC=FE=C8=CB=A3=BA l2tp@ipsec.org, evan@acc.com = | | =B3=AD=CB=CD=A3=BA (=C3=DC=CB=CD=A3=BA =C5=CB=C5=E6=C9=FA/=C4=CF= =BE=A9=D1=D0=BE=BF=CB=F9/=BD=BB=BB=BB=B2=FA=C6=B7=CA=C2=D2=B5=B2=BF | | /zte_ltd) | | =D6=F7=CC=E2=A3=BA Re: (Reply) Question about session | | establishment | >--------------------------------------------------------| --0__=cyHO4fu00TPg4E04PdmL74Evs5ZyQFXAa7yID6gZJtW7ywfDYiEvULpm Content-type: text/plain; charset=us-ascii Content-Disposition: inline But if the ICCN was lost and need to be retransmitted, the LAC has entered established state but the LNS still hasn't. During the period of retransmitting ICCN, data packets maybe send to LNS, how will LNS handle this data packets? because the session in LNS still hasn't established, so it maybe ignore these packets. Do you think this case isn't important? No. The session FSM steps immediately to "established" after sending the ICCN. evan - sudheer@samsung.co.kr wrote: > > Hi, > > The Session state moves to the Established state after receiving the ZLB corresponding to the ICCN sent. > > Sudheer. > > Hello, > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > LAC Incoming Call States table, I want to ask is that when will the state go to > established state? After sending ICCN or after sending ICCN and receiving > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > TIA > > ZZF --0__=cyHO4fu00TPg4E04PdmL74Evs5ZyQFXAa7yID6gZJtW7ywfDYiEvULpm-- From owner-l2tp@diameter.org Thu Nov 9 10:35:25 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12443 for ; Thu, 9 Nov 2000 10:35:24 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9DQEn20503 for l2tp-list; Thu, 9 Nov 2000 05:26:14 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9DQ9B20497 for ; Thu, 9 Nov 2000 05:26:09 -0800 Received: from imchub1.cosinecom.com (imchub1.cosinecom.com [63.88.104.18]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA04150 for ; Thu, 9 Nov 2000 04:32:13 -0800 (PST) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 04:31:45 -0800 Received: from cosinecom.com (TYANAGIB2 [192.168.1.118]) by exchsrv1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RQ7KS5F6; Thu, 9 Nov 2000 04:30:13 -0800 Message-ID: <3A0A983A.C3981A95@cosinecom.com> Date: Thu, 09 Nov 2000 21:27:38 +0900 From: Tatsuya Yanagibashi X-Mailer: Mozilla 4.73 [ja] (Win98; U) X-Accept-Language: ja MIME-Version: 1.0 To: pan.peisheng@mail.zte.com.cn CC: l2tp@ipsec.org Subject: Re: question References: <48256992.00318DAF.00@mail.zhongxing.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Pan, ProxyLCP/Auth enables to deliver the information which LAC gather during LCP negotiation with remote user to LNS. How LNS treat this info depends on the LNS's implementation. This means LNS may use this info prevent from renegotiation for LCP and Auth, or may not use. (1)If LNS is willing to use Proxy information from LAC, User LAC LNS <-------> LCP Nego <-------> LCP Auth .......... ---------> ICCN(ProxyLCP/Auth) <------------------ Auth-Success or Auth-Fail (2)If LNS don't want to use those information, User LAC LNS <-------> LCP Nego <-------> LCP Auth .......... ---------> ICCN(ProxyLCP/Auth) <------------------ LCP CONFREQ ........ Q1: ProxyName means username information which LAC get from remote user. Q2: PPP itself is terminated at LNS. Therefore remote user and LNS have to negotiate PPP baiscally. As you know, most of cases user and LAC negotiated LCP before l2tp session establishment. ProxyLCP/Auth helps LNS. I hope this helps you. Thanks, Tatsuya Yanagibashi pan.peisheng@mail.zte.com.cn wrote: > > question 1:In L2tp,whether Proxy Authen Name means remote user or LAC or LNS? > > question 2:In L2tp,ppp remote end must first LCP negotiate with LAC,then LAC > create > L2tp tunnel with LNS,so whether Proxy LCP AVPs are useless? -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ +----+----+ Tatsuya Yanagibashi |.. .| | |_~__| | Network Consultant | .. |~~_~| CoSine Communications Inc. | . | | +----+----+ e-mail: tyanagibashi@cosinecom.com C o S i n e Phone # +81-3-5219-1296 Communications Fax # +81-3-5219-1201 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From owner-l2tp@diameter.org Thu Nov 9 14:12:36 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29336 for ; Thu, 9 Nov 2000 14:12:33 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9IDvZ20840 for l2tp-list; Thu, 9 Nov 2000 10:13:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9IDrB20834 for ; Thu, 9 Nov 2000 10:13:53 -0800 Received: from cdsinet.net (server1.cdsinet.net [38.195.110.10]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id JAA04386 for ; Thu, 9 Nov 2000 09:20:01 -0800 (PST) Received: from dns1.cdsinet.net [38.195.110.12] by cdsinet.net with ESMTP (SMTPD32-6.03) id A5C6FA1043A; Thu, 09 Nov 2000 10:50:14 -0600 Date: Thu, 9 Nov 2000 10:50:09 -0600 (CST) From: John Narron To: l2tp@ipsec.org Subject: L2F / L2TP Questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk Greetings all, We're about to embark on some expansion using some L2F/L2TP wizardry, and well frankly I'm not to sure how to set this crap up. We got the frame-relay circuit between the two access points set up correctly, but there's a slight problem - the LAC uses L2F, and the LNS only does L2TP. I had thought L2TP was backwards compatible w/ L2F? Am I right, or was I smoking some bad stuff? If it is right, how would one go about getting the authentication of the tunnels working as well? Generic instructions would be useful, but if anyone knows how to set up an LNS on a Portmaster 3 (from Livingston/Lucent) it would be a major help. Thanks, John From owner-l2tp@diameter.org Thu Nov 9 16:32:51 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17501 for ; Thu, 9 Nov 2000 16:32:50 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9JF3R20913 for l2tp-list; Thu, 9 Nov 2000 11:15:03 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9JELB20907 for ; Thu, 9 Nov 2000 11:14:21 -0800 Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id KAA04430 for ; Thu, 9 Nov 2000 10:20:29 -0800 (PST) Received: from acc.com (calcium.dev.acc.am.ericsson.se [129.192.57.200]) by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id KAA28891; Thu, 9 Nov 2000 10:19:05 -0700 (PPET) Message-ID: <3A0AEC3A.87F3E1BA@acc.com> Date: Thu, 09 Nov 2000 10:26:02 -0800 From: Evan Caves X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pan.peisheng@mail.zte.com.cn CC: l2tp@ipsec.org Subject: Re: =?iso-8859-1?Q?=B4=F0=B8=B4?=: Re: (Reply) Question about session establishment References: <48256992.003C308B.00@mail.zhongxing.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-l2tp@diameter.org Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id eA9JF3R20913 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17501 ????? pan.peisheng@mail.zte.com.cn wrote: > > I think it is not very comfortable,but you have to bear it until more effective > ideas to be made. > > |--------+----------------------------> > | | zong.zaifeng@mail.| > | | zte.com.cn | > | | | > | | 00-11-09 03:33 PM | > | | | > |--------+----------------------------> > >--------------------------------------------------------| > | | > | ÊÕ¼þÈË£º l2tp@ipsec.org, evan@acc.com | > | ³­ËÍ£º (ÃÜËÍ£º ÅËÅæÉú/ÄϾ©Ñо¿Ëù/½»»»²úÆ·ÊÂÒµ²¿ | > | /zte_ltd) | > | Ö÷Ì⣺ Re: (Reply) Question about session | > | establishment | > >--------------------------------------------------------| > > ------------------------------------------------------------------------ > > But if the ICCN was lost and need to be retransmitted, the LAC has entered > established > state but the LNS still hasn't. During the period of retransmitting ICCN, data > packets > maybe send to LNS, how will LNS handle this data packets? because the session in > LNS still hasn't established, so it maybe ignore these packets. Do you think > this case > isn't important? > > No. The session FSM steps immediately to "established" after sending the > ICCN. > > evan > - > > sudheer@samsung.co.kr wrote: > > > > Hi, > > > > The Session state moves to the Established state after receiving the ZLB > corresponding to the ICCN sent. > > > > Sudheer. > > > > Hello, > > > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > > LAC Incoming Call States table, I want to ask is that when will the state go > to > > established state? After sending ICCN or after sending ICCN and receiving > > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > > > TIA > > > > ZZF From owner-l2tp@diameter.org Thu Nov 9 17:56:33 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07981 for ; Thu, 9 Nov 2000 17:56:33 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9JE6Z20905 for l2tp-list; Thu, 9 Nov 2000 11:14:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9JD4B20899 for ; Thu, 9 Nov 2000 11:13:04 -0800 Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id KAA04423 for ; Thu, 9 Nov 2000 10:19:12 -0800 (PST) Received: from acc.com (calcium.dev.acc.am.ericsson.se [129.192.57.200]) by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id KAA28776; Thu, 9 Nov 2000 10:17:49 -0700 (PPET) Message-ID: <3A0AEBED.2AAED02F@acc.com> Date: Thu, 09 Nov 2000 10:24:45 -0800 From: Evan Caves X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: zong.zaifeng@mail.zte.com.cn CC: l2tp@ipsec.org, evan@acc.am.ericsson.se Subject: Re: (Reply) Question about session establishment References: <48256992.002986F6.00@mail.zhongxing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit If the ICCN was lost then the LNS will still be in 'wait-connect' and will drop data packets. The LAC reliable transport will continue to retransmit the ICCN until acknowledged. The PPP state machine on the dial in client will continue to retransmit either LCP packets or auth packets as necessary until the LNS has stepped to established. So the end result is it works. evan - zong.zaifeng@mail.zte.com.cn wrote: > > But if the ICCN was lost and need to be retransmitted, the LAC has entered > established > state but the LNS still hasn't. During the period of retransmitting ICCN, data > packets > maybe send to LNS, how will LNS handle this data packets? because the session in > LNS still hasn't established, so it maybe ignore these packets. Do you think > this case > isn't important? > > No. The session FSM steps immediately to "established" after sending the > ICCN. > > evan > - > > sudheer@samsung.co.kr wrote: > > > > Hi, > > > > The Session state moves to the Established state after receiving the ZLB > corresponding to the ICCN sent. > > > > Sudheer. > > > > Hello, > > > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there is a > > LAC Incoming Call States table, I want to ask is that when will the state go > to > > established state? After sending ICCN or after sending ICCN and receiving > > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > > > TIA > > > > ZZF From owner-l2tp@diameter.org Thu Nov 9 20:30:21 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12364 for ; Thu, 9 Nov 2000 20:30:21 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA09gx21286 for l2tp-list; Thu, 9 Nov 2000 16:09:42 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA09bB21280 for ; Thu, 9 Nov 2000 16:09:37 -0800 Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id PAA04668 for ; Thu, 9 Nov 2000 15:15:46 -0800 (PST) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA26291; Thu, 9 Nov 2000 15:07:46 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Nov 2000 23:15:45 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA03734; Thu, 9 Nov 2000 15:15:44 -0800 (PST) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [135.140.53.42]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id PAA09553; Thu, 9 Nov 2000 15:15:34 -0800 (PST) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id PAA17460; Thu, 9 Nov 2000 15:11:15 -0800 (PST) Message-Id: <3.0.5.32.20001109151113.01445e10@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Nov 2000 15:11:13 -0800 To: James Carlson From: Ignacio Goyret Subject: Re: L2F / L2TP Questions Cc: John Narron , l2tp@ipsec.org In-Reply-To: <14859.7792.328782.123257@h006008986325.ne.mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-l2tp@diameter.org Precedence: bulk At 05:00 PM 11/9/00 -0500, James Carlson wrote: >John Narron writes: >> We're about to embark on some expansion using some L2F/L2TP >> wizardry, and well frankly I'm not to sure how to set this crap >> up. We got the frame-relay circuit between the two access points >> set up correctly, but there's a slight problem - the LAC uses >> L2F, and the LNS only does L2TP. I had thought L2TP was backwards >> compatible w/ L2F? Am I right, or was I smoking some bad stuff? > >No, that's not right. L2TP can *coexist* with L2F on a given system >because they use different GRE version numbers, but they're in no way >compatible with each other. That's not quite right either :-) Neither L2F nor L2TP use GRE. L2F and L2TP share UDP port 1701. Since the size and position of the version field in the headers were made to match, you can distinguish one from the other. However, they are incompatible one with the other. They have different encodings, options, etc. Read RFC 2661 (L2TP) and RFC 2341 (L2F) for further information. From owner-l2tp@diameter.org Thu Nov 9 20:49:14 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17104 for ; Thu, 9 Nov 2000 20:49:14 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9Mtkj21171 for l2tp-list; Thu, 9 Nov 2000 14:55:46 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9MsQB21165 for ; Thu, 9 Nov 2000 14:54:26 -0800 Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id OAA04595 for ; Thu, 9 Nov 2000 14:00:34 -0800 (PST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id eA9M0G007960; Thu, 9 Nov 2000 17:00:16 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14859.7792.328782.123257@h006008986325.ne.mediaone.net> Date: Thu, 9 Nov 2000 17:00:16 -0500 (EST) To: John Narron Cc: l2tp@ipsec.org Subject: Re: L2F / L2TP Questions In-Reply-To: John Narron's message of 9 November 2000 10:50:09 References: X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit John Narron writes: > We're about to embark on some expansion using some L2F/L2TP > wizardry, and well frankly I'm not to sure how to set this crap > up. We got the frame-relay circuit between the two access points > set up correctly, but there's a slight problem - the LAC uses > L2F, and the LNS only does L2TP. I had thought L2TP was backwards > compatible w/ L2F? Am I right, or was I smoking some bad stuff? No, that's not right. L2TP can *coexist* with L2F on a given system because they use different GRE version numbers, but they're in no way compatible with each other. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Thu Nov 9 21:14:31 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23383 for ; Thu, 9 Nov 2000 21:14:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9NdFo21231 for l2tp-list; Thu, 9 Nov 2000 15:39:15 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9NdAB21225 for ; Thu, 9 Nov 2000 15:39:10 -0800 Received: from mailsrv.acc.com (mailsrv.acc.com [129.192.64.128]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id OAA04630 for ; Thu, 9 Nov 2000 14:45:18 -0800 (PST) Received: from acc.com (calcium.dev.acc.am.ericsson.se [129.192.57.200]) by mailsrv.acc.com (8.9.3/8.9.1) with ESMTP id OAA18603; Thu, 9 Nov 2000 14:43:49 -0700 (PPET) Message-ID: <3A0B2A45.3A8F3384@acc.com> Date: Thu, 09 Nov 2000 14:50:45 -0800 From: Evan Caves X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Fabio Poggi CC: l2tp@ipsec.org Subject: Re: L2TP/UDP/IP model question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Fabio Poggi wrote: > > L2TP protocol, in RFC 2661, indicates that UDP/IP stack as one of the transport > media for a tunnel. > So we can have L2TP/UDP/IP/PHY. Not exactly sure what you mean by PHY here, if you mean an L2 protocol then yes you can have that. > L2TP is a particular case of Tunnel over IP. > > RFC 2667 ("Tunnel over IP MIB") section 4.1.1 states: > "Each logical interface (physical or virtual) has an ifEntry in the > Interfaces MIB. Tunnels are handled by creating a logical > interface (ifEntry) for each tunnel. These are then correlated, using > the ifStack table of the Interfaces MIB, to those interfaces on which > the local IPv4 addresses of the tunnels are configured." > > But ifStack model states that only physical interfaces under routing protocol > have to be present in these tables. Huh? Can you refresh my memory and point me to the statement in the ifStack MIB that says this. > > So how can I interpret the above RFC 2667 statement ? An IP tunnel endpoint has an associated IP address, usually one of the devices network interfaces (or perhaps a internal loopback interface), that network interface is logically bound to an interface in the ifStack model (perhaps a PPP, Ethernet or Frame Relay interface). Given this your tunnel interface would then sit on top (in the ifStack) of whatever interface (PPP, Ethernet etc) that the network interface is associated with. Make (absolutely no) sense, evan - > Does we have to model l2tpifindex and ifindex of the physical interface under > UDP with a single entry into the ifstack table ? > > Thanks. > Regards From owner-l2tp@diameter.org Thu Nov 9 21:41:25 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01688 for ; Thu, 9 Nov 2000 21:41:25 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eA9NxbA21264 for l2tp-list; Thu, 9 Nov 2000 15:59:37 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eA9NxWB21258 for ; Thu, 9 Nov 2000 15:59:32 -0800 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16009 for ; Thu, 9 Nov 2000 16:05:41 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA21082 for ; Thu, 9 Nov 2000 15:05:36 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA16903 for ; Thu, 9 Nov 2000 15:05:35 -0800 (PST) Date: Thu, 9 Nov 2000 15:02:56 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: test To: l2tp@l2tp.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk please ignore From owner-l2tp@diameter.org Thu Nov 9 22:02:55 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07194 for ; Thu, 9 Nov 2000 22:02:54 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA1Orn21409 for l2tp-list; Thu, 9 Nov 2000 17:24:53 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA1OnB21403 for ; Thu, 9 Nov 2000 17:24:49 -0800 Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA11503 for ; Thu, 9 Nov 2000 16:30:53 -0800 (PST) Message-ID: <3A0B40EA.936AC098@cisco.com> Date: Thu, 09 Nov 2000 16:27:22 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: l2tp@l2tp.net Subject: [Fwd: Re: L2F / L2TP Questions] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: L2F / L2TP Questions Date: Thu, 09 Nov 2000 14:10:41 -0800 From: "W. Mark Townsley" To: James Carlson CC: John Narron , l2tp@ipsec.org References: <14859.7792.328782.123257@h006008986325.ne.mediaone.net> James Carlson wrote: > > John Narron writes: > > We're about to embark on some expansion using some L2F/L2TP > > wizardry, and well frankly I'm not to sure how to set this crap > > up. We got the frame-relay circuit between the two access points > > set up correctly, but there's a slight problem - the LAC uses > > L2F, and the LNS only does L2TP. I had thought L2TP was backwards > > compatible w/ L2F? Am I right, or was I smoking some bad stuff? > > No, that's not right. L2TP can *coexist* with L2F on a given system > because they use different GRE version numbers, but they're in no way > compatible with each other. L2TP and L2F do not use GRE. They go exist because the use different version numbers in the L2TP/L2F header. > > -- > James Carlson > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Thu Nov 9 22:16:03 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10046 for ; Thu, 9 Nov 2000 22:16:02 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA1OCf21400 for l2tp-list; Thu, 9 Nov 2000 17:24:12 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA1O8B21394 for ; Thu, 9 Nov 2000 17:24:08 -0800 Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA10953 for ; Thu, 9 Nov 2000 16:30:13 -0800 (PST) Message-ID: <3A0B40C2.25C18FB2@cisco.com> Date: Thu, 09 Nov 2000 16:26:42 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: l2tp@l2tp.net Subject: [Fwd: Re: question] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: question Date: Wed, 08 Nov 2000 23:27:15 -0800 From: "W. Mark Townsley" To: Vipin Jain CC: "'pan.peisheng@mail.zte.com.cn'" ,l2tp@ipsec.org References: <940E42DB5D7FD4119C420004ACE6E0A03414FB@mailserver.shastanets.com> You can choose whether to accept them based on your own queue depths or other local conditions. However, the peer should not be sending more than one, unless of course these are 4 SCCRQ's :-) - Mark Vipin Jain wrote: > > no, unless other end is mis-behaving! > > -----Original Message----- > From: pan.peisheng@mail.zte.com.cn [mailto:pan.peisheng@mail.zte.com.cn] > Sent: Wednesday, November 08, 2000 9:46 PM > To: l2tp@ipsec.org > Subject: question > > When we create L2tp tunnel,if we identify our receive window size is 1, Can > we > receive > 4 control messages one time? From owner-l2tp@diameter.org Thu Nov 9 23:23:59 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02547 for ; Thu, 9 Nov 2000 23:23:58 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA1O1421392 for l2tp-list; Thu, 9 Nov 2000 17:24:01 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA1NtB21386 for ; Thu, 9 Nov 2000 17:23:55 -0800 Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA10789 for ; Thu, 9 Nov 2000 16:30:00 -0800 (PST) Message-ID: <3A0B40B5.EE327426@cisco.com> Date: Thu, 09 Nov 2000 16:26:29 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: l2tp@l2tp.net Subject: Posting problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Majordomo seemed to have booted me off the members list. Pat tells me that the problem has been corrected now. I will be forwarding messages that I tried to send over the past day or two. If your messages are not making it to the list, please feel free to send Pat email. For those that do not know, his email is: Pat.Calhoun@eng.sun.com - Mark From owner-l2tp@diameter.org Thu Nov 9 23:29:32 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04328 for ; Thu, 9 Nov 2000 23:29:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA256E21508 for l2tp-list; Thu, 9 Nov 2000 18:05:06 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA24QB21502 for ; Thu, 9 Nov 2000 18:04:26 -0800 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id RAA04759 for ; Thu, 9 Nov 2000 17:10:36 -0800 (PST) Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA06071; Thu, 9 Nov 2000 17:09:49 -0800 (PST) Message-ID: <3A0B4A08.EC587C6@cisco.com> Date: Thu, 09 Nov 2000 17:06:16 -0800 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Leone, Guido" CC: "'Adriaan van den Brand'" , l2tp@ipsec.org Subject: Re: R: L2TP over NAPT question References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-l2tp@diameter.org Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by charizard.diameter.org id eAA256E21508 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04328 I suspect you will find more NATs on the planet that support UDP than GRE, IPsec, or IP in IP. Since L2TP runs over UDP, it is therefore fairly NAT friendly (though perhaps not friendly enough for your cable modem if it only supports http). I would expect your Linux 2.2 kernel (with IP masquerading) to be able to handle NAPT of a UDP stream such as L2TP. The typical trip-up might be the scenerio listed below where L2TP moves off ports, though *most* implementations I see do not move off 1701. - Mark "Leone, Guido" wrote: > > GRE is a "protocol" (number 47) in itself (not using TCP or UDP to > encapsulate) : why are you saying that it cannot be as "NAT-friendly" as > L2TP ? > Regards, > Guido. > > > -----Messaggio originale----- > > Da: Adriaan van den Brand [SMTP:Adriaan.van.den.Brand@industree.nl] > > Inviato: giovedì 2 novembre 2000 10.29 > > A: 'Motonori Shindo'; Adriaan van den Brand > > Cc: l2tp@ipsec.org > > Oggetto: RE: L2TP over NAPT question > > > > Adriaan, > > > > L2TP encapsulates everything (ie. control & data msg) using UDP, so > > it's much more NAT-friendly than other tunneling protocols based on > > GRE ,IP-in-IP, IPsec, etc. However, there might be some cases where > > NAT doesn't work with L2TP. > > > > L2TP (over IP/UDP) works in the following way in terms of a port > > number usage (assuming a LAC initiates a tunnel creation): > > > > > > LAC LNS > > .xxx SCCRQ .1701 > > --------------------------> > > > > .xxx SCCRP .yyy > > <-------------------------- > > > > .xxx SCCCN .yyy > > ---------------------------> > > > > > > Here, .xxx and .yyy represent UDP port numbers. L2TP protocol allows > > .xxx and .yyy to be arbitarily chosen. Once .xxx and .yyy are > > determined, this pair will never change during the tunnel lifetime. A > > port number usage like this is very similar to what is used in tftp. > > > > Most implementations use 1701 for .xxx (but some don't) and almost all > > implementations also use 1701 for .yyy. However, there's a (very > > small) possibility that .yyy happens to be something different from > > 1701. In this case, if there is a NAT between the LAC and LNS, such a > > NAT will be confused and very likely to be unable to do NAT properly, > > unless it does some special treatment for L2TP packets (some clever > > NAT box does this for tftp, BTW). > > > > Cosidering the fact that .yyy being something other than 1701 is quite > > rare, L2TP *should* work with NAT, I would say. > > > > BTW, what are you using as a LAC and LNS? > > > > > > > > > > LAC & LNS: > > Redback SMS500 > > Enternet500 for client > > > > The NAT/PAT is located inside a cable modem. It doesn't have application > > support other than HTTP, so I guess that's the problem. > > > > It is mainly designed for provisioning purposes. > > > > Regards, > > Adriaan > > > > > > > > From: Adriaan van den Brand > > Subject: L2TP over NAPT question > > Date: Wed, 1 Nov 2000 13:14:15 +0100 > > > > > Hi, > > > > > > Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) > > > connection? We see some problems in the setup phase of the tunnels. For > > > NAPT, we use a Linux 2.2 kernel (with IP masquerading). > > > > > > Best regards, > > > Adriaan van den Brand > > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > +----+----+ > > |.. .| | Motonori Shindo > > |_~__| | > > | .. |~~_~| Sr. Systems Engineer > > | . | | CoSine Communications Inc. > > +----+----+ > > C o S i n e e-mail: mshindo@cosinecom.com > > Communications > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > From owner-l2tp@diameter.org Fri Nov 10 04:10:52 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13369 for ; Fri, 10 Nov 2000 04:10:51 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAA6Bjb22060 for l2tp-list; Thu, 9 Nov 2000 22:11:45 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAA6AQB22054 for ; Thu, 9 Nov 2000 22:10:26 -0800 Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id VAA04992 for ; Thu, 9 Nov 2000 21:16:35 -0800 (PST) Received: from cosinecom.com (IDENT:proxyuser@011.cosine.nttpc.gr.jp [202.229.42.11] (may be forged)) by center.mshindo.net (8.9.3/3.7W/00041811) with SMTP id OAA65470 for ; Fri, 10 Nov 2000 14:31:17 +0900 (JST) Date: Fri, 10 Nov 2000 14:17:21 +0900 (JST) Message-Id: <20001110.141721.48537963.mshindo@mshindo.net> To: l2tp@ipsec.org Subject: Re: [Fwd: R: L2TP over NAPT question] From: Motonori Shindo In-Reply-To: <3A0B6B7D.D42EED7@cosinecom.com> References: <20001109.171108.78704335.mshindo@cosinecom.com> <20001110.122842.59648782.mshindo@cosinecom.com> <3A0B6B7D.D42EED7@cosinecom.com> X-Mailer: Mew version 1.95b30 on XEmacs 21.1 (Canyonlands) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Leone, Due to the confusion of this mailing list for the last couple of days, I didn't receive your e-mail (my colleague forwarded this to me:-)). I used the term "NAT" rather generically. To be more precise, I should have said PAT (aka IP masquerading) in this case. Since GRE is neither TCP nor UDP, it's impossible to do PAT. Suppose there are five users behind a PAT which masquerades 5 internal IP addresses to one global IP address, it's quite difficult for these users to use PPTP through NAT simultaneously because TCP/UDP port number can't be utilized for masquerading. From this perspective, L2TP, which uses UDP for encapsulation, is more PAT-friendly over GRE-based tunneling mechanisms like PPTP and ATMP. Regards, > > > > "Leone, Guido" wrote: > > > > > > > > > > GRE is a "protocol" (number 47) in itself (not using TCP or UDP to > > > > > encapsulate) : why are you saying that it cannot be as "NAT-friendly" as > > > > > L2TP ? > > > > > Regards, > > > > > Guido. > > > > > > > > > > > -----Messaggio originale----- > > > > > > Da: Adriaan van den Brand [SMTP:Adriaan.van.den.Brand@industree.nl] > > > > > > Inviato: gioved$B!)(B2 novembre 2000 10.29 > > > > > > A: 'Motonori Shindo'; Adriaan van den Brand > > > > > > Cc: l2tp@ipsec.org > > > > > > Oggetto: RE: L2TP over NAPT question > > > > > > > > > > > > Adriaan, > > > > > > > > > > > > L2TP encapsulates everything (ie. control & data msg) using UDP, so > > > > > > it's much more NAT-friendly than other tunneling protocols based on > > > > > > GRE ,IP-in-IP, IPsec, etc. However, there might be some cases where > > > > > > NAT doesn't work with L2TP. > > > > > > > > > > > > L2TP (over IP/UDP) works in the following way in terms of a port > > > > > > number usage (assuming a LAC initiates a tunnel creation): > > > > > > > > > > > > > > > > > > LAC LNS > > > > > > .xxx SCCRQ .1701 > > > > > > --------------------------> > > > > > > > > > > > > .xxx SCCRP .yyy > > > > > > <-------------------------- > > > > > > > > > > > > .xxx SCCCN .yyy > > > > > > ---------------------------> > > > > > > > > > > > > > > > > > > Here, .xxx and .yyy represent UDP port numbers. L2TP protocol allows > > > > > > .xxx and .yyy to be arbitarily chosen. Once .xxx and .yyy are > > > > > > determined, this pair will never change during the tunnel lifetime. A > > > > > > port number usage like this is very similar to what is used in tftp. > > > > > > > > > > > > Most implementations use 1701 for .xxx (but some don't) and almost all > > > > > > implementations also use 1701 for .yyy. However, there's a (very > > > > > > small) possibility that .yyy happens to be something different from > > > > > > 1701. In this case, if there is a NAT between the LAC and LNS, such a > > > > > > NAT will be confused and very likely to be unable to do NAT properly, > > > > > > unless it does some special treatment for L2TP packets (some clever > > > > > > NAT box does this for tftp, BTW). > > > > > > > > > > > > Cosidering the fact that .yyy being something other than 1701 is quite > > > > > > rare, L2TP *should* work with NAT, I would say. > > > > > > > > > > > > BTW, what are you using as a LAC and LNS? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > LAC & LNS: > > > > > > Redback SMS500 > > > > > > Enternet500 for client > > > > > > > > > > > > The NAT/PAT is located inside a cable modem. It doesn't have application > > > > > > support other than HTTP, so I guess that's the problem. > > > > > > > > > > > > It is mainly designed for provisioning purposes. > > > > > > > > > > > > Regards, > > > > > > Adriaan > > > > > > > > > > > > > > > > > > > > > > > > From: Adriaan van den Brand > > > > > > Subject: L2TP over NAPT question > > > > > > Date: Wed, 1 Nov 2000 13:14:15 +0100 > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Has anyone got experience in running L2TP tunnels over a NAPT (NAT/PAT) > > > > > > > connection? We see some problems in the setup phase of the tunnels. For > > > > > > > NAPT, we use a Linux 2.2 kernel (with IP masquerading). > > > > > > > > > > > > > > Best regards, > > > > > > > Adriaan van den Brand > > > > > > > > > > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > > > > > +----+----+ > > > > > > |.. .| | Motonori Shindo > > > > > > |_~__| | > > > > > > | .. |~~_~| Sr. Systems Engineer > > > > > > | . | | CoSine Communications Inc. > > > > > > +----+----+ > > > > > > C o S i n e e-mail: mshindo@cosinecom.com > > > > > > Communications > > > > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > > > > > > > > > > > > > -- > > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > > > > > +----+----+ Tatsuya Yanagibashi > > > > |.. .| | > > > > |_~__| | Network Consultant > > > > | .. |~~_~| CoSine Communications Inc. > > > > | . | | > > > > +----+----+ e-mail: tyanagibashi@cosinecom.com > > > > C o S i n e Phone # +81-3-5219-1296 > > > > Communications Fax # +81-3-5219-1201 > > > > > > > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > > +----+----+ > > > |.. .| | Motonori Shindo > > > |_~__| | > > > | .. |~~_~| Sr. Systems Engineer > > > | . | | CoSine Communications Inc. > > > +----+----+ > > > C o S i n e e-mail: mshindo@cosinecom.com > > > Communications > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > +----+----+ > > |.. .| | Motonori Shindo > > |_~__| | > > | .. |~~_~| Sr. Systems Engineer > > | . | | CoSine Communications Inc. > > +----+----+ > > C o S i n e e-mail: mshindo@cosinecom.com > > Communications > > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= > > -- > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > +----+----+ Tatsuya Yanagibashi > |.. .| | > |_~__| | Network Consultant > | .. |~~_~| CoSine Communications Inc. > | . | | > +----+----+ e-mail: tyanagibashi@cosinecom.com > C o S i n e Phone # +81-3-5219-1296 > Communications Fax # +81-3-5219-1201 > > /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= From owner-l2tp@diameter.org Fri Nov 10 11:29:09 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27705 for ; Fri, 10 Nov 2000 11:29:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAAEBih23013 for l2tp-list; Fri, 10 Nov 2000 06:11:44 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAAEAPB23007 for ; Fri, 10 Nov 2000 06:10:25 -0800 Received: from S100085A.private.sterlingbancorp.com (hidden-user@[206.20.228.11]) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id FAA06666 for ; Fri, 10 Nov 2000 05:16:35 -0800 (PST) Received: from win98005([172.18.198.201]) by S100085A.PRIVATE.STERLINGBANCORP.COM (IBM OS/400 SMTP V04R05M00) with TCP; Fri, 10 Nov 2000 08:15:21 -0400 Reply-To: From: "Eliot Robinson" To: Subject: Windows2000 IPSec/L2TP VPN Security Threats Date: Fri, 10 Nov 2000 08:02:00 -0500 Message-ID: <001001c04b16$6b1f48f0$c9c612ac@win98005> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C04AEC.825A09D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-l2tp@diameter.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C04AEC.825A09D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I have heard that once a hacker has access to your PC, the hacker from the internet can ride your VPN tunnel to your secure network. I thought that once you connected to your IPSec/L2TP session, internet access was blocked. Assume a dial up connection to the internet and then a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? Second assumption, assume a DSL or cable modem connection to the internet and a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? If there are security threats, are these being taken into account in the development/enhancement of the standards for L2TP and IPSec? Does anyone know of any good reading material on this subject? Thanks, Eliot Eliot S. Robinson Sterling National Bank 430 Park Avenue, 4th Floor New York, NY 10022-3505 ------=_NextPart_000_0011_01C04AEC.825A09D0 Content-Type: text/x-vcard; name="Eliot S. Robinson (E-mail).vcf" Content-Disposition: attachment; filename="Eliot S. Robinson (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Robinson;Eliot FN:Eliot S. Robinson (E-mail) ORG:Sterling National Bank TITLE:Executive Vice President TEL;WORK;VOICE:(212) 826-8016 TEL;HOME;VOICE:(212) 288-3535 TEL;CELL;VOICE:(917) 848-1524 TEL;WORK;FAX:(212) 826-8027 ADR;WORK:;;430 Park Avenue, 4th Floor;New York;NY;10022-3505;United = States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:430 Park Avenue, 4th = Floor=3D0D=3D0ANew York, NY 10022-3505=3D0D=3D0AUnited States o=3D f America EMAIL;PREF;INTERNET:Eliot.Robinson@STERLINGBANCORP.COM REV:19990708T122425Z END:VCARD ------=_NextPart_000_0011_01C04AEC.825A09D0-- From owner-l2tp@diameter.org Fri Nov 10 11:58:55 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08021 for ; Fri, 10 Nov 2000 11:58:54 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAAFIsu23120 for l2tp-list; Fri, 10 Nov 2000 07:18:54 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAAFIoB23114 for ; Fri, 10 Nov 2000 07:18:50 -0800 Received: from S100085A.private.sterlingbancorp.com (hidden-user@[206.20.228.11]) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id GAA06713 for ; Fri, 10 Nov 2000 06:25:00 -0800 (PST) Received: from win98005([172.18.198.201]) by S100085A.PRIVATE.STERLINGBANCORP.COM (IBM OS/400 SMTP V04R05M00) with TCP; Fri, 10 Nov 2000 09:24:53 -0400 Reply-To: From: "Eliot Robinson" To: Subject: test Date: Fri, 10 Nov 2000 09:11:36 -0500 Message-ID: <003401c04b20$23dff390$c9c612ac@win98005> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit disregard. From owner-l2tp@diameter.org Fri Nov 10 16:32:25 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14545 for ; Fri, 10 Nov 2000 16:32:25 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAAIYUP23511 for l2tp-list; Fri, 10 Nov 2000 10:34:30 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAAIX8B23505 for ; Fri, 10 Nov 2000 10:33:09 -0800 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id JAA06925 for ; Fri, 10 Nov 2000 09:39:19 -0800 (PST) Received: by BOR with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 12:33:48 -0500 Message-ID: From: "Chen, David" To: "'eliot.robinson@STERLINGBANCORP.COM'" , l2tp@ipsec.org Subject: RE: test Date: Fri, 10 Nov 2000 12:33:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04B3C.6191C33C" Sender: owner-l2tp@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04B3C.6191C33C Content-Type: text/plain; charset="windows-1252" Successful!!! -----Original Message----- From: Eliot Robinson [mailto:eliot.robinson@STERLINGBANCORP.COM] Sent: Friday, November 10, 2000 9:12 AM To: l2tp@ipsec.orgj Subject: test disregard. ------_=_NextPart_001_01C04B3C.6191C33C Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: test

Successful!!!

-----Original Message-----
From: Eliot Robinson [mailto:eliot.robinson= @STERLINGBANCORP.COM]
Sent: Friday, November 10, 2000 9:12 AM
To: l2tp@ipsec.orgj
Subject: test


disregard.

------_=_NextPart_001_01C04B3C.6191C33C-- From owner-l2tp@diameter.org Sat Nov 11 05:02:15 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18830 for ; Sat, 11 Nov 2000 05:02:14 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAB9Fm024368 for l2tp-list; Sat, 11 Nov 2000 01:15:48 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAB9FXB24362 for ; Sat, 11 Nov 2000 01:15:33 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id AAA07901 for ; Sat, 11 Nov 2000 00:21:38 -0800 (PST) From: zong.zaifeng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256994.002C3A49 ; Sat, 11 Nov 2000 16:03:05 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256994.002C3995.00@mail.zhongxing.com> Date: Sat, 11 Nov 2000 15:48:40 +0800 Subject: When will LAC answer the call? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Hi, Q1: When do LAC answer the call and do LCP negotiation? I think it may answer the call before starting a session or after receiving ICRP. Is that right? And I want to know which one we usually adopt. I remember rfc2661(section 7.4) says we will answer the call after we receive ICRP, does this sequence have to be obeyed? Q2: I think there may be some ambiguities in protocol rfc2661, that in section 4.3, there are some terms which have made me confused. what does the AV refer to in function "b1 = MD5(AV + S + RV)"? It is attribute type or attribute value? From paragraph just before, I found "the Attribute Value AV", it seems that AV is "the attribute value", but prior to this paragraph, there's a sentence"Next, An MD5 hash is performed on the concatenation of:+the 2 octet Attribute number of the AVP...", it seems the AV should refer to this "attribute number of the avp", but what's "attribute number", is it just attribute type? And I have checked that attribute number is found only once in rfc2661. I think the AV in "b1=MD5(AV+S+RV)" means attribute type, is that right? Or am I wrong thoroughly? Regards ZZF From owner-l2tp@diameter.org Sat Nov 11 16:29:54 2000 Received: from charizard.diameter.org (nobody@[24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26713 for ; Sat, 11 Nov 2000 16:29:54 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eABK14u24824 for l2tp-list; Sat, 11 Nov 2000 12:01:04 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eABK0wB24813 for ; Sat, 11 Nov 2000 12:00:58 -0800 Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id LAA09522 for ; Sat, 11 Nov 2000 11:07:13 -0800 (PST) Received: from gwzpc (rtp-dial-1-137.cisco.com [10.83.97.137]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA18344; Sat, 11 Nov 2000 11:05:50 -0800 (PST) Reply-To: From: "Glen Zorn" To: , Subject: RE: When will LAC answer the call? Date: Sat, 11 Nov 2000 11:05:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <48256994.002C3995.00@mail.zhongxing.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hi, > > Q1: When do LAC answer the call and do LCP negotiation? I think > it may answer > the call before starting a session or after receiving ICRP. Is > that right? And I > want to know which one we usually adopt. I remember > rfc2661(section 7.4) says we > will answer the call after we receive ICRP, does this sequence have to be > obeyed? Not necessarily. The LAC might answer the call, negotiate LCP and tunnel the call (or not) based upon the NAI for example. > > Q2: I think there may be some ambiguities in protocol rfc2661, > that in section > 4.3, there are some terms which have made me confused. what does > the AV refer to > in function "b1 = MD5(AV + S + RV)"? It is attribute type or > attribute value? Attribute type. > >From paragraph just before, I found "the Attribute Value AV", it > seems that AV > is "the attribute value", but prior to this paragraph, there's a > sentence"Next, > An MD5 hash is performed on the concatenation of:+the 2 octet > Attribute number > of the AVP...", it seems the AV should refer to this "attribute > number of the > avp", but what's "attribute number", is it just attribute type? Yes, it's the Attribute Type field from the AVP to be hidden. I agree that this may be confusing; we should change it in RFC2661bis. > And I have > checked that attribute number is found only once in rfc2661. I > think the AV in > "b1=MD5(AV+S+RV)" means attribute type, is that right? Yes. > Or am I > wrong thoroughly? > > Regards > ZZF > > > From owner-l2tp@diameter.org Mon Nov 13 04:55:55 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10361 for ; Mon, 13 Nov 2000 04:55:54 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAD7q9A31377 for l2tp-list; Sun, 12 Nov 2000 23:52:09 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAD7okB31371 for ; Sun, 12 Nov 2000 23:50:47 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id WAA12360 for ; Sun, 12 Nov 2000 22:56:59 -0800 (PST) From: pan.peisheng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256996.00262BB7 ; Mon, 13 Nov 2000 14:56:55 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256996.00262AC9.00@mail.zhongxing.com> Date: Mon, 13 Nov 2000 14:56:07 +0800 Subject: question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Question 1:If in Framing Capabilities AVP in SCCRQ sent by LAC ,bit A is set while in Framing Capabilities AVP in SCCRP sent by LNS,bit S is set,whether L2tp tunnel between LAC and LNS can be established or not? Question 2:If the tunnel could be established,when we establish a session in this tunnel by sending ICRQ ,need we reference to the Framing Capabilities AVP of LNS? From owner-l2tp@diameter.org Mon Nov 13 11:59:34 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29633 for ; Mon, 13 Nov 2000 11:59:34 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eADEivq31789 for l2tp-list; Mon, 13 Nov 2000 06:44:57 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eADEirB31783 for ; Mon, 13 Nov 2000 06:44:54 -0800 Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id FAA13865 for ; Mon, 13 Nov 2000 05:51:14 -0800 (PST) Received: by email.quarrytech.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 08:46:22 -0500 Message-ID: <496A8683261CD211BF6C0008C733261AA80769@email.quarrytech.com> From: "Fox, David" To: "'eliot.robinson@STERLINGBANCORP.COM'" Cc: l2tp@ipsec.org Subject: RE: Windows2000 IPSec/L2TP VPN Security Threats Date: Mon, 13 Nov 2000 08:46:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk Eliot, The answer is that it "depends." There are two scenarios that I've heard from customers: 1) They want all access to the corporate and Internet going through the corporate network and thus through the VPN. In the case of the Internet access, the traffic would then go through the corporate firewall. That traffic can then be tracked, if corporate policy requires it. 2) They want the corporate traffic going through the VPN and they could care less about the Internet traffic. That traffic would then be routed in the clear through the user's ISP. Take the case of a retailer's store that needs to use a VPN back to corporate for sales tracking and then access to a bank's credit card authorization system that lives on the Internet. That traffic would be protected by whatever mechanism the bank requires. Both cases can be accommodated by appropriate policies in the IPsec SPD. So the answer to your question is that if the VPN is implemented as described in #2, then there is the possibility for the hacker to gain access to the corporate network if the VPN is sitting there open and active. My former employer at one point required employees to log into the corporate network via the web before access to web based information was allowed. There are other possibilities as well. Depending on the VPN client on the PC, it is possible to tear down the VPN session after a timeout or each use and require a password, digital certificate, or other security mechanism to re-establish it. < The previous comment is a supposition as I haven't fully investigated all of those abilities. It really depends on what you are using for a VPN client. Your company's security policies also play a role here as some of the VPN clients can enforce global security policies are pre-defined by the corporate network security managers.> David =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= David Fox Quarry Technologies dfox@quarrytech.com 8 New England Executive Park Office: 781-505-8300 x335 Burlington, Massachusetts 01803 FAX: 781-505-8316 www.quarrytech.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: Eliot Robinson [mailto:eliot.robinson@STERLINGBANCORP.COM] Sent: Friday, November 10, 2000 8:02 AM To: l2tp@ipsec.org Subject: Windows2000 IPSec/L2TP VPN Security Threats << File: Eliot S. Robinson (E-mail).vcf >> I have heard that once a hacker has access to your PC, the hacker from the internet can ride your VPN tunnel to your secure network. I thought that once you connected to your IPSec/L2TP session, internet access was blocked. Assume a dial up connection to the internet and then a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? Second assumption, assume a DSL or cable modem connection to the internet and a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? If there are security threats, are these being taken into account in the development/enhancement of the standards for L2TP and IPSec? Does anyone know of any good reading material on this subject? Thanks, Eliot Eliot S. Robinson Sterling National Bank 430 Park Avenue, 4th Floor New York, NY 10022-3505 From owner-l2tp@diameter.org Mon Nov 13 18:43:07 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08413 for ; Mon, 13 Nov 2000 18:43:06 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eADMDEh32203 for l2tp-list; Mon, 13 Nov 2000 14:13:14 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eADMBtB32197 for ; Mon, 13 Nov 2000 14:11:56 -0800 Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id NAA14260 for ; Mon, 13 Nov 2000 13:18:17 -0800 (PST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 13 Nov 2000 15:50:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 13 Nov 2000 15:50:32 -0500 Message-ID: From: "Peter Tam" To: pan.peisheng@mail.zte.com.cn, l2tp@ipsec.org Subject: RE: question Date: Mon, 13 Nov 2000 15:50:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04DB3.5A2D5920" X-Orig: Sender: owner-l2tp@diameter.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04DB3.5A2D5920 Content-Type: text/plain; charset="iso-8859-1" Pan (I guess): My take is that the receiver should never set the S-bit in a SCCRP response in the 1st place, after an A-bit was received in SCCRQ. However, if the S-bit is incorrectly set by receiver, then the sender should send a StopCCN to terminate the attempt upon receiving this incorrect S-bit setting in the SCCRP. This applies to both the A-bit and S-bit paradigms for LAC/LNS initiated connection controls. The states machine is in Section 7.2.1. Regards....Peter Tam, Nortel Networks -----Original Message----- From: pan.peisheng@mail.zte.com.cn [SMTP:pan.peisheng@mail.zte.com.cn] Sent: Monday, November 13, 2000 1:56 AM To: l2tp@ipsec.org Subject: question Question 1:If in Framing Capabilities AVP in SCCRQ sent by LAC ,bit A is set while in Framing Capabilities AVP in SCCRP sent by LNS,bit S is set,whether L2tp tunnel between LAC and LNS can be established or not? Question 2:If the tunnel could be established,when we establish a session in this tunnel by sending ICRQ ,need we reference to the Framing Capabilities AVP of LNS? ------_=_NextPart_001_01C04DB3.5A2D5920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question

Pan (I guess):

My take is that the receiver should = never set the S-bit in a SCCRP response in the 1st = place, after an A-bit was received in SCCRQ. However, if the S-bit is = incorrectly set by receiver, then the sender should send a StopCCN to = terminate the attempt upon receiving this incorrect S-bit setting in = the SCCRP. This applies to both the A-bit and S-bit paradigms = for LAC/LNS initiated connection = controls. The states machine is in = Section 7.2.1.

Regards....Peter Tam,
Nortel Networks

    -----Original = Message-----
    From:   = pan.peisheng@mail.zte.com.cn = [SMTP:pan.peisheng@mail.zte.com.cn]
    Sent:   Monday, November 13, 2000 1:56 AM
    To:     l2tp@ipsec.org
    Subject:       = question



    Question 1:If in Framing Capabilities = AVP in SCCRQ  sent by LAC ,bit A is set
    while
             &nb= sp;    in Framing Capabilities AVP in SCCRP sent by = LNS,bit S is
    set,whether
             &nb= sp;    L2tp tunnel between LAC and LNS can be = established or not?
    Question 2:If the tunnel could be = established,when we establish a session in
    this tunnel = by     sending ICRQ ,need we reference to the = Framing Capabilities
    AVP of LNS?

------_=_NextPart_001_01C04DB3.5A2D5920-- From owner-l2tp@diameter.org Tue Nov 14 07:03:10 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16202 for ; Tue, 14 Nov 2000 07:03:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAE9wAH32654 for l2tp-list; Tue, 14 Nov 2000 01:58:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAE9w7B32648 for ; Tue, 14 Nov 2000 01:58:07 -0800 Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id BAA14857 for ; Tue, 14 Nov 2000 01:04:31 -0800 (PST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id BAA13759; Tue, 14 Nov 2000 01:04:27 -0800 (PST) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA02170; Tue, 14 Nov 00 01:30:29 -0800 From: "Bernard Aboba" To: , Subject: RE: Windows2000 IPSec/L2TP VPN Security Threats Date: Tue, 14 Nov 2000 00:49:25 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <001001c04b16$6b1f48f0$c9c612ac@win98005> Importance: Normal Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Let us assume that "having access to your PC" means having access to the administrator password. This by itself would not give the attacker the credentials required to bring up L2TP/IPSEC tunnels (unless the save password option were selected, a very bad idea). Moreover, once an L2TP/IPSEC tunnel is set up, a default route is plumbed pointing down the tunnel. This means that unless there is a route to the attacker, either from the attacked system or via the attacked corpnet, then once the tunnel comes up packets will no longer be routed correclty from the attacked system back to the attacker. There are several actions you can take to protect against this attack. The first measure is to use packet filtering or IPSEC to protect BackOrifice, Terminal Services, Netmeeting Remote Control and Telnet ports on machines that will be bringing up tunnels to the corporate network. That way attackers will not be able to gain access via these ports easily. I also recommend turning forwarding off. Additional measures include use of smartcards or crypto tokens for user login and/or VPN access (this will only prevent an attacker from physically logging into the machine or bringing up a tunnel; it will not prevent an attacker who has gained access from using existing tunnels). A major cause of compromises are poorly chosen passwords, so that the strong password option should be selected to improve password security. -----Original Message----- From: owner-l2tp@diameter.org [mailto:owner-l2tp@diameter.org]On Behalf Of Eliot Robinson Sent: Friday, November 10, 2000 5:02 AM To: l2tp@ipsec.org Subject: Windows2000 IPSec/L2TP VPN Security Threats I have heard that once a hacker has access to your PC, the hacker from the internet can ride your VPN tunnel to your secure network. I thought that once you connected to your IPSec/L2TP session, internet access was blocked. Assume a dial up connection to the internet and then a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? Second assumption, assume a DSL or cable modem connection to the internet and a Windows2000 IPSec/L2TP VPN connection to a secure network, what are the security threats? If there are security threats, are these being taken into account in the development/enhancement of the standards for L2TP and IPSec? Does anyone know of any good reading material on this subject? Thanks, Eliot Eliot S. Robinson Sterling National Bank 430 Park Avenue, 4th Floor New York, NY 10022-3505 From owner-l2tp@diameter.org Wed Nov 15 23:55:44 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12098 for ; Wed, 15 Nov 2000 23:55:44 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAG3dWs03691 for l2tp-list; Wed, 15 Nov 2000 19:39:32 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAG3dLB03684 for ; Wed, 15 Nov 2000 19:39:21 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id SAA19580 for ; Wed, 15 Nov 2000 18:45:48 -0800 (PST) From: pan.peisheng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256999.000F3047 ; Thu, 16 Nov 2000 10:45:53 +0800 X-Lotus-FromDomain: ZTE_LTD To: l2tp@ipsec.org Message-ID: <48256999.000F2EF2.00@mail.zhongxing.com> Date: Thu, 16 Nov 2000 10:46:27 +0800 Subject: question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Whether all session in a L2tp tunnel have the same private groupid and same peer ip address? From owner-l2tp@diameter.org Thu Nov 16 03:34:35 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29986 for ; Thu, 16 Nov 2000 03:34:34 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAG6xt003958 for l2tp-list; Wed, 15 Nov 2000 22:59:55 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAG6wZB03952 for ; Wed, 15 Nov 2000 22:58:36 -0800 Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133] (may be forged)) by ns1.sailpix.com (8.8.8/8.6.9) with SMTP id WAA19772 for ; Wed, 15 Nov 2000 22:05:00 -0800 (PST) From: zong.zaifeng@mail.zte.com.cn Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 48256999.00216EEE ; Thu, 16 Nov 2000 14:05:10 +0800 X-Lotus-FromDomain: ZTE_LTD To: pan.peisheng@mail.zte.com.cn cc: l2tp@ipsec.org Message-ID: <48256999.00216EA3.00@mail.zhongxing.com> Date: Thu, 16 Nov 2000 14:05:49 +0800 Subject: ´ð¸´: question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk For peer ip address, I think it's true. For private groupid, it's not necessary, if private groupid is got from radius(radius server maybe look it up according to the username and password) then there maybe have different private groupid in a tunnel, this private groupid may be used by LNS to distribute remote users to different servers or give them different privilege. Whether all session in a L2tp tunnel have the same private groupid and same peer ip address? From owner-l2tp@diameter.org Tue Nov 21 12:47:03 2000 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20665 for ; Tue, 21 Nov 2000 12:47:02 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALGVwj19111 for l2tp-list; Tue, 21 Nov 2000 08:31:58 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALGVrH19105 for ; Tue, 21 Nov 2000 08:31:53 -0800 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id HAA04205 for ; Tue, 21 Nov 2000 07:38:36 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id PAA18755 for ; Tue, 21 Nov 2000 15:39:42 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 15:38:24 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 07:38:23 -0800 Message-ID: From: "Ahmed, Hany" To: l2tp@ipsec.org Subject: l2TP with dynamic routing. Date: Tue, 21 Nov 2000 07:38:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk Hi, I was just wondering about the possibilty of using dynamic routing protocols (RIP/OSPF etc..) through the L2TP tunnel to exchange network topology information between the remote client and the LNS, is there any related draft to address any problems or concerns. Is there also any new AVP that indicates the ability of the remote end to accept certain routing protocols ? thanks alot Hany A. Ahmed Software Engineer Intel of Canada, Ltd. 2 Eva road , suite 220 Toronto, ON 416-622-8930 Hany.Ahmed@intel.com From owner-l2tp@diameter.org Tue Nov 21 13:11:04 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26350 for ; Tue, 21 Nov 2000 13:11:01 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALH8Oh19206 for l2tp-list; Tue, 21 Nov 2000 09:08:24 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALH7mH19200 for ; Tue, 21 Nov 2000 09:07:48 -0800 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id IAA04248 for ; Tue, 21 Nov 2000 08:14:35 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29928; Tue, 21 Nov 2000 09:14:32 -0700 (MST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA15701; Tue, 21 Nov 2000 11:14:32 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eALGEdg143212; Tue, 21 Nov 2000 11:14:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.40815.487512.642717@gargle.gargle.HOWL> Date: Tue, 21 Nov 2000 11:14:39 -0500 (EST) From: James Carlson To: "Ahmed, Hany" Cc: l2tp@ipsec.org Subject: Re: l2TP with dynamic routing. In-Reply-To: Ahmed, Hany's message of 21 November 2000 07:38:17 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ahmed, Hany writes: > I was just wondering about the possibilty of using dynamic routing protocols > (RIP/OSPF etc..) through the L2TP tunnel to exchange network topology > information between the remote client and the LNS, If you're running IP over that PPP link then, yes, you can run routing protocols. > is there any related > draft to address any problems or concerns. Such as what? Is this different from a routing protocol over any other kind of point-to-point link? On-demand and bandwidth-limited links have special problems; those are addressed in the many RFCs dealing with such situations, such as Triggered RIP (RFC 2091). > Is there also any new AVP that indicates the ability of the remote end to > accept > certain routing protocols ? I don't see why you'd want that. If you had just PPP over a direct serial link, how would you detect that the peer supports a routing protocol? Doesn't that same method work here? -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Tue Nov 21 13:18:54 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28156 for ; Tue, 21 Nov 2000 13:18:49 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALHlpj19369 for l2tp-list; Tue, 21 Nov 2000 09:47:51 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALHllH19363 for ; Tue, 21 Nov 2000 09:47:47 -0800 Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id IAA04273 for ; Tue, 21 Nov 2000 08:54:35 -0800 (PST) Received: from ebooth-linux.cisco.com (ebooth@ebooth-linux.cisco.com [161.44.58.52]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA20980; Tue, 21 Nov 2000 11:53:12 -0500 (EST) Date: Tue, 21 Nov 2000 11:53:45 -0500 (EST) From: Skip Booth To: "Ahmed, Hany" cc: "'James Carlson'" , Subject: RE: l2TP with dynamic routing. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk On Tue, 21 Nov 2000, Ahmed, Hany wrote: > > You are right about using demand-dialing over the tunnel. > > The reason I was asking about a new AVP is to determine > the possibility of the LNS to use RIP/OSPF with the client > once it finds out about this capability. > > If the client doesn't support it, it can be disabled on > the link all together and save any bandwidth you may use > for that purpose. If this is your intention, it would be better to negotiate this within IPCP than L2TP. This really shouldn't have anything to do with L2TP. Especially in compulsory tunneling where the LAC may not have any knowledge of what options the client supports. > > There was also the indication that with SPAP you can request > routing as well, I guess SPAP is not that bad after all! Funny place to put IP parameters if you ask me. -Skip > > > Thanks, > > Hany A. Ahmed > Software Engineer > Intel of Canada, Ltd. > 2 Eva road , suite 220 > Toronto, ON > 416-622-8930 > Hany.Ahmed@intel.com > > > > > -----Original Message----- > > From: James Carlson [mailto:james.d.carlson@east.sun.com] > > Sent: Tuesday, November 21, 2000 11:15 AM > > To: Ahmed, Hany > > Cc: l2tp@ipsec.org > > Subject: Re: l2TP with dynamic routing. > > > > > > Ahmed, Hany writes: > > > I was just wondering about the possibilty of using dynamic > > routing protocols > > > (RIP/OSPF etc..) through the L2TP tunnel to exchange > > network topology > > > information between the remote client and the LNS, > > > > If you're running IP over that PPP link then, yes, you can run routing > > protocols. > > > > > is there any related > > > draft to address any problems or concerns. > > > > Such as what? Is this different from a routing protocol over any > > other kind of point-to-point link? > > > > On-demand and bandwidth-limited links have special problems; those are > > addressed in the many RFCs dealing with such situations, such as > > Triggered RIP (RFC 2091). > > > > > Is there also any new AVP that indicates the ability of the > > remote end to > > > accept > > > certain routing protocols ? > > > > I don't see why you'd want that. If you had just PPP over a direct > > serial link, how would you detect that the peer supports a routing > > protocol? Doesn't that same method work here? > > > > -- > > James Carlson, Internet Engineering > > > > SUN Microsystems / 1 Network Drive 71.234W Vox +1 > > 781 442 2084 > > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > > 781 442 1677 > > Second Edition now available - > > http://people.ne.mediaone.net/carlson/ppp > > > > From owner-l2tp@diameter.org Tue Nov 21 13:24:13 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29429 for ; Tue, 21 Nov 2000 13:24:09 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALHWf919287 for l2tp-list; Tue, 21 Nov 2000 09:32:41 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALHWaH19281 for ; Tue, 21 Nov 2000 09:32:37 -0800 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id IAA04261 for ; Tue, 21 Nov 2000 08:39:24 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA28476; Tue, 21 Nov 2000 16:40:41 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 16:39:20 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 08:39:19 -0800 Message-ID: From: "Ahmed, Hany" To: "'James Carlson'" Cc: l2tp@ipsec.org Subject: RE: l2TP with dynamic routing. Date: Tue, 21 Nov 2000 08:39:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk You are right about using demand-dialing over the tunnel. The reason I was asking about a new AVP is to determine the possibility of the LNS to use RIP/OSPF with the client once it finds out about this capability. If the client doesn't support it, it can be disabled on the link all together and save any bandwidth you may use for that purpose. There was also the indication that with SPAP you can request routing as well, I guess SPAP is not that bad after all! Thanks, Hany A. Ahmed Software Engineer Intel of Canada, Ltd. 2 Eva road , suite 220 Toronto, ON 416-622-8930 Hany.Ahmed@intel.com > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: Tuesday, November 21, 2000 11:15 AM > To: Ahmed, Hany > Cc: l2tp@ipsec.org > Subject: Re: l2TP with dynamic routing. > > > Ahmed, Hany writes: > > I was just wondering about the possibilty of using dynamic > routing protocols > > (RIP/OSPF etc..) through the L2TP tunnel to exchange > network topology > > information between the remote client and the LNS, > > If you're running IP over that PPP link then, yes, you can run routing > protocols. > > > is there any related > > draft to address any problems or concerns. > > Such as what? Is this different from a routing protocol over any > other kind of point-to-point link? > > On-demand and bandwidth-limited links have special problems; those are > addressed in the many RFCs dealing with such situations, such as > Triggered RIP (RFC 2091). > > > Is there also any new AVP that indicates the ability of the > remote end to > > accept > > certain routing protocols ? > > I don't see why you'd want that. If you had just PPP over a direct > serial link, how would you detect that the peer supports a routing > protocol? Doesn't that same method work here? > > -- > James Carlson, Internet Engineering > > SUN Microsystems / 1 Network Drive 71.234W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > 781 442 1677 > Second Edition now available - > http://people.ne.mediaone.net/carlson/ppp > From owner-l2tp@diameter.org Tue Nov 21 13:34:58 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01568 for ; Tue, 21 Nov 2000 13:34:57 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALHl2Z19361 for l2tp-list; Tue, 21 Nov 2000 09:47:02 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALHkvH19351 for ; Tue, 21 Nov 2000 09:46:57 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id IAA04270 for ; Tue, 21 Nov 2000 08:53:45 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00492; Tue, 21 Nov 2000 08:52:02 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA01378; Tue, 21 Nov 2000 11:51:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eALGpx5145100; Tue, 21 Nov 2000 11:51:59 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.43055.284425.83736@gargle.gargle.HOWL> Date: Tue, 21 Nov 2000 11:51:59 -0500 (EST) From: James Carlson To: "Ahmed, Hany" Cc: l2tp@ipsec.org Subject: RE: l2TP with dynamic routing. In-Reply-To: Ahmed, Hany's message of 21 November 2000 08:39:18 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Ahmed, Hany writes: > The reason I was asking about a new AVP is to determine > the possibility of the LNS to use RIP/OSPF with the client > once it finds out about this capability. My point is that if this is a real problem, then L2TP isn't the right place to solve it. It's a general problem with links. > If the client doesn't support it, it can be disabled on > the link all together and save any bandwidth you may use > for that purpose. Are you authenticating the peer at all? If you are, then you can key preferences -- such as desired routing protocol, filters, compression protocols, and other options -- off of the authenticated peer name. There's no reason to negotiate these. If you're not authenticating, then you do have to use heuristics. For OSPF or IS-IS, it's easy. Send a few Hellos, and if you don't hear any back by RouterDeadInterval, then just stop. For RIP, it's only a little harder. Send a few Response messages to make sure that silent peers get the right data (two or three packets aren't going to hurt anyone, and there's no compelling need to optimize that). If you don't get an ICMP Port Unreachable (telling you immediately that the peer isn't running RIP), then send a Query to see if the peer is running RIP. (I'm not sure I would bother with this on bandwidth grounds. One small packet every 30 seconds has no real effect. I would do it, though, if it caused inactivity timer problems.) > There was also the indication that with SPAP you can request > routing as well, I guess SPAP is not that bad after all! If that's true about SPAP (I have no documentation on the protocol), then that's yet another design flaw. Link layer authentication protocols have no business negotiating network layer attributes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Tue Nov 21 15:54:53 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27533 for ; Tue, 21 Nov 2000 15:54:51 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALJkrC19747 for l2tp-list; Tue, 21 Nov 2000 11:46:53 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALJkkH19741 for ; Tue, 21 Nov 2000 11:46:46 -0800 Received: from fcs-nt1.futsoft.com (fcs-nt1.futsoft.com [38.242.189.2]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id KAA04391 for ; Tue, 21 Nov 2000 10:53:34 -0800 (PST) Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Tue, 21 Nov 2000 10:30:55 -0800 Received: from rajeshs ([38.242.189.59]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id JAA02213 for ; Tue, 21 Nov 2000 09:33:44 -0800 Received: by localhost with Microsoft MAPI; Tue, 21 Nov 2000 11:14:18 -0800 Message-Id: <01C053AC.30B19A80.rajeshs@futsoft.com> From: Rajesh Kumar Reply-To: "rajeshs@futsoft.com" To: "l2tp@ipsec.org" Subject: RE: l2TP with dynamic routing. Date: Tue, 21 Nov 2000 11:14:17 -0800 Organization: Future Communications Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit IMHO - to run routing protocols over a tunnel, an IpSec (or an Ip-in-Ip tunnel if security is not a need) tunnel would be a better choice than L2tp because of the lesser overhead. Probably also less complex? Rajesh -----Original Message----- From: James Carlson [SMTP:james.d.carlson@east.sun.com] Sent: Tuesday, November 21, 2000 8:52 AM To: Ahmed, Hany Cc: l2tp@ipsec.org Subject: RE: l2TP with dynamic routing. Ahmed, Hany writes: > The reason I was asking about a new AVP is to determine > the possibility of the LNS to use RIP/OSPF with the client > once it finds out about this capability. My point is that if this is a real problem, then L2TP isn't the right place to solve it. It's a general problem with links. > If the client doesn't support it, it can be disabled on > the link all together and save any bandwidth you may use > for that purpose. Are you authenticating the peer at all? If you are, then you can key preferences -- such as desired routing protocol, filters, compression protocols, and other options -- off of the authenticated peer name. There's no reason to negotiate these. If you're not authenticating, then you do have to use heuristics. For OSPF or IS-IS, it's easy. Send a few Hellos, and if you don't hear any back by RouterDeadInterval, then just stop. For RIP, it's only a little harder. Send a few Response messages to make sure that silent peers get the right data (two or three packets aren't going to hurt anyone, and there's no compelling need to optimize that). If you don't get an ICMP Port Unreachable (telling you immediately that the peer isn't running RIP), then send a Query to see if the peer is running RIP. (I'm not sure I would bother with this on bandwidth grounds. One small packet every 30 seconds has no real effect. I would do it, though, if it caused inactivity timer problems.) > There was also the indication that with SPAP you can request > routing as well, I guess SPAP is not that bad after all! If that's true about SPAP (I have no documentation on the protocol), then that's yet another design flaw. Link layer authentication protocols have no business negotiating network layer attributes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Tue Nov 21 17:21:01 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14970 for ; Tue, 21 Nov 2000 17:21:00 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALKmlH19847 for l2tp-list; Tue, 21 Nov 2000 12:48:47 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALKmgH19841 for ; Tue, 21 Nov 2000 12:48:42 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id LAA04480 for ; Tue, 21 Nov 2000 11:55:31 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17044; Tue, 21 Nov 2000 11:55:22 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25738; Tue, 21 Nov 2000 14:55:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id eALJtT2145349; Tue, 21 Nov 2000 14:55:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.54064.783732.618239@gargle.gargle.HOWL> Date: Tue, 21 Nov 2000 14:55:28 -0500 (EST) From: James Carlson To: "rajeshs@futsoft.com" Cc: "l2tp@ipsec.org" Subject: RE: l2TP with dynamic routing. In-Reply-To: Rajesh Kumar's message of 21 November 2000 11:14:17 References: <01C053AC.30B19A80.rajeshs@futsoft.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Rajesh Kumar writes: > IMHO - to run routing protocols over a tunnel, an IpSec > (or an Ip-in-Ip tunnel if security is not a need) tunnel would > be a better choice than L2tp because of the lesser > overhead. Probably also less complex? How can whether you're running a routing protocol possibly affect whether you use IPSec or IP/PPP/L2TP? Routing sees these things as point-to-point links. It doesn't care how or why they're point-to-point. In turn, IPSec and IP/PPP/L2TP see routing packets as just IP packets. They don't care what the packets carry. Sure, IP-IP tunneling has less overhead than L2TP on IP. So what? That's not necessarily the reason you choose one or the other. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-l2tp@diameter.org Tue Nov 21 18:43:09 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26161 for ; Tue, 21 Nov 2000 18:43:05 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eALM2ZM19998 for l2tp-list; Tue, 21 Nov 2000 14:02:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eALM2SH19992 for ; Tue, 21 Nov 2000 14:02:28 -0800 Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id NAA04545 for ; Tue, 21 Nov 2000 13:09:16 -0800 (PST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id VAA03175 for ; Tue, 21 Nov 2000 21:09:02 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 21:09:01 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 13:09:00 -0800 Message-ID: From: "Ahmed, Hany" To: l2tp@ipsec.org Subject: RE: l2TP with dynamic routing. Date: Tue, 21 Nov 2000 13:08:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk But IPSEC is not a good protocol when it comes to tunneling, you have even a harder problem when you negotiate IPSEC. When you agree on a certain parameters and subnets during negotiation you'll have to stick with that for the rest of the tunnel, if you happen to learn another subnet and you want to reach it then you have to negotiate another SA to support this new traffic. So IPSEC by itself is not good enough, IP in IP is simple but you cannot do much with it since it has no such things as authentication/authorization or dynamic address assignment. Regards, Hany A. Ahmed Software Engineer Intel of Canada, Ltd. 2 Eva road , suite 220 Toronto, ON 416-622-8930 Hany.Ahmed@intel.com > -----Original Message----- > From: Rajesh Kumar [mailto:rajeshs@futsoft.com] > Sent: Tuesday, November 21, 2000 2:14 PM > To: l2tp@ipsec.org > Subject: RE: l2TP with dynamic routing. > > > IMHO - to run routing protocols over a tunnel, an IpSec > (or an Ip-in-Ip tunnel if security is not a need) tunnel would > be a better choice than L2tp because of the lesser > overhead. Probably also less complex? > > Rajesh > From owner-l2tp@diameter.org Thu Nov 23 21:06:15 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16234 for ; Thu, 23 Nov 2000 21:06:15 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAO1HdG23266 for l2tp-list; Thu, 23 Nov 2000 17:17:39 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAO1GKH23260 for ; Thu, 23 Nov 2000 17:16:20 -0800 Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id QAA09408 for ; Thu, 23 Nov 2000 16:23:14 -0800 (PST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id QAA31801; Thu, 23 Nov 2000 16:23:11 -0800 (PST) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA02570; Thu, 23 Nov 00 16:46:43 -0800 From: "Bernard Aboba" To: , Subject: RE: l2TP with dynamic routing. Date: Thu, 23 Nov 2000 16:07:16 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <01C053AC.30B19A80.rajeshs@futsoft.com> Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit >IMHO - to run routing protocols over a tunnel, an IpSec >(or an Ip-in-Ip tunnel if security is not a need) tunnel would >be a better choice than L2tp because of the lesser >overhead. Probably also less complex? Unfortunately, most IPSEC tunnel mode implementations do not support multicast, which is required by IGPs. So in practice, with IPSEC tunnel mode, we see use of BGP or static routing only. Since this is not an issue with L2TP/IPSEC (or GRE with or without IPSEC, for that matter), these protocols are preferred for use with IGPs. From owner-l2tp@diameter.org Fri Nov 24 01:48:15 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18255 for ; Fri, 24 Nov 2000 01:48:11 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAO5QAo23538 for l2tp-list; Thu, 23 Nov 2000 21:26:10 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAO5Q1H23532 for ; Thu, 23 Nov 2000 21:26:01 -0800 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id UAA09533 for ; Thu, 23 Nov 2000 20:32:57 -0800 (PST) Received: from cisco.com (rtp-dial-1-92.cisco.com [10.83.97.92]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA11864; Thu, 23 Nov 2000 20:31:47 -0800 (PST) Message-ID: <3A1DEE55.ACCF18C6@cisco.com> Date: Thu, 23 Nov 2000 23:28:05 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vipin Jain CC: "'zong.zaifeng@mail.zte.com.cn'" , l2tp@ipsec.org, evan@acc.com Subject: Re: (Reply) Question about session establishment References: <940E42DB5D7FD4119C420004ACE6E0A03414FE@mailserver.shastanets.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit In most cases, sending packets right away will do no harm. However, the problem with NOT waiting is that, in a few identifiable cases, dropping the first few packets sent to the LNS can be fairly detrimental. This is an unfortunate reality due to the dropping of IPCP options in retransmitted IPCP Conf Reqs of a very popular PPP implementation. This unfortunate reality makes the first couple of IPCP packets sent by this particular implementation very important. If Proxy LCP is performed and no authentication negotiated at the LAC (perhaps some previous authentication occurred, this is a default tunnel endpoint, etc) then the PPP peer connected to the LAC will be sending IPCP packets right away as it will not be waiting on an authentication response from the LNS. If these IPCP packets are dropped due to the ICCN not reaching the LNS beforehand, or the PPP state machine at the LNS has not been initialized yet, then it could drop these very first, very important IPCP packets from the popular yet misbehaving PPP implementation described above. To handle this situation in a robust manner, a well-informed PPP implementation at an LAC must queue these IPCP packets as they arrive before the L2TP session is established. Rather than force the LNS to do the same, it would be better to wait until the ICCN is acknowledged if it is carrying Proxy LCP information and no authentication was negotiated. - Mark Vipin Jain wrote: > > If LAC waits for Ack from LNS, what would it do with the data packets LNS > might have sent before it sent ZLB Ack? Given the fact that ZLB Ack could be > delayed, where as ICCN isn't. > Assuming most of the times ICCN will get to LNS, it would be more efficient > to assume tunnel in established when ICCN is sent and not wait for ZLB Ack. > > -- vipin > > -----Original Message----- > From: zong.zaifeng@mail.zte.com.cn [mailto:zong.zaifeng@mail.zte.com.cn] > Sent: Wednesday, November 08, 2000 11:34 PM > To: l2tp@ipsec.org; evan@acc.com > Subject: Re: (Reply) Question about session establishment > > But if the ICCN was lost and need to be retransmitted, the LAC has entered > established > state but the LNS still hasn't. During the period of retransmitting ICCN, > data > packets > maybe send to LNS, how will LNS handle this data packets? because the > session in > LNS still hasn't established, so it maybe ignore these packets. Do you think > this case > isn't important? > > No. The session FSM steps immediately to "established" after sending the > ICCN. > > evan > - > > sudheer@samsung.co.kr wrote: > > > > Hi, > > > > The Session state moves to the Established state after receiving the ZLB > corresponding to the ICCN sent. > > > > Sudheer. > > > > Hello, > > > > I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there > is a > > LAC Incoming Call States table, I want to ask is that when will the state > go > to > > established state? After sending ICCN or after sending ICCN and receiving > > acknowledgement correspond to this ICCN(e.g.a ZLB)? > > > > TIA > > > > ZZF From owner-l2tp@diameter.org Fri Nov 24 02:01:21 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26571 for ; Fri, 24 Nov 2000 02:01:20 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAO5l5m23564 for l2tp-list; Thu, 23 Nov 2000 21:47:05 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAO5klH23558 for ; Thu, 23 Nov 2000 21:46:47 -0800 Received: from cisco.com (rtp-dial-1-92.cisco.com [10.83.97.92]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA12012 for ; Thu, 23 Nov 2000 20:53:39 -0800 (PST) Message-ID: <3A1DF375.A2074B64@cisco.com> Date: Thu, 23 Nov 2000 23:49:57 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: l2tp@l2tp.net Subject: Call for L2TPEXT Agenda Items for the 49th IETF in San Diego, CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit We are currently scheduled to meet 1300-1500, Afternoon Sessions I, on THURSDAY, December 14, 2000. Please send me requests to make presentations. Be sure to include all of the below: 1) Name of presenter, including e-mail address 2) Title of presentation 3) Internet draft name, if applicable 4) Amount of time requested Thanks, - Mark From owner-l2tp@diameter.org Fri Nov 24 03:41:34 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06600 for ; Fri, 24 Nov 2000 03:41:22 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAO7Ii723710 for l2tp-list; Thu, 23 Nov 2000 23:18:44 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAO7IIH23700 for ; Thu, 23 Nov 2000 23:18:18 -0800 Received: from iwan-view6.cisco.com (iwan-view6.cisco.com [171.69.24.141]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA11195; Thu, 23 Nov 2000 22:24:42 -0800 (PST) Date: Thu, 23 Nov 2000 22:24:37 -0800 (PST) From: William Mark Townsley To: internet-drafts@ietf.org cc: l2tp@l2tp.net Subject: Please post draft-ietf-l2tpext-l2tpbis-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk Network Working Group W. Townsley Internet-Draft A. Valencia Category: Standards Track G. Zorn cisco Systems A. Rubens Tut Systems G. Pall Microsoft Corporation B. Palter Redback Networks November 2000 Layer Two Tunneling Protocol "L2TP" Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as and expires May 31, 2001. Please send comments to the L2TP mailing list (l2tp@l2tp.net). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes the Layer Two Tunneling Protocol (L2TP). RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP Townsley, et al. Standards Track [Page 1] INTERNET DRAFT L2TP November 2000 facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications. Townsley, et al. Standards Track [Page 2] INTERNET DRAFT L2TP November 2000 Contents Status of this Memo.......................................... 1 1.0 Introduction.......................................... 4 1.1 Specification of Requirements......................... 5 1.2 Terminology........................................... 5 2.0 Topology.............................................. 8 3.0 Protocol Overview..................................... 9 3.1 L2TP Header Format.................................... 10 3.2 Control Message Types................................. 12 4.0 Control Message Attribute Value Pairs................. 13 4.1 AVP Format............................................ 13 4.2 Mandatory AVPs........................................ 15 4.3 Hiding of AVP Attribute Values........................ 15 4.4 AVP Summary........................................... 17 5.0 Protocol Operation.................................... 42 5.1 Control Connection Establishment...................... 42 5.2 Session Establishment................................. 43 5.3 Forwarding PPP Frames................................. 44 5.4 Using Sequence Numbers on the Data Channel............ 45 5.5 Keepalive (Hello)..................................... 45 5.6 Session Teardown...................................... 46 5.7 Control Connection Teardown........................... 46 5.8 Reliable Delivery of Control Messages................. 47 6.0 Control Connection Protocol Specification............. 49 6.1 Start-Control-Connection-Request (SCCRQ).............. 49 6.2 Start-Control-Connection-Reply (SCCRP)................ 49 6.3 Start-Control-Connection-Connected (SCCCN)............ 50 6.4 Stop-Control-Connection-Notification (StopCCN)........ 50 6.5 Hello (HELLO)......................................... 50 6.6 Incoming-Call-Request (ICRQ).......................... 51 6.7 Incoming-Call-Reply (ICRP)............................ 52 6.8 Incoming-Call-Connected (ICCN)........................ 52 6.9 Outgoing-Call-Request (OCRQ).......................... 53 6.10 Outgoing-Call-Reply (OCRP)........................... 54 6.11 Outgoing-Call-Connected (OCCN)....................... 54 6.12 Call-Disconnect-Notify (CDN)......................... 54 6.13 WAN-Error-Notify (WEN)............................... 55 6.14 Set-Link-Info (SLI).................................. 55 7.0 Control Connection State Machines..................... 56 7.1 Control Connection Protocol Operation................. 56 7.2 Control Connection States............................. 57 7.2.1 Control Connection Establishment................. 57 7.3 Timing considerations................................. 59 7.4 Incoming calls........................................ 59 7.4.1 LAC Incoming Call States......................... 60 7.4.2 LNS Incoming Call States......................... 62 7.5 Outgoing calls........................................ 63 Townsley, et al. Standards Track [Page 3] INTERNET DRAFT L2TP November 2000 7.5.1 LAC Outgoing Call States......................... 63 7.5.2 LNS Outgoing Call States......................... 64 7.6 Tunnel Disconnection.................................. 66 8.0 L2TP Over Specific Media.............................. 66 8.1 L2TP over UDP/IP...................................... 66 8.2 IP.................................................... 68 9.0 Security Considerations............................... 68 9.1 Tunnel Endpoint Security.............................. 68 9.2 Packet Level Security................................. 69 9.3 End to End Security................................... 69 9.4 L2TP and IPsec........................................ 69 9.5 Proxy PPP Authentication.............................. 70 10.0 IANA Considerations.................................. 70 10.1 AVP Attributes....................................... 70 10.2 Message Type AVP Values.............................. 70 10.3 Result Code AVP Values............................... 70 10.3.1 Result Code Field Values........................ 71 10.3.2 Error Code Field Values......................... 71 10.4 Framing Capabilities & Bearer Capabilities........... 71 10.5 Proxy Authen Type AVP Values......................... 71 10.6 AVP Header Bits...................................... 71 11.0 References........................................... 71 12.0 Acknowledgments...................................... 73 13.0 Authors' Addresses................................... 73 Appendix A: Control Channel Slow Start and Congestion Avoidance 74 Appendix B: Control Message Examples......................... 75 Appendix C: Intellectual Property Notice..................... 76 1.0 Introduction The Layer Two Tunneling Protocol (L2TP) provides a mechanism for aggregation of multiple layer two connections across packet oriented data networks. These layer two connections may be PPP [RFC1661] or other layer two connections such as Frame Relay, ATM, etc. This document defines the specific mechanisms for tunneling of PPP, including a control protocol for on-demand creation of tunnels between nodes and the accompanying encapsulation for multiplexing multiple, tunneled, PPP sessions. The specifics of tunneling layer 2 links other than PPP with L2TP will be defined separately. PPP defines an encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, ADSL, etc.) and then runs PPP over that connection. In such a configuration, the L2 Townsley, et al. Standards Track [Page 4] INTERNET DRAFT L2TP November 2000 termination point and PPP session endpoint reside on the same physical device (i.e., the NAS). L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched network. With L2TP, a user has an L2 connection to an access concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the NAS. This allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit. One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require a long- distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over a shared infrastructure such as a frame relay circuit or the Internet. From the user's perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP. L2TP may also solve the multilink hunt-group splitting problem. Multilink PPP [RFC1990] requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Due to its ability to project a PPP session to a location other than the point at which it was physically received, L2TP can be used to make all channels terminate at a single NAS. This allows multilink operation even when the calls are spread across distinct physical NASs. 1.1 Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Terminology Analog Channel A circuit-switched communication path which is intended to carry 3.1 kHz audio in each direction. Attribute Value Pair (AVP) The variable length concatenation of a unique Attribute (represented by an integer) and a Value containing the actual value identified by the attribute. Multiple AVPs make up Control Messages which are used in the establishment, maintenance, and Townsley, et al. Standards Track [Page 5] INTERNET DRAFT L2TP November 2000 teardown of tunnels. Call A connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call (Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Session within a previously established Tunnel between the LAC and LNS. (See also: Session, Incoming Call, Outgoing Call). Called Number An indication to the receiver of a call as to what telephone number the caller used to reach it. Calling Number An indication to the receiver of a call as to the telephone number of the caller. CHAP Challenge Handshake Authentication Protocol [RFC1994], a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line. Control Connection A control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself. Control Messages Control messages are exchanged between LAC and LNS pairs, operating in-band within the tunnel protocol. Control messages govern aspects of the tunnel and sessions within the tunnel. Digital Channel A circuit-switched communication path which is intended to carry digital information in each direction. DSLAM Digital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator Townsley, et al. Standards Track [Page 6] INTERNET DRAFT L2TP November 2000 of individual DSL lines located in a central office (CO) or local exchange. Incoming Call A Call received at an LAC to be tunneled to an LNS (see Call, Outgoing Call). L2TP Access Concentrator (LAC) A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Network Server (LNS). The LAC sits between an LNS and a remote system and forwards packets to and from each. Packets sent from the LAC to the LNS requires tunneling with the L2TP protocol as defined in this document. The connection from the LAC to the remote system is either local (see: Client LAC) or a PPP link. L2TP Network Server (LNS) A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Access Concentrator (LAC). The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC. Management Domain (MD) A network or networks under the control of a single administration, policy or system. For example, an LNS's Management Domain might be the corporate network it serves. An LAC's Management Domain might be the Internet Service Provider that owns and manages it. Network Access Server (NAS) A device providing local network access to users across a remote access network such as the PSTN. An NAS may also serve as an LAC, LNS or both. Outgoing Call A Call placed by an LAC on behalf of an LNS (see Call, Incoming Call). Peer When used in context with L2TP, peer refers to either the LAC or LNS. An LAC's Peer is an LNS and vice versa. When used in context Townsley, et al. Standards Track [Page 7] INTERNET DRAFT L2TP November 2000 with PPP, a peer is either side of the PPP connection. POTS Plain Old Telephone Service. Remote System An end-system or router attached to a remote access network (i.e. a PSTN), which is either the initiator or recipient of a call. Also referred to as a dial-up or virtual dial-up client. Session L2TP is connection-oriented. The LNS and LAC maintain state for each Call that is initiated or answered by an LAC. An L2TP Session is created between the LAC and LNS when an end-to-end PPP connection is established between a Remote System and the LNS. Datagrams related to the PPP connection are sent over the Tunnel between the LAC and LNS. There is a one to one relationship between established L2TP Sessions and their associated Calls. (See also: Call). Tunnel A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a Control Connection and zero or more L2TP Sessions. The Tunnel carries encapsulated PPP datagrams and Control Messages between the LAC and the LNS. Zero-Length Body (ZLB) Message A control packet with only an L2TP header. ZLB messages are used for explicitly acknowledging packets on the reliable control channel. 2.0 Topology The following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN. Townsley, et al. Standards Track [Page 8] INTERNET DRAFT L2TP November 2000 [Home LAN] [LAC Client]----------+ | ____|_____ +--[Host] | | | [LAC]---------| Internet |-----[LNS]-----+ | |__________| | _____|_____ : | | | PSTN | [Remote]--| Cloud | [System] | | [Home LAN] |___________| | | ______________ +---[Host] | | | | [LAC]-------| Frame Relay |---[LNS]-----+ | or ATM Cloud | | |______________| : The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is obtained. The Remote System is provided addresses from the HOME LAN via PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN's Management Domain as if the user were connected to a Network Access Server directly. A LAC Client (a Host which runs L2TP natively) may also participate in tunneling to the Home LAN without use of a separate LAC. In this case, the Host containing the LAC Client software already has a connection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel to the LNS. As in the above case, Addressing, Authentication, Authorization and Accounting will be provided by the Home LAN's Management Domain. 3.0 Protocol Overview L2TP utilizes two types of messages, control messages and data messages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames being carried over the tunnel. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are not retransmitted when packet loss occurs. Townsley, et al. Standards Track [Page 9] INTERNET DRAFT L2TP November 2000 +-------------------+ | PPP Frames | +-------------------+ +-----------------------+ | L2TP Data Messages| | L2TP Control Messages | +-------------------+ +-----------------------+ | L2TP Data Channel | | L2TP Control Channel | | (unreliable) | | (reliable) | +------------------------------------------------+ | Packet Transport (UDP, FR, ATM, etc.) | +------------------------------------------------+ Figure 3.0 L2TP Protocol Structure Figure 3.0 depicts the relationship of PPP frames and Control Messages over the L2TP Control and Data Channels. PPP Frames are passed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM, etc. Control messages are sent over a reliable L2TP Control Channel which transmits packets in-band over the same Packet Transport. Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the Control Channel. Data Messages may use sequence numbers to reorder packets and detect lost packets. All values are placed into their respective fields and sent in network order (high order octets first). 3.1 L2TP Header Format L2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Note that while optional on data messages, the Length, Ns, and Nr fields marked as optional below, are required to be present on all control messages. This header is formatted: Townsley, et al. Standards Track [Page 10] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.1 L2TP Message Header The Type (T) bit indicates the type of message. It is set to 0 for a data message and 1 for a control message. If the Length (L) bit is 1, the Length field is present. This bit MUST be set to 1 for control messages. The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages. If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages. If the Offset (O) bit is 1, the Offset Size field is present. The O bit MUST be set to 0 (zero) for control messages. If the Priority (P) bit is 1, this data message should receive preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporary interval of local congestion could result in interference with keepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit MUST be set to 0 for all control messages. Ver MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved to permit detection of L2F [RFC2341] packets should they arrive intermixed with L2TP packets. Packets received with an unknown Ver field MUST be discarded. The Length field indicates the total length of the message in octets. Tunnel ID indicates the identifier for the control connection. L2TP tunnels are named by identifiers that have local significance only. Townsley, et al. Standards Track [Page 11] INTERNET DRAFT L2TP November 2000 That is, the same tunnel will be given different Tunnel IDs by each end of the tunnel. Tunnel ID in each message is that of the intended recipient, not the sender. Tunnel IDs are selected and exchanged as Assigned Tunnel ID AVPs during the creation of a tunnel. Session ID indicates the identifier for a session within a tunnel. L2TP sessions are named by identifiers that have local significance only. That is, the same session will be given different Session IDs by each end of the session. Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected and exchanged as Assigned Session ID AVPs during the creation of a session. Ns indicates the sequence number for this data or control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See section 5.8 and 5.4 for more information on using this field. Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). In data messages, Nr is reserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using this field in control messages. The Offset Size field specifies the number of octets past the L2TP header at which the payload data is expected to start. If the offset field is present, the L2TP header ends after the last octet of the offset padding. The offset field itself is considered part of the l2tp header, not part of the offset padding. Thus, an offset field with a value of zero will add two octets to the header length. Actual data within the offset padding is undefined. A recommended maximum for the offset value is 7, which allows for 8 octet alignment. 3.2 Control Message Types The Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1. This document defines the following control message types (see section 6.1 through 6.14 for details on the construction and use of each message): Control Connection Management Townsley, et al. Standards Track [Page 12] INTERNET DRAFT L2TP November 2000 0 (reserved) 1 (SCCRQ) Start-Control-Connection-Request 2 (SCCRP) Start-Control-Connection-Reply 3 (SCCCN) Start-Control-Connection-Connected 4 (StopCCN) Stop-Control-Connection-Notification 5 (reserved) 6 (HELLO) Hello Call Management 7 (OCRQ) Outgoing-Call-Request 8 (OCRP) Outgoing-Call-Reply 9 (OCCN) Outgoing-Call-Connected 10 (ICRQ) Incoming-Call-Request 11 (ICRP) Incoming-Call-Reply 12 (ICCN) Incoming-Call-Connected 13 (reserved) 14 (CDN) Call-Disconnect-Notify Error Reporting 15 (WEN) WAN-Error-Notify PPP Session Control 16 (SLI) Set-Link-Info 4.0 Control Message Attribute Value Pairs To maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is used throughout L2TP. This encoding will be termed AVP (Attribute-Value Pair) in the remainder of this document. 4.1 AVP Format Each AVP is encoded as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Attribute Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [until Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Townsley, et al. Standards Track [Page 13] INTERNET DRAFT L2TP November 2000 The first six bits are a bit mask, describing the general attributes of the AVP. Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP. Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associated with a particular session, the session associated with this message MUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must then continue to be processed as if the AVP had not been present. Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. section 4.3 describes the procedure for performing AVP hiding. Length: Encodes the number of octets (including the Overall Length and bitmask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the length is 6, then the Attribute Value field is absent. Vendor ID: The IANA assigned "SMI Network Management Private Enterprise Codes" [RFC1700] value. The value 0, corresponding to IETF adopted attribute values, is used for all AVPs defined within this document. Any vendor wishing to implement their own L2TP extensions can use their own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions, nor with future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this feature to the first 65,535 enterprises. Attribute Type: A 2 octet value with a unique interpretation across all AVPs defined under a given Vendor ID. Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the Attribute Type field, and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6. Townsley, et al. Standards Track [Page 14] INTERNET DRAFT L2TP November 2000 4.2 Mandatory AVPs Receipt of an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it is associated with. Thus, the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Further, in the case where the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility of the peer sending the Mandatory AVP to accept fault for causing an non-interoperable situation. Before defining an AVP with the M-bit set, particularly a vendor-specific AVP, be sure that this is the intended consequence. When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M- bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message. Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set. 4.3 Hiding of AVP Attribute Values The H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in cleartext. This feature can be used to hide sensitive control message data such as user passwords or user IDs. The H bit MUST only be set if a shared secret exists between the LAC and LNS and tunnel authentication has completed. The shared secret is the same secret that is used for tunnel authentication (see section 5.1.1). Hidden values MUST NOT be unhidden until after tunnel authentication has completed successfully (perhaps requiring the hidden value to be stored until after receipt of additional setup messages). To do otherwise runs the risk of AVP data being utilized without verifying the integrity of the shared secret. If the H bit is set in any AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1. Hiding an AVP value is done in several steps. The first step is to take the length and value fields of the original (cleartext) AVP and encode them into a Hidden AVP Subformat as follows: Townsley, et al. Standards Track [Page 15] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Original Value | Original Attribute Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Padding ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Original Attribute Value: This is length of the Original Attribute Value to be obscured in octets. This is necessary to determine the original length of the Attribute Value which is lost when the additional Padding is added. Original Attribute Value: Attribute Value that is to be obscured. Padding: Random additional octets used to obscure length of the Attribute Value that is being hidden. To mask the size of the data being hidden, the resulting subformat MAY be padded as shown above. Padding does NOT alter the value placed in the Length of Original Attribute Value field, but does alter the length of the resultant AVP that is being created. For example, If an Attribute Value to be hidden is 4 octets in length, the unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the length of the AVP will become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 octets. Next, An MD5 hash is performed on the concatenation of: + the 2 octet Attribute number of the AVP + the shared secret + an arbitrary length random vector The value of the random vector used in this hash is passed in the value field of a Random Vector AVP. This Random Vector AVP must be placed in the message by the sender before any hidden AVPs. The same random vector may be used for more than one hidden AVP in the same message. If a different random vector is used for the hiding of subsequent AVPs then a new Random Vector AVP must be placed in the command message before the first AVP to which it applies. The MD5 hash value is then XORed with the first 16 octet (or less) segment of the Hidden AVP Subformat and placed in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the Attribute Value field had been padded to 16 octets before the XOR, but only the actual Townsley, et al. Standards Track [Page 16] INTERNET DRAFT L2TP November 2000 octets present in the Subformat are modified, and the length of the AVP is not altered. If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP. If necessary, this operation is repeated, with the shared secret used along with each XOR result to generate the next hash to XOR the next segment of the value with. The hiding method was adapted from RFC 2138 [RFC2138] which was taken from the "Mixing in the Plaintext" section in the book "Network Security" by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of the method follows: Call the shared secret S, the Random Vector RV, and the Attribute Value AV. Break the value field into 16-octet chunks p1, p2, etc. with the last one padded at the end with random data to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We will also define intermediate values b1, b2, etc. b1 = MD5(AV + S + RV) c(1) = p1 xor b1 b2 = MD5(S + c(1)) c(2) = p2 xor b2 . . . . . . bi = MD5(S + c(i-1)) c(i) = pi xor bi The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation. On receipt, the random vector is taken from the last Random Vector AVP encountered in the message prior to the AVP to be unhidden. The above process is then reversed to yield the original value. 4.4 AVP Summary The following sections contain a list of all L2TP AVPs defined in this document. Following the name of the AVP is a list indicating the message types that utilize each AVP. After each AVP title follows a short description of the purpose of the AVP, a detail (including a graphic) of the format for the Attribute Value, and any additional information needed for proper use of the AVP. Townsley, et al. Standards Track [Page 17] INTERNET DRAFT L2TP November 2000 4.4.1 AVPs Applicable To All Control Messages Message Type (All Messages) The Message Type AVP, Attribute Type 0, identifies the control message herein and defines the context in which the exact meaning of the following AVPs will be determined. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type is a 2 octet unsigned integer. The Message Type AVP MUST be the first AVP in a message, immediately following the control message header (defined in section 3.1). See section 3.2 for the list of defined control message types and their identifiers. The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication as to whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. Thus, if the M-bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the tunnel MUST be cleared. If the M-bit is not set, then the implementation may ignore an unknown message type. The M-bit MUST be set to 1 for all message types defined in this document. This AVP may not be hidden (the H-bit MUST be 0). The Length of this AVP is 8. A Vendor Specific control message may be defined by setting the Vendor ID of the Message Type AVP to a value other than the IETF Vendor ID of 0 (see section 4.1). Random Vector (All Messages) The Random Vector AVP, Attribute Type 36, is used to enable the hiding of the Attribute Value of arbitrary AVPs. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 18] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Octet String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Random Octet String may be of arbitrary length, although a random vector of at least 16 octets is recommended. The string contains the random vector for use in computing the MD5 hash to retrieve or hide the Attribute Value of a hidden AVP (see section 4.3). More than one Random Vector AVP may appear in a message, in which case a hidden AVP uses the Random Vector AVP most closely preceding it. This AVP MUST precede the first AVP with the H bit set. The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the length of the Random Octet String. 4.4.2 Result and Error Codes Result Code (CDN, StopCCN) The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control channel or session. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | Error Code (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (opt) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code is a 2 octet unsigned integer. The optional Error Code is a 2 octet unsigned integer. An optional Error Message can follow the Error Code field. Presence of the Error Code and Message are indicated by the AVP Length field. The Error Message contains an arbitrary string providing further (human readable) text associated with the condition. Human readable text in all error messages MUST be provided in the UTF-8 charset using the Default Language [RFC2277]. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for Townsley, et al. Standards Track [Page 19] INTERNET DRAFT L2TP November 2000 this AVP MUST be set to 1. The Length is 8 if there is no Error Code or Message, 10 if there is an Error Code and no Error Message or 10 + the length of the Error Message if there is an Error Code and Message. Defined Result Code values for the StopCCN message are: 0 - Reserved 1 - General request to clear control connection 2 - General error, Error Code indicates the problem 3 - Control channel already exists 4 - Requester is not authorized to establish a control channel 5 - The protocol version of the requester is not supported, Error Code indicates highest version supported 6 - Requester is being shut down 7 - Finite State Machine error Defined Result Code values for the CDN message are: 0 - Reserved 1 - Call disconnected due to loss of carrier 2 - Call disconnected for the reason indicated in Error Code 3 - Call disconnected for administrative reasons 4 - Call failed due to lack of appropriate facilities being available (temporary condition) 5 - Call failed due to lack of appropriate facilities being available (permanent condition) 6 - Invalid destination 7 - Call failed due to no carrier detected 8 - Call failed due to detection of a busy signal 9 - Call failed due to lack of a dial tone 10 - Call was not established within time allotted 11 - Call was connected but no appropriate framing was detected The Error Codes defined below pertain to types of errors that are not specific to any particular L2TP request, but rather to protocol or message format errors. If an L2TP reply indicates in its Result Code that a general error occurred, the General Error value should be examined to determine what the error was. The currently defined General Error codes and their meanings are: 0 - No general error 1 - No control connection exists yet for this LAC-LNS pair 2 - Length is wrong 3 - One of the field values was out of range or reserved field was non-zero 4 - Insufficient resources to handle this operation now Townsley, et al. Standards Track [Page 20] INTERNET DRAFT L2TP November 2000 5 - The Session ID is invalid in this context 6 - A generic vendor-specific error occurred 7 - Try another. If initiator is aware of other possible responder destinations, it should try one of them. This can be used to guide an LAC or LNS based on policy, for instance, the existence of multilink PPP bundles at an LNS. 8 - The session or tunnel was shutdown due to receipt of an unknown AVP with the M-bit set (see section 4.2). The Error Message SHOULD contain the attribute of the offending AVP in (human readable) text form. 9 - Try another directed. If an LAC or LNS is aware of other possible destinations, it should inform the initiator of the tunnel or session. The Error Message MUST contain a comma separated list of addresses for the initiator to choose from. If the L2TP transport is IPv4, then this would be a comma separated list of IP addresses in the canonical dotted-decimal format. i.e. "10.0.0.1, 10.0.0.2, 10.0.0.3" If there are no servers for the LAC or LNS to suggest, then Error Code 7 should be used. The delimiter between addresses MUST be precisely a single comma and a single space. When a General Error Code of 6 is used, additional information about the error SHOULD be included in the Error Message field. Further, a vendor specific AVP MAY be sent to indicate the problem more precisely. 4.4.3 Control Connection Management AVPs Protocol Version (SCCRP, SCCRQ) The Protocol Version AVP, Attribute Type 2, indicates the L2TP protocol version of the sender. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Rev | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Ver field is a 1 octet unsigned integer containing the value 1. Rev field is a 1 octet unsigned integer containing 0. This pertains to L2TP protocol version 1, revision 0. Note this is not the same version number that is included in the header of each message. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for Townsley, et al. Standards Track [Page 21] INTERNET DRAFT L2TP November 2000 this AVP MUST be set to 1. The Length of this AVP is 8. Framing Capabilities (SCCRP, SCCRQ) The Framing Capabilities AVP, Attribute Type 3, provides the peer with an indication of the types of framing that will be accepted or requested by the sender. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future framing type definitions |A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute Value field is a 32-bit mask, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. The framing capabilities defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Framing Type AVP specifying a value not advertised in this AVP. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10. Bearer Capabilities (SCCRP, SCCRQ) The Bearer Capabilities AVP, Attribute Type 4, provides the peer with an indication of the bearer device types supported by the hardware interfaces of the sender for outgoing calls. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future bearer type definitions |V|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is a 32-bit mask, with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported. Bit V is set, virtual access is supported. Virtual access refers to access where there is no physical point to point Townsley, et al. Standards Track [Page 22] INTERNET DRAFT L2TP November 2000 link. The framing capabilitiies defined in this AVP refer only to the physical interfaces available for dialout usage on an LAC. An LNS MUST not send an OCRQ with a Bearer Type AVP specifying a value not advertised in this AVP. This AVP MUST be present if the sender can place outgoing calls when requested. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10. Tie Breaker (SCCRQ) The Tie Breaker AVP, Attribute Type 5, indicates that the sender wishes a single tunnel to exist between the given LAC-LNS pair. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tie Break Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...(64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Tie Breaker Value is an 8 octet value that is used to choose a single tunnel where both LAC and LNS request a tunnel concurrently. The recipient of a SCCRQ must check to see if a SCCRQ has been sent to the peer, and if so, must compare its Tie Breaker value with the received one. The lower value "wins", and the "loser" MUST silently discard its tunnel. In the case where a tie breaker is present on both sides, and the value is equal, both sides MUST discard their tunnels. If a tie breaker is received, and an outstanding SCCRQ had no tie breaker value, the initiator which included the Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate tunnels are opened. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 0. The Length of this AVP is 14. Firmware Revision (SCCRP, SCCRQ) Townsley, et al. Standards Track [Page 23] INTERNET DRAFT L2TP November 2000 The Firmware Revision AVP, Attribute Type 6, indicates the firmware revision of the issuing device. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Firmware Revision is a 2 octet unsigned integer encoded in a vendor specific format. For devices which do not have a firmware revision (general purpose computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 8. Host Name (SCCRP, SCCRQ) The Host Name AVP, Attribute Type 7, indicates the name of the issuing LAC or LNS. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Name ... (arbitrary number of octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Host Name is of arbitrary length, but MUST be at least 1 octet. This name should be as broadly unique as possible; for hosts participating in DNS [RFC1034], a hostname with fully qualified domain would be appropriate. The Host Name MAY be used to identify tunnel configuration, including the shared secret for tunnel authentication (if enabled) and any other options defined for the tunnel. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6 plus the length of the Host Name. Townsley, et al. Standards Track [Page 24] INTERNET DRAFT L2TP November 2000 Vendor Name (SCCRP, SCCRQ) The Vendor Name AVP, Attribute Type 8, contains a vendor specific (possibly human readable) string describing the type of LAC or LNS being used. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Name ...(arbitrary number of octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor Name is the indicated number of octets representing the vendor string. Human readable text for this AVP MUST be provided in the UTF-8 charset using the Default Language [RFC2277]. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Vendor Name. Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN) The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being assigned to this tunnel by the sender. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Tunnel ID is a 2 octet non-zero unsigned integer. The Assigned Tunnel ID AVP establishes a value used to multiplex and demultiplex multiple tunnels between the LNS and LAC. The L2TP peer MUST place this value in the Tunnel ID header field of all control and data messages that it subsequently transmits over the associated tunnel. Before the Assigned Tunnel ID AVP is received from a peer, messages MUST be sent to that peer with a Tunnel ID value of 0 in the header of all control messages. In the StopCCN control message, the Assigned Tunnel ID AVP MUST be the same as the Assigned Tunnel ID AVP first sent to the receiving peer, permitting the peer to identify the appropriate tunnel even Townsley, et al. Standards Track [Page 25] INTERNET DRAFT L2TP November 2000 if a StopCCN is sent before an Assigned Tunnel ID AVP is received. If an Assigned Tunnel ID AVP has not been sent in a previous message, a tunnel ID SHOULD be allocated and sent via the Assigned Tunnel ID AVP so that the StopCCN may be reliably delivered. This is most important if the StopCCN carries an essential directive within, for instance, a Result Code of value 9 with an alternate address to attempt connecting to. If an Assigned Tunnel ID AVP is not sent in the StopCCN or any previous message, the StopCCN MUST NOT be retransmitted. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. Receive Window Size (SCCRQ, SCCRP) The Receive Window Size AVP, Attribute Type 10, specifies the receive window size being offered to the remote peer. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Window Size is a 2 octet unsigned integer. If absent, the peer must assume a Window Size of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8. Challenge (SCCRP, SCCRQ) The Challenge AVP, Attribute Type 11, indicates that the issuing peer wishes to authenticate the tunnel endpoints using a CHAP- style authentication mechanism. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 26] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge ... (arbitrary number of octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge is one or more octets of random data. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Challenge. Challenge Response (SCCCN, SCCRP) The Response AVP, Attribute Type 13, provides a response to a challenge received. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response is a 16 octet value reflecting the CHAP-style [RFC1994] response to the challenge. This AVP MUST be present in an SCCRP or SCCCN if a challenge was received in the preceding SCCRQ or SCCRP. For purposes of the ID value in the CHAP response calculation, the value of the Message Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for an SCCCN). This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 22. 4.4.4 Call Management AVPs Q.931 Cause Code (CDN) Townsley, et al. Standards Track [Page 27] INTERNET DRAFT L2TP November 2000 The Q.931 Cause Code AVP, Attribute Type 12, is used to give additional information in case of unsolicited call disconnection. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Msg | Advisory Msg... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code is the returned Q.931 Cause code, and Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings [DSS1]. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP Length) to further explain the reason for disconnecting. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 9, plus the size of the Advisory Message. Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ) The Assigned Session ID AVP, Attribute Type 14, encodes the ID being assigned to this session by the sender. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Session ID is a 2 octet non-zero unsigned integer. The Assigned Session ID AVP is establishes a value used to multiplex and demultiplex data sent over a tunnel between the LNS and LAC. The L2TP peer MUST place this value in the Session ID header field of all control and data messages that it subsequently transmits over the tunnel that belong to this session. Before the Assigned Session ID AVP is received from a peer, messages MUST be sent to that peer with a Session ID of 0 in the header of all control messages. If an Assigned Session ID AVP has been sent in a previous message, it MUST be sent in a CDN as well to permit a peer to identify the Townsley, et al. Standards Track [Page 28] INTERNET DRAFT L2TP November 2000 appropriate session even if CDN is sent before an Assigned Session ID is received. If the CDN is sent before an Assigned Session ID is communicated (e.g. in response to an ICRQ), it MUST NOT be sent in the CDN message. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. Call Serial Number (ICRQ, OCRQ) The Call Serial Number AVP, Attribute Type 15, encodes an identifier assigned by the LAC or LNS to this call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call Serial Number is a 32 bit value. The Call Serial Number is intended to be an easy reference for administrators on both ends of a tunnel to use when investigating call failure problems. Call Serial Numbers should be set to progressively increasing values, which are likely to be unique for a significant period of time across all interconnected LNSs and LACs. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Minimum BPS (OCRQ) The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable line speed for this call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Townsley, et al. Standards Track [Page 29] INTERNET DRAFT L2TP November 2000 The Minimum BPS is a 32 bit value indicates the speed in bits per second. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Maximum BPS (OCRQ) The Maximum BPS AVP, Attribute Type 17, encodes the highest acceptable line speed for this call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Maximum BPS is a 32 bit value indicates the speed in bits per second. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Bearer Type (ICRQ, OCRQ) The Bearer Type AVP, Attribute Type 18, encodes the bearer type for the incoming or outgoing call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future Bearer Types |V|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Type is a 32-bit bit mask indicating the bearer capability of the call (ICRQ) or required for the call (OCRQ). Bit A refers to an analog channel. Bit D refers to a digital channel. Bit V (virtual) refers to a channel for which there is no physical point to point link. Bits set in the Bearer Type AVP in an OCRQ message indicate which bearer type(s) an outgoing call may be placed on. If more than Townsley, et al. Standards Track [Page 30] INTERNET DRAFT L2TP November 2000 one bit is set, the LAC may choose which bearer type to place the call on. If no bits are set, any type of available channel may be used. Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if the same bit was set in the Bearer Capabilities AVP received from the LAC during control connection establishment. Bits set in the Bearer Type AVP in an ICRQ message indicate what bearer type an incoming call was received on at the LAC. If no bits are set in an ICRQ, then it is assumed that the bearer type was indeterminable. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Framing Type (ICCN, OCCN, OCRQ) The Framing Type AVP, Attribute Type 19, encodes the framing type for the incoming or outgoing call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for future Framing Types |A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Type is a 32-bit mask, which indicates the type of PPP framing requested for an OCRQ, or the type of PPP framing negotiated for an OCCN or ICCN. Bit A indicates asynchronous framing. Bit S indicates synchronous framing. For an OCRQ, both may be set, indicating that the LAC may decide the type of framing to be used. For an ICRQ, only one framing type bit may be set. The framing type SHOULD be used as an indication to PPP on the LNS as to what link options to use for LCP negotiation [RFC1662]. For example, if the A bit is not set in the Framing Type AVP in an ICRQ message and an ACCM LCP option is requested by the PPP client, then the LNS should try to respond with no bits set in the ACCM mask as the LAC will likely not perform async mapping on a non-async interface. Similarly, if the S bit is set, PPP may wish to reject address field compression and protocol field compression options. Townsley, et al. Standards Track [Page 31] INTERNET DRAFT L2TP November 2000 Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Framing Capabilities AVP received from the LAC during control connection establishment. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Called Number (ICRQ, OCRQ) The Called Number AVP, Attribute Type 21, encodes the telephone number to be called for an OCRQ, and the Called number for an ICRQ. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Called Number... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Called Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value needed in this AVP. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Called Number. Calling Number (ICRQ) The Calling Number AVP, Attribute Type 22, encodes the originating number for the incoming call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Calling Number... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calling Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for Townsley, et al. Standards Track [Page 32] INTERNET DRAFT L2TP November 2000 this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Calling Number. Sub-Address (ICRQ, OCRQ) The Sub-Address AVP, Attribute Type 23, encodes additional dialing information. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Address ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sub-Address is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Sub-Address. (Tx) Connect Speed (ICCN, OCCN) The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the speed of the facility chosen for the connection attempt. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The (Tx) Connect Speed BPS is a 4 octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable, or there is no physical point to point link. When the optional Rx Connect Speed AVP is present, the value in this AVP represents the transmit connect speed, from the perspective of the LAC (e.g. data flowing from the LAC to the remote system). When the optional Rx Connect Speed AVP is NOT present, the connection speed between the remote system and LAC is assumed to be symmetric and is represented by the single value in this AVP. Townsley, et al. Standards Track [Page 33] INTERNET DRAFT L2TP November 2000 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. Rx Connect Speed (ICCN, OCCN) The Rx Connect Speed AVP, Attribute Type 38, represents the speed of the connection from the perspective of the LAC (e.g. data flowing from the remote system to the LAC). The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (H) | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BPS is a 4 octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable, or there is no physical point to point link. Presence of this AVP implies that the connection speed may be asymmetric with respect to the transmit connect speed given in the (Tx) Connect Speed AVP. This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 10. Physical Channel ID (ICRQ, OCRP) The Physical Channel ID AVP, Attribute Type 25, encodes the vendor specific physical channel number used for a call. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Physical Channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID is a 4 octet value intended to be used for logging purposes only. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP Townsley, et al. Standards Track [Page 34] INTERNET DRAFT L2TP November 2000 is 10. Private Group ID (ICCN) The Private Group ID AVP, Attribute Type 37, is used by the LAC to indicate that this call is to be associated with a particular customer group. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Group ID ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Private Group ID is a string of octets of arbitrary length. The LNS MAY treat the PPP session as well as network traffic through this session in a special manner determined by the peer. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks. The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. A LAC MAY determine the Private Group ID from a RADIUS response, local configuration, or some other source. This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Private Group ID. Sequencing Required (ICCN, OCCN) The Sequencing Required AVP, Attribute Type 39, indicates to the LNS that Sequence Numbers MUST always be present on the data channel. This AVP has no Attribute Value field. This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6. 4.4.5 Proxy LCP and Authentication AVPs The LAC may have answered the call and negotiated LCP with the Townsley, et al. Standards Track [Page 35] INTERNET DRAFT L2TP November 2000 remote system, perhaps in order to establish the system's apparent identity. In this case, these AVPs may be included to indicate the link properties the remote system initially requested, properties the remote system and LAC ultimately negotiated, as well as PPP authentication information sent and received by the LAC. This information may be used to initiate the PPP LCP and authentication systems on the LNS, allowing PPP to continue without renegotiation of LCP. Note that the LNS policy may be to enter an additional round of LCP negotiation and/or authentication if the LAC is not trusted. Initial Received LCP CONFREQ (ICCN) In the Initial Received LCP CONFREQ AVP, Attribute Type 26, provides the LNS with the Initial CONFREQ received by the LAC from the PPP Peer. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCP CONFREQ is a copy of the body of the initial CONFREQ received, starting at the first option within the body of the LCP message. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Last Sent LCP CONFREQ (ICCN) In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS with the Last CONFREQ sent by the LAC to the PPP Peer. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LCP CONFREQ is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, starting at the first option within the body of the LCP message. Townsley, et al. Standards Track [Page 36] INTERNET DRAFT L2TP November 2000 This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Last Received LCP CONFREQ (ICCN) The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the LNS with the Last CONFREQ received by the LAC from the PPP Peer. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCP CONFREQ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LCP CONFREQ is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within the body of the LCP message. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ. Proxy Authen Type (ICCN) The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Type is a 2 octet unsigned integer, holding: This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. Defined Authen Type values are: 0 - Reserved 1 - Textual username/password exchange 2 - PPP CHAP Townsley, et al. Standards Track [Page 37] INTERNET DRAFT L2TP November 2000 3 - PPP PAP 4 - No Authentication 5 - Microsoft CHAP Version 1 (MSCHAPv1) This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS if the client has already entered this phase with the LAC (which may be determined by the Proxy LCP AVP if present). Associated AVPs for each type of authentication follow. Proxy Authen Name (ICCN) The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authen Name... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authen Name is a string of octets of arbitrary length. It contains the name specified in the client's authentication response. This AVP MUST be present in messages containing a Proxy Authen Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to employ AVP hiding for obscuring the cleartext name. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 6 plus the length of the cleartext name. Proxy Authen Challenge (ICCN) The Proxy Authen Challenge AVP, Attribute Type 31, specifies the challenge sent by the LAC to the PPP Peer, when using proxy authentication. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 38] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge is a string of one or more octets. This AVP MUST be present for Proxy Authen Types 2 and 5. The Challenge field contains the CHAP challenge presented to the client by the LAC. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6, plus the length of the Challenge. Proxy Authen ID (ICCN) The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of the PPP Authentication that was started between the LAC and the PPP Peer, when proxy authentication is being used. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ID is a 2 octet unsigned integer, the most significant octet MUST be 0. The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 3 and 5. For 2 and 5, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For 3, it is the Identifier value of the Authenticate-Request. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. Proxy Authen Response (ICCN) The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP Authentication response received by the LAC from the PPP Peer, when proxy authentication is used. The Attribute Value field for this AVP has the following format: Townsley, et al. Standards Track [Page 39] INTERNET DRAFT L2TP November 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response is a string of octets. This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The Response field contains the client's response to the challenge. For Proxy authen types 2 and 5, this field contains the response value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. In the case of cleartext passwords, AVP hiding is recommended. This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Response. 4.4.6 Call Status AVPs Call Errors (WEN) The Call Errors AVP, Attribute Type 34, is used by the LAC to send error information to the LNS. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | CRC Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC Errors (L) | Framing Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Errors (L) | Hardware Overruns (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Overruns (L) | Buffer Overruns (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Overruns (L) | Time-out Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-out Errors (L) | Alignment Errors (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alignment Errors (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined: Townsley, et al. Standards Track [Page 40] INTERNET DRAFT L2TP November 2000 Reserved - Not used, MUST be 0 CRC Errors - Number of PPP frames received with CRC errors since call was established Framing Errors - Number of improperly framed PPP packets received Hardware Overruns - Number of receive buffer over-runs since call was established Buffer Overruns - Number of buffer over-runs detected since call was established Time-out Errors - Number of time-outs since call was established Alignment Errors - Number of alignment errors since call was established This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 32. ACCM (SLI) The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of the ACCM negotiated with the PPP Peer by the LNS. The Attribute Value field for this AVP has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Send ACCM (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM (L) | Receive ACCM (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive ACCM (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Send ACCM and Receive ACCM are each 4 octet values preceded by a 2 octet reserved quantity. The send ACCM value should be used by the LAC to process packets it sends on the connection. The receive ACCM value should be used by the LAC to process incoming packets on the connection. The default values used by the LAC for both these fields are 0xFFFFFFFF. The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation. This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 16. Townsley, et al. Standards Track [Page 41] INTERNET DRAFT L2TP November 2000 5.0 Protocol Operation The necessary setup for tunneling a PPP session with L2TP consists of two steps, (1) establishing the Control Connection for a Tunnel, and (2) establishing a Session as triggered by an incoming or outgoing call request. The Tunnel and corresponding Control Connection MUST be established before an incoming or outgoing call is initiated. An L2TP Session MUST be established before L2TP can begin to tunnel PPP frames. Multiple Sessions may exist across a single Tunnel and multiple Tunnels may exist between the same LAC and LNS. +-----+ +-----+ | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | | LAC | | LNS | | #######Control Connection######## | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | +-----+ +-----+ Figure 5.1 Tunneling PPP 5.1 Control Connection Establishment The Control Connection is the initial connection that must be achieved between an LAC and LNS before sessions may be brought up. Establishment of the control connection includes securing the identity of the peer, as well as identifying the peer's L2TP version, framing, and bearer capabilities, etc. A three message exchange is utilized to setup the control connection. Following is a typical message exchange: LAC or LNS LAC or LNS ---------- ---------- SCCRQ -> <- SCCRP SCCCN -> <- ZLB ACK The ZLB ACK is sent if there are no further messages waiting in queue for that peer. Townsley, et al. Standards Track [Page 42] INTERNET DRAFT L2TP November 2000 5.1.1 Tunnel Authentication L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel authentication system during control connection establishment. If an LAC or LNS wishes to authenticate the identity of the peer it is contacting or being contacted by, a Challenge AVP is included in the SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, respectively. If the expected response and response received from a peer does not match, establishment of the tunnel MUST be disallowed. To participate in tunnel authentication, a single shared secret MUST exist between the LAC and LNS. This is the same shared secret used for AVP hiding (see section 4.3). See section 4.4.3 for details on construction of the Challenge and Response AVPs. 5.2 Session Establishment After successful control connection establishment, individual sessions may be created. Each session corresponds to single PPP stream between the LAC and LNS. Unlike control connection establishment, session establishment is directional with respect to the LAC and LNS. The LAC requests the LNS to accept a session for an incoming call, and the LNS requests the LAC to accept a session for placing an outgoing call. 5.2.1 Incoming Call Establishment A three message exchange is employed to setup the session. Following is a typical sequence of events: LAC LNS --- --- (Call Detected) ICRQ -> <- ICRP ICCN -> <- ZLB ACK The ZLB ACK is sent if there are no further messages waiting in queue for that peer. Townsley, et al. Standards Track [Page 43] INTERNET DRAFT L2TP November 2000 5.2.2 Outgoing Call Establishment A three message exchange is employed to setup the session. Following is a typical sequence of events: LAC LNS --- --- <- OCRQ OCRP -> (Perform Call Operation) OCCN -> <- ZLB ACK The ZLB ACK is sent if there are no further messages waiting in queue for that peer. 5.3 Forwarding PPP Frames Once tunnel establishment is complete, PPP frames from the remote system are received at the LAC, stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The LNS receives the L2TP packet, and processes the encapsulated PPP frame as if it were received on a local PPP interface. The sender of a message associated with a particular session and tunnel places the Session ID and Tunnel ID (specified by its peer) in the Session ID and Tunnel ID header for all outgoing messages. In this manner, PPP frames are multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair. Multiple tunnels may exist between a given LNS-LAC pair, and multiple sessions may exist within a tunnel. The value of 0 for Session ID and Tunnel ID is special and MUST NOT be used as an Assigned Session ID or Assigned Tunnel ID. For the cases where a Session ID has not yet been assigned by the peer (i.e., during establishment of a new session or tunnel), the Session ID field MUST be sent as 0, and the Assigned Session ID AVP within the message MUST be used to identify the session. Similarly, for cases where the Tunnel ID has not yet been assigned from the peer, the Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to identify the tunnel. Townsley, et al. Standards Track [Page 44] INTERNET DRAFT L2TP November 2000 5.4 Using Sequence Numbers on the Data Channel Sequence numbers are defined in the L2TP header for control messages and optionally for data messages (see section 3.1). These are used to provide a reliable control message transport (see section 5.8) and optional data message sequencing. Each peer maintains separate sequence numbers for the control connection and each individual data session within a tunnel. Unlike the L2TP control channel, the L2TP data channel does not use sequence numbers to retransmit lost data messages. Rather, data messages may use sequence numbers to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. The LAC may request that sequence numbers be present in data messages via the Sequencing Required AVP (see section 4.4.6). If this AVP is present during session setup, sequence numbers MUST be present at all times at the LNS and LAC. If the Sequencing Required AVP is not present, sequence number presence is under control of the LNS. The LNS controls enabling and disabling of sequence numbers by sending a data message with or without sequence numbers present at any time during the life of a session. Thus, if the LAC receives a data message without sequence numbers present, it MUST stop sending sequence numbers in future data messages. If the LAC receives a data message with sequence numbers present, it MUST begin sending sequence numbers in future outgoing data messages. If the LNS enables sequencing after disabling it earlier in the session, the sequence number count picks up where it left off before. The LNS may initiate disabling of sequencing at any time during the session (including the first data message sent). It is recommended that for connections where reordering or packet loss may occur, sequence numbers always be enabled during the initial negotiation stages of PPP and disabled only when and if the risk is considered acceptable. For example, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP (as determined by the PPP NCPs that are established), then the LNS might decide to disable sequencing as IP is tolerant to datagram loss and reordering. 5.5 Keepalive (Hello) A keepalive mechanism is employed by L2TP in order to differentiate tunnel outages from extended periods of no control or data activity on a tunnel. This is accomplished by injecting Hello control messages (see section 6.5) after a specified period of time has elapsed since the last data or control message was received on a tunnel. As for any Townsley, et al. Standards Track [Page 45] INTERNET DRAFT L2TP November 2000 other control message, if the Hello message is not reliably delivered then the tunnel is declared down and is reset. The transport reset mechanism along with the injection of Hello messages ensures that a connectivity failure between the LNS and the LAC will be detected at both ends of a tunnel. 5.6 Session Teardown Session teardown may be initiated by either the LAC or LNS and is accomplished by sending a CDN control message. After the last session is cleared, the control connection MAY be torn down as well (and typically is). Following is an example of a typical control message exchange: LAC or LNS LAC or LNS CDN -> (Clean up) <- ZLB ACK (Clean up) 5.7 Control Connection Teardown Control connection teardown may be initiated by either the LAC or LNS and is accomplished by sending a single StopCCN control message. The receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of the message and maintain enough control connection state to properly accept StopCCN retransmissions over at least a full retransmission cycle (in case the ZLB ACK is lost). The recommended time for a full retransmission cycle is 31 seconds (see section 5.8). Following is an example of a typical control message exchange: LAC or LNS LAC or LNS StopCCN -> (Clean up) <- ZLB ACK (Wait) (Clean up) An implementation may shut down an entire tunnel and all sessions on the tunnel by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole tunnel. Townsley, et al. Standards Track [Page 46] INTERNET DRAFT L2TP November 2000 5.8 Reliable Delivery of Control Messages L2TP provides a lower level reliable transport service for all control messages. The Nr and Ns fields of the control message header (see section 3.1) belong to this transport. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control message is a sliding window transport that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for the control connection within a tunnel. The message sequence number, Ns, begins at 0. Each subsequent message is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 65536. The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32767 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered a duplicate of a message already received and ignored from processing. However, in order to ensure that all messages are acknowledged properly (particularly in the case of a lost ZLB ACK message), receipt of duplicate messages MUST be acknowledged by the reliable transport. This acknowledgement may either piggybacked on a message in queue, or explicitly via a ZLB ACK. All control messages take up one slot in the control message sequence number space, except the ZLB acknowledgement. Thus, Ns is not incremented after a ZLB message is sent. The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next (e.g. the last Ns of a non- ZLB message received plus 1, modulo 65536). While the Nr in a received ZLB is used to flush messages from the local retransmit queue (see below), Nr of the next message sent is not be updated by the Ns of the ZLB. As a precaution, Nr should be sanity checked before flushing the retransmit queue. e.g. if the Nr received in a control message is greater than the last Ns sent plus 1 modulo 65536, it is clearly invalid. The reliable transport at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level. Messages arriving out of order may be queued for in-order delivery when the missing messages are received, or they may be discarded requiring a retransmission by the peer. When Townsley, et al. Standards Track [Page 47] INTERNET DRAFT L2TP November 2000 dropping out of order control packets, Nr MAY be updated before the packet is discarded. Each tunnel maintains a queue of control messages to be transmitted to its peer. The message at the front of the queue is sent with a given Ns value, and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message. After a period of time (a recommended default is 1 second) passes without acknowledgement, the message is retransmitted. The retransmitted message contains the same Ns value, but the Nr value MUST be updated with the sequence number of the next expected message. Each subsequent retransmission of a message MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmission should occur after 2 seconds has elapsed, then 4 seconds, etc. An implementation MAY place a cap upon the maximum interval between retransmissions. This cap MUST be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions, (a recommended default is 5, but SHOULD be configurable), the tunnel and all sessions within MUST be cleared. When a tunnel is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message exchange has occurred. A sliding window mechanism is used for control message transmission. Consider two peers A & B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP messages. B is now allowed to have up to N outstanding control messages. Once N have been sent, it must wait for an acknowledgment that advances the window before sending new control messages. An implementation may support a receive window of only 1 (e.g. by sending out a Receive Window Size AVP with a value of 1), but MUST accept a window of up to 4 from its peer (e.g. have the ability to send 4 messages before backing off). A value of 0 for the Receive Window Size AVP is invalid. When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. The recommended procedure for this is described in Appendix A. A peer MUST NOT withhold acknowledgment of messages as a technique for flow controlling control messages. An L2TP implementation is expected to be able to keep up with incoming control messages, possibly responding to some with errors reflecting an inability to honor the requested action. Townsley, et al. Standards Track [Page 48] INTERNET DRAFT L2TP November 2000 Appendix B contains examples of control message transmission, acknowledgement, and retransmission. 6.0 Control Connection Protocol Specification The following control connection messages are used to establish, clear and maintain L2TP tunnels. All data is sent in network order (high order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility. 6.1 Start-Control-Connection-Request (SCCRQ) Start-Control-Connection-Request (SCCRQ) is a control message used to initialize a tunnel between an LNS and an LAC. It is sent by either the LAC or the LNS to being the tunnel establishment process. The following AVPs MUST be present in the SCCRQ: Message Type AVP Protocol Version Host Name Framing Capabilities Assigned Tunnel ID The Following AVPs MAY be present in the SCCRQ: Bearer Capabilities Receive Window Size Challenge Tie Breaker Firmware Revision Vendor Name 6.2 Start-Control-Connection-Reply (SCCRP) Start-Control-Connection-Reply (SCCRP) is a control message sent in reply to a received SCCRQ message. SCCRP is used to indicate that the SCCRQ was accepted and establishment of the tunnel should continue. The following AVPs MUST be present in the SCCRP: Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID The following AVPs MAY be present in the SCCRP: Townsley, et al. Standards Track [Page 49] INTERNET DRAFT L2TP November 2000 Bearer Capabilities Firmware Revision Vendor Name Receive Window Size Challenge Challenge Response 6.3 Start-Control-Connection-Connected (SCCCN) Start-Control-Connection-Connected (SCCCN) is a control message sent in reply to an SCCRP. SCCCN completes the tunnel establishment process. The following AVP MUST be present in the SCCCN: Message Type The following AVP MAY be present in the SCCCN: Challenge Response 6.4 Stop-Control-Connection-Notification (StopCCN) Stop-Control-Connection-Notification (StopCCN) is a control message sent by either the LAC or LNS to inform its peer that the tunnel is being shutdown and the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit call control messages). The reason for issuing this request is indicated in the Result Code AVP. There is no explicit reply to the message, only the implicit ACK that is received by the reliable control message transport layer. The following AVPs MUST be present in the StopCCN: Message Type Result Code The Assigned Tunnel ID MUST be present in the StopCCN if it has been sent in a previous message (see section 4.4.3). 6.5 Hello (HELLO) The Hello (HELLO) message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a "keepalive" for the tunnel. The sending of HELLO messages and the policy for sending them are left up to the implementation. A peer MUST NOT expect HELLO messages Townsley, et al. Standards Track [Page 50] INTERNET DRAFT L2TP November 2000 at any time or interval. As with all messages sent on the control connection, the receiver will return either a ZLB ACK or an (unrelated) message piggybacking the necessary acknowledgement information. Since a HELLO is a control message, and control messages are reliably sent by the lower level transport, this keepalive function operates by causing the transport level to reliably deliver a message. If a media interruption has occurred, the reliable transport will be unable to deliver the HELLO across, and will clean up the tunnel. Keepalives for the tunnel MAY be implemented by sending a HELLO if a period of time (a recommended default is 60 seconds, but SHOULD be configurable) has passed without receiving any message (data or control) from the peer. HELLO messages are global to the tunnel. The Session ID in a HELLO message MUST be 0. The Following AVP MUST be present in the HELLO message: Message Type 6.6 Incoming-Call-Request (ICRQ) Incoming-Call-Request (ICRQ) is a control message sent by the LAC to the LNS when an incoming call is detected. It is the first in a three message exchange used for establishing a session within an L2TP tunnel. ICRQ is used to indicate that a session is to be established between the LAC and LNS for this call and provides the LNS with parameter information for the session. The LAC may defer answering the call until it has received an ICRP from the LNS indicating that the session should be established. This mechanism allows the LNS to obtain sufficient information about the call before determining whether it should be answered or not. Alternatively, the LAC may answer the call, negotiate LCP and PPP authentication, and use the information gained to choose the LNS. In this case, the call has already been answered by the time the ICRP message is received; the LAC simply spoofs the "call indication" and "call answer" steps in this case. The following AVPs MUST be present in the ICRQ: Message Type Assigned Session ID Call Serial Number Townsley, et al. Standards Track [Page 51] INTERNET DRAFT L2TP November 2000 The following AVPs MAY be present in the ICRQ: Bearer Type Physical Channel ID Calling Number Called Number Sub-Address 6.7 Incoming-Call-Reply (ICRP) Incoming-Call-Reply (ICRP) is a control message sent by the LNS to the LAC in response to a received ICRQ message. It is the second in the three message exchange used for establishing sessions within an L2TP tunnel. ICRP is used to indicate that the ICRQ was successful and for the LAC to answer the call if it has not already done so. It also allows the LNS to indicate necessary parameters for the L2TP session. The following AVPs MUST be present in the ICRP: Message Type Assigned Session ID 6.8 Incoming-Call-Connected (ICCN) Incoming-Call-Connected (ICCN) is a control message sent by the LAC to the LNS in response to a received ICRP message. It is the third message in the three message exchange used for establishing sessions within an L2TP tunnel. ICCN is used to indicate that the ICRP was accepted, the call has been answered, and that the L2TP session should move to the established state. It also provides additional information to the LNS about parameters used for the answered call (parameters that may not always available at the time the ICRQ is issued). If the ICCN is carrying crucial PPP initialization information (such as Proxy LCP or Auth), the LAC SHOULD wait until the ICCN has been acknowledged before sending data messages. This is recommended because (1) there is no guarantee that the ICCN and first data messages will not be reordered during transit, and (2) the LNS may take some time to initialize its PPP session with the proxied information. The following AVPs MUST be present in the ICCN: Message Type Townsley, et al. Standards Track [Page 52] INTERNET DRAFT L2TP November 2000 (Tx) Connect Speed Framing Type The following AVPs MAY be present in the ICCN: Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response Private Group ID Rx Connect Speed Sequencing Required 6.9 Outgoing-Call-Request (OCRQ) Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to the LAC to indicate that an outbound call from the LAC is to be established. It is the first in a three message exchange used for establishing a session within an L2TP tunnel. OCRQ is used to indicate that a session is to be established between the LNS and LAC for this call and provides the LAC with parameter information for both the L2TP session, and the call that is to be placed An LNS MUST have received a Bearer Capabilities AVP during tunnel establishment from an LAC in order to request an outgoing call to that LAC. The following AVPs MUST be present in the OCRQ: Message Type Assigned Session ID Call Serial Number Minimum BPS Maximum BPS Bearer Type Framing Type Called Number The following AVPs MAY be present in the OCRQ: Sub-Address Townsley, et al. Standards Track [Page 53] INTERNET DRAFT L2TP November 2000 6.10 Outgoing-Call-Reply (OCRP) Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to the LNS in response to a received OCRQ message. It is the second in a three message exchange used for establishing a session within an L2TP tunnel. OCRP is used to indicate that the LAC is able to attempt the outbound call and returns certain parameters regarding the call attempt. The following AVPs MUST be present in the OCRP: Message Type Assigned Session ID The following AVPs MAY be present in the OCRP: Physical Channel ID 6.11 Outgoing-Call-Connected (OCCN) Outgoing-Call-Connected (OCCN) is a control message sent by the LAC to the LNS following the OCRP and after the outgoing call has been completed. It is the final message in a three message exchange used for establishing a session within an L2TP tunnel. OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LNS about the particular parameters obtained after the call was established. The following AVPs MUST be present in the OCCN: Message Type (Tx) Connect Speed Framing Type The following AVPs MAY be present in the OCCN: Rx Connect Speed Sequencing Required 6.12 Call-Disconnect-Notify (CDN) The Call-Disconnect-Notify (CDN) message is an L2TP control message sent by either the LAC or LNS to request disconnection of a specific call within the tunnel. Its purpose is to inform the peer of the disconnection and the reason why the disconnection occurred. The peer MUST clean up any resources, and does not send back any indication of Townsley, et al. Standards Track [Page 54] INTERNET DRAFT L2TP November 2000 success or failure for such cleanup. The following AVPs MUST be present in the CDN: Message Type Result Code The Assigned Session ID MUST be present in the CDN if it has been sent in a previous message (see section 4.4.3). The following AVPs MAY be present in the CDN: Q.931 Cause Code 6.13 WAN-Error-Notify (WEN) The WAN-Error-Notify message is an L2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established. The following AVPs MUST be present in the WEN: Message Type Call Errors 6.14 Set-Link-Info (SLI) The Set-Link-Info message is an L2TP control message sent by the LNS to the LAC after the last LCP Conf ACK is received during PPP LCP negotiation. This AVP contains any relevant link level parameters that the LAC may need to be aware of (for instance, ACCM map info). If there is no relevant information to be sent in the SLI, then it MAY be omitted. Since LCP may be renegotiated at any time, an SLI may be sent at any time during the life of the call, thus the LAC MUST be able to update its internal call information and behavior on an active session. Further, if there are packets in queue at the LAC when an SLI is received, these must be flushed before applying the SLI information to the link. If the PPP session at the LNS renegotiates LCP during the call, an SLI MUST be sent to the LAC to return link level information to the initial default values while the negotiation occurs. However, if the last SLI sent was already set to default values or no SLI was sent at all, this step MAY be omitted. Townsley, et al. Standards Track [Page 55] INTERNET DRAFT L2TP November 2000 The following AVPs MUST be present in the SLI: Message Type ACCM 7.0 Control Connection State Machines State tables defined in this section govern the exchange of control messages defined in section 6. Tables are defined for incoming call placement, outgoing call placement, as well as for initiation of the tunnel itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying transport defined in section 5.8. 7.1 Control Connection Protocol Operation This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them. Receipt of an invalid or unrecoverable malformed control message should be logged appropriately and the control connection cleared to ensure recovery to a known state. The control connection may then be restarted by the initiator. An invalid control message is defined as a message which contains a Message Type that is marked mandatory (see section 4.4.1) and is unknown to the implementation, or a control message that is received in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). Examples of a malformed control message include one that has an invalid value in its header, contains an AVP that is formatted incorrectly or whose value is out of range, or a message that is missing a required AVP. A control message with a malformed header should be discarded. A control message with an invalid AVP should look to the M-bit for that AVP to determine whether the error is recoverable or not. A malformed yet recoverable non-mandatory (M-bit is not set) AVP within a control message should be treated in a similar manner as an unrecognized non-mandatory AVP. Thus, if a malformed AVP is received with the M-bit set, the session or tunnel should be terminated with a proper Result or Error Code sent. If the M-bit is not set, the AVP should be ignored (with the exception of logging a local error message) and the message accepted. This MUST NOT be considered a license to send malformed AVPs, but simply a guide towards how to handle an improperly formatted message Townsley, et al. Standards Track [Page 56] INTERNET DRAFT L2TP November 2000 if one is received. It is impossible to list all potential malformations of a given message and give advice for each. That said, one example of a recoverable, malformed AVP might be if the Rx Connect Speed AVP, attribute 38, is received with a length of 8 rather than 10 and the BPS given in 2 octets rather than 4. Since the Rx Connect Speed is non-mandatory, this condition should not be considered catastrophic. As such, the control message should be accepted as if the AVP had not been received (with the exception of a local error message being logged). In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that regardless of the initiator of the tunnel destruction, the reliable delivery mechanism must be allowed to run (see section 5.8) before destroying the tunnel. This permits the tunnel management messages to be reliably delivered to the peer. Appendix B.1 contains an example of lock-step tunnel establishment. 7.2 Control Connection States The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the originator and receiver. The originating peer is the one which first initiates establishment of the tunnel (in a tie breaker situation, this is the winner of the tie). Since either LAC or LNS can be the originator, a collision can occur. See the Tie Breaker AVP in section 4.4.3 for a description of this and its resolution. 7.2.1 Control Connection Establishment State Event Action New State ----- ----- ------ --------- idle Local Send SCCRQ wait-ctl-reply Open request idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up idle Receive SCCRP Send StopCCN idle Clean up idle Receive SCCCN Clean up idle Townsley, et al. Standards Track [Page 57] INTERNET DRAFT L2TP November 2000 wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-open event to waiting sessions wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable Clean up wait-ctl-reply Receive SCCRQ, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state wait-ctl-reply Receive SCCCN Send StopCCN idle Clean up wait-ctl-conn Receive SCCCN, Send tunnel-open established acceptable event to waiting sessions wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable Clean up wait-ctl-conn Receive SCCRP, Send StopCCN, idle SCCRQ Clean up established Local Send tunnel-open established Open request event to waiting (new call) sessions established Admin Send StopCCN idle Tunnel Close Clean up established Receive SCCRQ, Send StopCCN idle SCCRP, SCCCN Clean up idle Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established The states associated with the LNS or LAC for control connection establishment are: idle Both initiator and recipient start from this state. An initiator transmits an SCCRQ, while a recipient remains in the idle state until receiving an SCCRQ. Townsley, et al. Standards Track [Page 58] INTERNET DRAFT L2TP November 2000 wait-ctl-reply The originator checks to see if another connection has been requested from the same peer, and if so, handles the collision situation described in section 5.8. When an SCCRP is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a StopCCN MUST be sent to the peer and the originator cleans up and terminates the tunnel. wait-ctl-conn This is where an SCCCN is awaited; upon receipt, the challenge response is checked. The tunnel either is established, or is torn down if an authorization failure is detected. established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection- Notification. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Notification and clean up the tunnel. If the originator receives a Stop-Control-Connection-Notification it MUST also clean up the tunnel. 7.3 Timing considerations Due to the real-time nature of telephone signaling, both the LNS and LAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The call and connection state figures do not specify exceptions caused by timers. These are addressed in section 5.8. 7.4 Incoming calls An Incoming-Call-Request message is generated by the LAC when an incoming call is detected (for example, an associated telephone line rings). The LAC selects a Session ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaptation is used and analog if digital modems are involved. Calling Number, Called Number, and Subaddress may be included in the message if they are available from the telephone network. Townsley, et al. Standards Track [Page 59] INTERNET DRAFT L2TP November 2000 Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS but it does not necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if: - No resources are available to handle more sessions - The dialed, dialing, or subaddress fields do not correspond to an authorized user - The bearer service is not authorized or supported If the LNS chooses to accept the call, it responds with an Incoming- Call-Reply. When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, a Call-Disconnect-Notify is sent by the LAC to indicate this condition. When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session. 7.4.1 LAC Incoming Call States State Event Action New State ----- ----- ------ --------- idle Bearer Ring or Initiate local wait-tunnel Ready to indicate tunnel open incoming conn. idle Receive ICCN, Clean up idle ICRP, CDN wait-tunnel Bearer line drop Clean up idle or local close request wait-tunnel tunnel-open Send ICRQ wait-reply wait-reply Receive ICRP, Send ICCN established acceptable wait-reply Receive ICRP, Send CDN, idle Not acceptable Clean up wait-reply Receive ICRQ Send CDN idle Clean up Townsley, et al. Standards Track [Page 60] INTERNET DRAFT L2TP November 2000 wait-reply Receive CDN Clean up idle ICCN wait-reply Local Send CDN, idle close request or Clean up Bearer line drop established Receive CDN Clean up idle established Receive ICRQ, Send CDN, idle ICRP, ICCN Clean up established Bearer line Send CDN, idle drop or local Clean up close request The states associated with the LAC for incoming calls are: idle The LAC detects an incoming call on one of its interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC initiates its tunnel establishment state machine, and moves to a state waiting for confirmation of the existence of a tunnel. wait-tunnel In this state the session is waiting for either the control connection to be opened or for verification that the tunnel is already open. Once an indication that the tunnel has/was opened, session control messages may be exchanged. The first of these is the Incoming-Call-Request. wait-reply The LAC receives either a CDN message indicating the LNS is not willing to accept the call (general error or don't accept) and moves back into the idle state, or an Incoming-Call-Reply message indicating the call is accepted, the LAC sends an Incoming-Call- Connected message and enters the established state. established Data is exchanged over the tunnel. The call may be cleared following: + An event on the connected interface: The LAC sends a Call- Disconnect-Notify message + Receipt of a Call-Disconnect-Notify message: The LAC cleans up, disconnecting the call. + A local reason: The LAC sends a Call-Disconnect-Notify Townsley, et al. Standards Track [Page 61] INTERNET DRAFT L2TP November 2000 message. 7.4.2 LNS Incoming Call States State Event Action New State ----- ----- ------ --------- idle Receive ICRQ, Send ICRP wait-connect acceptable idle Receive ICRQ, Send CDN, idle not acceptable Clean up idle Receive ICRP Send CDN idle Clean up idle Receive ICCN Clean up idle wait-connect Receive ICCN Prepare for established acceptable data wait-connect Receive ICCN Send CDN, idle not acceptable Clean up wait-connect Receive ICRQ, Send CDN idle ICRP Clean up idle, Receive CDN Clean up idle wait-connect, established wait-connect Local Send CDN, idle established Close request Clean up established Receive ICRQ, Send CDN idle ICRP, ICCN Clean up The states associated with the LNS for incoming calls are: idle An Incoming-Call-Request message is received. If the request is not acceptable, a Call-Disconnect-Notify is sent back to the LAC and the LNS remains in the idle state. If the Incoming-Call- Request message is acceptable, an Incoming-Call-Reply is sent. The session moves to the wait-connect state. Townsley, et al. Standards Track [Page 62] INTERNET DRAFT L2TP November 2000 wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This could happen, for example, if a telephone user accidentally places a standard voice call to an LAC resulting in a handshake failure on the called modem. established The session is terminated either by receipt of a Call-Disconnect- Notify message from the LAC or by sending a Call-Disconnect- Notify. Clean up follows on both sides regardless of the initiator. 7.5 Outgoing calls Outgoing calls are initiated by an LNS and instruct an LAC to place a call. There are three messages for outgoing calls: Outgoing-Call- Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request specifying the dialed party phone number, subaddress and other parameters. The LAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the LAC determines that the proper facilities exist to place the call and the call is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connected, the LAC sends an Outgoing-Call-Connected message to the LNS indicating the final result of the call attempt: 7.5.1 LAC Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Receive OCRQ, Send OCRP, wait-cs-answer acceptable Open bearer idle Receive OCRQ, Send CDN, idle not acceptable Clean up idle Receive OCRP Send CDN idle Clean up idle Receive OCCN, Clean up idle CDN wait-cs-answer Bearer answer, Send OCCN established framing detected Townsley, et al. Standards Track [Page 63] INTERNET DRAFT L2TP November 2000 wait-cs-answer Bearer failure Send CDN, idle Clean up wait-cs-answer Receive OCRQ, Send CDN idle OCRP, OCCN Clean up established Receive OCRQ, Send CDN idle OCRP, OCCN Clean up wait-cs-answer, Receive CDN Clean up idle established established Bearer line drop, Send CDN, idle Local close Clean up request The states associated with the LAC for outgoing calls are: idle If Outgoing-Call-Request is received in error, respond with a Call-Disconnect-Notify. Otherwise, allocate a physical channel and send an Outgoing-Call-Reply. Place the outbound call and move to the wait-cs-answer state. wait-cs-answer If the call is not completed or a timer expires waiting for the call to complete, send a Call-Disconnect-Notify with the appropriate error condition set and go to idle state. If a circuit switched connection is established and framing is detected, send an Outgoing-Call-Connected indicating success and go to established state. established If a Call-Disconnect-Notify is received by the LAC, the telco call MUST be released via appropriate mechanisms and the session cleaned up. If the call is disconnected by the client or the called interface, a Call-Disconnect-Notify message MUST be sent to the LNS. The sender of the Call-Disconnect-Notify message returns to the idle state after sending of the message is complete. 7.5.2 LNS Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Local Initiate local wait-tunnel open request tunnel-open Townsley, et al. Standards Track [Page 64] INTERNET DRAFT L2TP November 2000 idle Receive OCCN, Clean up idle OCRP, CDN wait-tunnel tunnel-open Send OCRQ wait-reply wait-reply Receive OCRP, none wait-connect acceptable wait-reply Receive OCRP, Send CDN idle not acceptable Clean up wait-reply Receive OCCN, Send CDN idle OCRQ Clean up wait-connect Receive OCCN none established wait-connect Receive OCRQ, Send CDN idle OCRP Clean up idle, Receive CDN, Clean up idle wait-reply, wait-connect, established established Receive OCRQ, Send CDN idle OCRP, OCCN Clean up wait-reply, Local Send CDN idle wait-connect, Close request Clean up established wait-tunnel Local Clean up idle Close request The states associated with the LNS for outgoing calls are: idle, wait-tunnel When an outgoing call is initiated, a tunnel is first created, much as the idle and wait-tunnel states for an LAC incoming call. Once a tunnel is established, an Outgoing-Call-Request message is sent to the LAC and the session moves into the wait-reply state. wait-reply If a Call-Disconnect-Notify is received, an error occurred, and the session is cleaned up and returns to idle. If an Outgoing- Call-Reply is received, the call is in progress and the session moves to the wait-connect state. Townsley, et al. Standards Track [Page 65] INTERNET DRAFT L2TP November 2000 wait-connect If a Call-Disconnect-Notify is received, the call failed; the session is cleaned up and returns to idle. If an Outgoing-Call- Connected is received, the call has succeeded and the session may now exchange data. established If a Call-Disconnect-Notify is received, the call has been terminated for the reason indicated in the Result and Cause Codes; the session moves back to the idle state. If the LNS chooses to terminate the session, it sends a Call-Disconnect-Notify to the LAC and then cleans up and idles its session. 7.6 Tunnel Disconnection The disconnection of a tunnel consists of either peer issuing a Stop-Control-Connection-Notification. The sender of this Notification should wait a finite period of time for the acknowledgment of this message before releasing the control information associated with the tunnel. The recipient of this Notification should send an acknowledgment of the Notification and then release the associated control information. When to release a tunnel is an implementation issue and is not specified in this document. A particular implementation may use whatever policy is appropriate for determining when to release a control connection. Some implementations may leave a tunnel open for a period of time or perhaps indefinitely after the last session for that tunnel is cleared. Others may choose to disconnect the tunnel immediately after the last user connection on the tunnel disconnects. 8.0 L2TP Over Specific Media L2TP is self-describing, operating at a level above the media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. The following sections describe details needed to permit interoperability over specific media. 8.1 L2TP over UDP/IP L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel picks an available source UDP port (which may or may not be 1701), and sends to the desired destination address at port 1701. The recipient picks a free port on its own system (which may or may not be 1701), and sends its reply to the initiator's UDP port and address, setting its own source port to Townsley, et al. Standards Track [Page 66] INTERNET DRAFT L2TP November 2000 the free port it found. Once the source and destination ports and addresses are established, they MUST remain static for the life of the tunnel. It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the tunnel, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementers should consider the potential implication of this before choosing an arbitrary source port. IP fragmentation may occur as the L2TP packet travels over the IP substrate. L2TP makes no special efforts to optimize this. A LAC implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments in which the MTU's of the path over which the L2TP packets are likely to travel have a consistent value. The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and data messages. An L2TP implementation MAY provide an option to disable UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets. Port 1701 is used for both L2F [RFC2341] and L2TP packets. The Version field in each header may be used to discriminate between the two packet types (L2F uses a value of 1, and the L2TP version described in this document uses a value of 2). An L2TP implementation running on a system which does not support L2F MUST silently discard all L2F packets. To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has the characteristic of being able to reorder or silently drop packets. The former may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. The latter may break protocols which assume per-packet indication of error, such as TCP header compression. Sequencing may be handled by using L2TP data message sequence numbers if any protocol being transported by the PPP tunnel cannot tolerate reordering. The sequence dependency characteristics of individual protocols are outside the scope of this document. Allowing packets to be dropped silently is perhaps more problematic with some protocols. If PPP reliable delivery [RFC1663] is enabled, no upper PPP protocol will encounter lost packets. If L2TP sequence numbers are enabled, L2TP can detect the packet loss. In the case of an LNS, the PPP and L2TP stacks are both present within the LNS, and packet loss signaling may occur precisely as if a packet was received Townsley, et al. Standards Track [Page 67] INTERNET DRAFT L2TP November 2000 with a CRC error. Where the LAC and PPP stack are co-resident, this technique also applies. Where the LAC and PPP client are physically distinct, the analogous signaling MAY be accomplished by sending a packet with a CRC error to the PPP client. Note that this would greatly increase the complexity of debugging client line problems, since the client statistics could not distinguish between true media errors and LAC-initiated ones. Further, this technique is not possible on all hardware. If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet results in a 1 in 2**16 chance of a TCP segment being forwarded with incorrect contents [RFC1144]. Where the combination of the packet loss rate with this statistical exposure is unacceptable, TCP header compression SHOULD NOT be used. In general, it is wise to remember that the L2TP/UDP/IP transport is an unreliable transport. As with any PPP media that is subject to loss, care should be taken when using protocols that are particularly loss-sensitive. Such protocols include compression and encryption protocols that employ history. 8.2 IP When operating in IP environments, L2TP MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations (perhaps corresponding to a compressed header format) MAY be defined and made available as a configurable option. 9.0 Security Considerations L2TP encounters several security issues in its operation. The general approach of L2TP to these issues is documented here. 9.1 Tunnel Endpoint Security The tunnel endpoints may optionally perform an authentication procedure of one another during tunnel establishment. This authentication has the same security attributes as CHAP, and has reasonable protection against replay and snooping during the tunnel establishment process. This mechanism is not designed to provide any authentication beyond tunnel establishment; it is fairly simple for a malicious user who can snoop the tunnel stream to inject packets once an authenticated tunnel establishment has been completed successfully. For authentication to occur, the LAC and LNS MUST share a single Townsley, et al. Standards Track [Page 68] INTERNET DRAFT L2TP November 2000 secret. Each side uses this same secret when acting as authenticatee as well as authenticator. Since a single secret is used, the tunnel authentication AVPs include differentiating values in the CHAP ID fields for each message digest calculation to guard against replay attacks. The Assigned Tunnel ID and Assigned Session ID (See section 4.4.3) SHOULD be selected in an unpredictable manner rather than sequentially or otherwise. Doing so will help deter hijacking of a session by a malicious user who does not have access to packet traces between the LAC and LNS. 9.2 Packet Level Security Securing L2TP requires that the underlying transport make available encryption, integrity and authentication services for all L2TP traffic. This secure transport operates on the entire L2TP packet and is functionally independent of PPP and the protocol being carried by PPP. As such, L2TP is only concerned with confidentiality, authenticity, and integrity of the L2TP packets between its tunnel endpoints (the LAC and LNS), not unlike link-layer encryption being concerned only about protecting the confidentiality of traffic between its physical endpoints. 9.3 End to End Security Protecting the L2TP packet stream via a secure transport does, in turn, also protect the data within the tunneled PPP packets while transported from the LAC to the LNS. Such protection should not be considered a substitution for end-to-end security between communicating hosts or applications. 9.4 L2TP and IPsec When running over IP, IPsec provides packet-level security via ESP and/or AH. All L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP data packets to the IPsec system. In addition to IP transport security, IPsec defines a mode of operation that allows tunneling of IP packets. The packet level encryption and authentication provided by IPsec tunnel mode and that provided by L2TP secured with IPsec provide an equivalent level of security for these requirements. IPsec also defines access control features that are required of a compliant IPsec implementation. These features allow filtering of packets based upon network and transport layer characteristics such as IP address, ports, etc. In the L2TP tunneling model, analogous Townsley, et al. Standards Track [Page 69] INTERNET DRAFT L2TP November 2000 filtering is logically performed at the PPP layer or network layer above L2TP. These network layer access control features may be handled at the LNS via vendor-specific authorization features based upon the authenticated PPP user, or at the network layer itself by using IPsec transport mode end-to-end between the communicating hosts. The requirements for access control mechanisms are not a part of the L2TP specification and as such are outside the scope of this document. 9.5 Proxy PPP Authentication L2TP defines AVPs that MAY be exchanged during session establishment to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation (see section 4.4.5). This implies a direct trust relationship of the LAC on behalf of the LNS. If the LNS chooses to implement proxy authentication, it MUST be able to be configured off, requiring a new round a PPP authentication initiated by the LNS (which may or may not include a new round of LCP negotiation). 10.0 IANA Considerations This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document. 10.1 AVP Attributes As defined in section 4.1, AVPs contain vendor ID, Attribute and Value fields. For vendor ID value of 0, IANA will maintain a registry of assigned Attributes and in some case also values. Attributes 0-39 are assigned as defined in section 4.4. The remaining values are available for assignment upon Expert Review [RFC 2434]. 10.2 Message Type AVP Values As defined in section 4.4.1, Message Type AVPs (Attribute Type 0) have an associated value maintained by IANA. Values 0-16 are defined in section 3.2, the remaining values are available for assignment upon Expert Review [RFC 2434] 10.3 Result Code AVP Values As defined in section 4.4.2, Result Code AVPs (Attribute Type 1) contain three fields. Two of these fields (the Result Code and Error Code fields) have associated values maintained by IANA. Townsley, et al. Standards Track [Page 70] INTERNET DRAFT L2TP November 2000 10.3.1 Result Code Field Values The Result Code AVP may be included in CDN and StopCCN messages. The allowable values for the Result Code field of the AVP differ depending upon the value of the Message Type AVP. For the StopCCN message, values 0-7 are defined in section 4.4.2; for the CDN message, values 0-11 are defined in the same section. The remaining values of the Result Code field for both messages are available for assignment upon Expert Review [RFC 2434]. 10.3.2 Error Code Field Values Values 0-7 are defined in section 4.4.2. Remaining values are available for assignment upon Expert Review [RFC 2434]. 10.4 Framing Capabilities & Bearer Capabilities The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in section 4.4.3) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434]. 10.5 Proxy Authen Type AVP Values The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in section 4.4.5, the remaining values are available for assignment upon Expert Review [RFC 2434]. 10.6 AVP Header Bits There are four remaining reserved bits in the AVP header. Additional bits should only be assigned via a Standards Action [RFC 2434]. 11.0 References [DSS1] ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998 [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", Townsley, et al. Standards Track [Page 71] INTERNET DRAFT L2TP November 2000 STD 13, RFC 1034, November 1987. [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. Townsley, et al. Standards Track [Page 72] INTERNET DRAFT L2TP November 2000 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9 12.0 Acknowledgments The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of this document. Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the endpoint authentication mechanism. John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL., which led to improvement of the overall readability and clarity of this document. 13.0 Authors' Addresses Gurdeep Singh Pall Microsoft Corporation Redmond, WA Email: gurdeep@microsoft.com Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089 Email: palter@zev.net Allan Rubens Email: acr@del.com W. Mark Townsley Townsley, et al. Standards Track [Page 73] INTERNET DRAFT L2TP November 2000 cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 Email: mark@townsley.net Andrew J. Valencia P.O. Box 2928 Vashon, WA 98070 Email: vandys@zendo.com Glen Zorn cisco Systems 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Email: gwz@cisco.com Appendix A: Control Channel Slow Start and Congestion Avoidance Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS]. Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP (in the text below, it is assumed any increase will be limited by the Receive Window Size). The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH. A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgement (either explicit or piggybacked). When the acknowledgement is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ZLB or piggybacked) is received. Increasing CWND by one on each ACK has the Townsley, et al. Standards Track [Page 74] INTERNET DRAFT L2TP November 2000 effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins. During congestion avoidance, CWND expands more slowly. Specifically, it increases by 1/CWND for every new ACK received. That is, CWND is increased by one packet after CWND new ACKs have been received. Window expansion during the congestion avoidance phase is effectively linear, with CWND increasing by one packet each round trip. When congestion occurs (indicated by the triggering of a retransmission) one half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase. Appendix B: Control Message Examples B.1: Lock-step tunnel establishment In this example, an LAC establishes a tunnel, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within a ZLB ACK message. An alternative would be to piggyback the acknowledgement within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the tunnel. LAC or LNS LNS or LAC ---------- ---------- SCCRQ -> Nr: 0, Ns: 0 <- SCCRP Nr: 1, Ns: 0 SCCCN -> Nr: 1, Ns: 1 <- ZLB Nr: 2, Ns: 1 B.2: Lost packet with retransmission An existing tunnel has a new session requested by the LAC. The ICRP is lost and must be retransmitted by the LNS. Note that loss of the ICRP has two impacts: not only does it keep the upper level state machine from progressing, but it also keeps the LAC from seeing a timely lower level acknowledgment of its ICRQ. LAC LNS --- --- Townsley, et al. Standards Track [Page 75] INTERNET DRAFT L2TP November 2000 ICRQ -> Nr: 1, Ns: 2 (packet lost) <- ICRP Nr: 3, Ns: 1 (pause; LAC's timer started first, so fires first) ICRQ -> Nr: 1, Ns: 2 (Realizing that it has already seen this packet, the LNS discards the packet and sends a ZLB) <- ZLB Nr: 3, Ns: 2 (LNS's retransmit timer fires) <- ICRP Nr: 3, Ns: 1 ICCN -> Nr: 2, Ns: 3 <- ZLB Nr: 4, Ns: 2 Appendix C: Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Townsley, et al. Standards Track [Page 76] INTERNET DRAFT L2TP November 2000 The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Townsley, et al. Standards Track [Page 77] From owner-l2tp@diameter.org Mon Nov 27 17:26:45 2000 Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00683 for ; Mon, 27 Nov 2000 17:26:44 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eARLAqk07212 for l2tp-list; Mon, 27 Nov 2000 13:10:52 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eARL9XH07206 for ; Mon, 27 Nov 2000 13:09:33 -0800 Received: from cisco.com (rtp7-dhcp-58-126.cisco.com [161.44.58.126]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA04865 for ; Mon, 27 Nov 2000 12:16:37 -0800 (PST) Message-ID: <3A22C04C.1992515B@cisco.com> Date: Mon, 27 Nov 2000 15:13:00 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: l2tp@l2tp.net Subject: Re: Call for L2TPEXT Agenda Items for the 49th IETF in San Diego, CA References: <3A1DF375.A2074B64@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a note. Even if you think I know you are presenting, please respond to this email so I have an accurate record and do not forget anyone. Thanks, - Mark "W. Mark Townsley" wrote: > > We are currently scheduled to meet 1300-1500, Afternoon Sessions I, > on THURSDAY, December 14, 2000. > > Please send me requests to make presentations. > Be sure to include all of the below: > > 1) Name of presenter, including e-mail address > 2) Title of presentation > 3) Internet draft name, if applicable > 4) Amount of time requested > > Thanks, > > - Mark From owner-l2tp@diameter.org Mon Nov 27 18:21:03 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16051 for ; Mon, 27 Nov 2000 18:21:02 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eARLXXs07296 for l2tp-list; Mon, 27 Nov 2000 13:33:33 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from postal.redback.com (hiddenuser@postal.redback.com [155.53.12.9]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eARLXUH07290 for ; Mon, 27 Nov 2000 13:33:30 -0800 Received: from stile.redback.com (stile.redback.com [155.53.36.12]) by postal.redback.com (Postfix) with ESMTP id 4983B17BC13 for ; Mon, 27 Nov 2000 12:40:40 -0800 (PST) Received: (from suhail@localhost) by stile.redback.com (8.8.8/8.8.8/null redback bsdclient) id MAA20482; Mon, 27 Nov 2000 12:40:40 -0800 (PST) From: Suhail Nanji MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 27 Nov 2000 12:40:40 -0800 (PST) To: l2tp@l2tp.net Subject: New Ethernet over L2TP draft based on Service Type draft X-Mailer: VM 6.43 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Message-ID: <14882.50859.66496.977317@stile.redback.com> Reply-To: suhail@redback.com (Suhail Nanji) Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Network Working Group Suhail Nanji INTERNET DRAFT Redback Networks, Inc. Category: Standards Track Title: draft-ietf-l2tpext-eth-00.txt Date: November 2000 Ethernet Service Type for Layer Two Tunneling Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires May, 2001. Please send comments to the authors. Abstract The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. In accordance with the Layer Two Tunneling Protocol (L2TP) Service Type draft [L2TP_svctype], this document describes the details for transporting Ethernet frames over a session in an L2TP tunnel. That is, the details of an Ethernet service type for L2TP sessions. Nanji [Page1] INTERNET DRAFT November 2000 1. Introduction With L2TP it is possible to divorce the location of the initial dial- up server from the location at which the dial-up protocol connection is terminated and access to the network provided. However, this is only possible if PPP is used to access the network. The L2TP Service Type draft describes how other payload types may be tunneled on a session by session basis over L2TP. This document describes how Ethernet frames may be tunneled over an L2TP session as a new service type as described by the L2TP Service Type draft. It is possible to use PPP Bridging Control Protocol (BCP) as specified in [RFC2878] to transport the Ethernet frame over L2TP without employing a new service type. However, using BCP might not be feasible since the Ethernet client may not support BCP. Furthermore, the service type approach has less protocol overhead than using BCP. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. Ethernet in this document refers to both DIX Ethernet and IEEE 802.3. It is assumed the receipient of an Ethernet frame has the capabilities to distinguish between the two different Ethernet encapsulations. Both Ethernet types MAY be used on the same L2TP session. 3. Ethernet Service Type A Ethernet srvice type value of 3 MUST be used for the L2TP Service Type draft to identify an Ethernet payload. 4. Tunnel Establishment The basic tunnel establishment procedures defined in [RFC2661] and [L2TP_svctype] draft are unchanged. The Ethernet service type value MUST be included in the Service Capabilities List AVP. Nanji [Page2] INTERNET DRAFT November 2000 5. Session Establishment The basic call establishment procedures defined in [RFC2661] and [L2TP_svctype] are unchanged. Currently, Ethernet framing is only supported for incoming call requests (ICRQ). The Ethernet service type value MUST be used in the Service Type AVP of an ICRQ. The Ethernet service type value MUST NOT be used in the Service Type AVP of an OCRQ. Also, a new AVP MUST be included in the ICRQ which contains an Ethernet MAC address from the LAC. 5.1 Ethernet MAC Address AVP Ethernet MAC Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ethernet MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Ethernet MAC Address AVP contains an Ethernet MAC address from the LAC in canonical form as specified in [RFC2469]. This value MUST be used as the source address for Ethernet frames sent to tunneled end stations from the LNS. The vendor code is 0 and the Attribute value is TBD. This AVP MUST NOT have the manditory bit set. The Value is a 48-bit Ethernet MAC address. 6. Ethernet Payload Message Format The L2TP payload header will be unchanged and as described in [RFC2661]. However, instead of carrying a PPP packet, the payload will carry an Ethernet frame starting from the MAC addresses, which MUST be in canonical form as specified in [RFC2469]. In both types of Ethernet frames, the CRC is preserved end-to-end. Nanji [Page3] INTERNET DRAFT November 2000 DIX Ethernet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IEEE 802.3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | DSAP | SSAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CTL | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nanji [Page4] INTERNET DRAFT November 2000 7. Effects on Standard AVPs If Ethernet frames are being tunneled in accordance with this document, then the following Call Management AVPs MAY be ignored: Bearer Type Framing Type Called Number Calling Number Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response ACCM 8. Authentication Considerations All issues dealing with authenticating the incoming Ethernet client are beyond the scope of this document. 9. Security Considerations All security considerations with tunneling Ethernet frames over L2TP are beyond the scope of this document. 10. Acknowledgments Thanks to Bill Palter, Danny McPherson, Mark Townsley and Wei Luo for their help in reviewing this draft. Copious amounts of text were stolen from [RFC2661]. Nanji [Page5] INTERNET DRAFT November 2000 11. References [RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC 2661, February 1999. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [L2TP_svctype] McPherson D., Nanji S., "L2TP Service Type", August 2000. [RFC2469] T. Narten, C. Burton, "A Caution On The Canonical Ordering Of Link-Layer Addresses", RFC 2469, December 1998. [RFC2878] M. Higashiyama, F. Baker, "PPP Bridging Control Protocol (BCP)", RFC 2878, July 2000. Authors' Addresses: Suhail Nanji Redback Networks, Inc. 350 Holger Way San Jose, CA 95134-1362 United States of America Nanji [Page6] From owner-l2tp@diameter.org Tue Nov 28 06:57:12 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28746 for ; Tue, 28 Nov 2000 06:57:11 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eASAjRg08614 for l2tp-list; Tue, 28 Nov 2000 02:45:27 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eASAjLH08608 for ; Tue, 28 Nov 2000 02:45:21 -0800 Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 28 Nov 2000 09:52:14 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA08650; Tue, 28 Nov 2000 09:52:14 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C12569A5.0035C5D1 ; Tue, 28 Nov 2000 10:47:20 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Luigi Campora" To: l2tp@l2tp.net Message-ID: Date: Tue, 28 Nov 2000 10:48:25 +0100 Subject: sequence numbering on the data channel Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-l2tp@diameter.org Precedence: bulk Dear subscribers, what happens generally if a LAC irrimediably looses the value of the Ns counter on the data channel? (suppose the PPP session being tunnelled carries IP). Is there any vendor whose LNSs close the session in case of this event? thank you in advance for your reply luigi From owner-l2tp@diameter.org Tue Nov 28 10:28:37 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21327 for ; Tue, 28 Nov 2000 10:28:36 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eASEPKu09076 for l2tp-list; Tue, 28 Nov 2000 06:25:20 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eASEPHH09070 for ; Tue, 28 Nov 2000 06:25:17 -0800 Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id FAA13149; Tue, 28 Nov 2000 05:32:23 -0800 (PST) Message-ID: <3A23B30B.F4AD45E3@cisco.com> Date: Tue, 28 Nov 2000 08:28:43 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Luigi Campora CC: l2tp@l2tp.net Subject: Re: sequence numbering on the data channel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Luigi Campora wrote: > > Dear subscribers, > what happens generally if a LAC irrimediably looses the value of the > Ns counter on the data channel? The data channel MAY sequence data packets, but never retransmits them. > (suppose the PPP session being tunnelled carries IP). > Is there any vendor whose LNSs close the session in case of this event? This would be a pretty serious violation of the RFC. > > thank you in advance for your reply > > luigi From owner-l2tp@diameter.org Tue Nov 28 12:32:57 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10352 for ; Tue, 28 Nov 2000 12:32:57 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eASFg7x09234 for l2tp-list; Tue, 28 Nov 2000 07:42:07 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eASFg2H09228 for ; Tue, 28 Nov 2000 07:42:02 -0800 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22096 for ; Tue, 28 Nov 2000 07:49:14 -0700 (MST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA03305 for ; Tue, 28 Nov 2000 06:49:08 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA18373 for ; Tue, 28 Nov 2000 06:49:07 -0800 (PST) Date: Tue, 28 Nov 2000 06:46:09 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: BOUNCE l2tp@diameter.org: Non-member submission from [Internet-Drafts@ietf.org] (Fwd) To: l2tp@l2tp.net In-Reply-To: "Your message with ID" <200011281153.eASBrjO08741@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk All, Here is an e-mail from Internet Drafts. I had a problem with my Majordomo configuration that I fixed yesterday, but bounced e-mail was not being delivered to the correct address. Now that I am receiving bounces (and boy, am I receiving them!) I will start to correct problems I notice. I had to figure out a way to allow for Internet-Drafts@ietf.org to be able to post to the list, but NOT forward mailing list e-mail to them. PatC >----------------Begin Forwarded Message----------------< Date: Tue, 28 Nov 2000 03:53:45 -0800 From: owner-l2tp@diameter.org Subject: BOUNCE l2tp@diameter.org: Non-member submission from [Internet-Drafts@ietf.org] To: l2tp-approval@diameter.org From pcalhoun@eng.sun.com Tue Nov 28 03:53:41 2000 Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eASBrfH08735 for ; Tue, 28 Nov 2000 03:53:41 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id DAA05745 for ; Tue, 28 Nov 2000 03:00:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04250; Tue, 28 Nov 2000 06:00:39 -0500 (EST) Message-Id: <200011281100.GAA04250@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: l2tp@ipsec.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tp-mib-01.txt Date: Tue, 28 Nov 2000 06:00:39 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol 'L2TP' Management Information Base Author(s) : E. Caves, P. Calhoun, R. Wheeler Filename : draft-ietf-l2tpext-l2tp-mib-01.txt Pages : 73 Date : 27-Nov-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-l2tp-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2tpext-l2tp-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001127133143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-l2tp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-l2tp-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001127133143.I-D@ietf.org> --OtherAccess-- --NextPart-- >----------------End Forwarded Message----------------< From owner-l2tp@diameter.org Wed Nov 29 07:08:24 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20075 for ; Wed, 29 Nov 2000 07:08:23 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATB0qQ10510 for l2tp-list; Wed, 29 Nov 2000 03:00:52 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATB0nH10504 for ; Wed, 29 Nov 2000 03:00:49 -0800 Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id CAA08153 for ; Wed, 29 Nov 2000 02:07:58 -0800 (PST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id eATA7Id07321 for ; Wed, 29 Nov 2000 11:07:18 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id LAA24952 for ; Wed, 29 Nov 2000 11:07:18 +0100 (MET) Received: from vies141a.sie.siemens.at(195.1.196.56) by scesie13 via smap (V2.0beta) id xma022035; Wed, 29 Nov 00 11:05:34 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 11:05:32 +0100 Message-ID: From: Klausberger Walter To: l2tp@ipsec.org Subject: ifStackTable layering in L2TP Date: Wed, 29 Nov 2000 11:05:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-l2tp@diameter.org Precedence: bulk Hi everybody, I started to read the new L2TP-MIB draft and I already have several questions... As I understood stacking should be made visible up to the 'forwarding layer'(e.g. IP). When looking at common ifStackTables I never saw an IP layer until yet. So there should be no layer above Ethernet when transporting IP packets... As an example in the tunnel interface in the LNS is set on top of an Ethernet interface. But L2TP is never set directly above Ethernet, but will be transported via UDP/IP. So there is no direct context. The connection depends on the routing table. Assume there is an LNS with an Ethernet and an unnumbered Frame Relay interface. First the tunnel is setup via Ethernet IF. Due to the entries in the routing table, the tunnel IF is set on top of the ethernet IF. Now a problem occurs in the backbone and the connection is switched over to the unnumbered Frame Relay IF (same IP address). Would this need a change in the ifStackTable? It is possible to transport L2TP directly over ATM or via UDP/IP/ATM. Would there be no difference in the ifStackTable? In case of LAC it is even more unclear to me how the ifStackTable will look like. In former L2TP-MIB drafts it was stated that the tunnel IF sits on top of the interfaces that forward the PPP packets (e.g. DS0). Now there is a reference to the tunnel MIB (RFC 2667) and everything seems to be different now. Do we have a problem here with unnumbered IP interfaces, because... Tunnels are handled by creating a logical interface (ifEntry) for each tunnel. These are then correlated, using the ifStack table of the Interfaces MIB, to those interfaces on which the local IPv4 addresses of the tunnels are configured. ...or do I have to take the numbered Ethernet IF for the ifStackTable, even if the tunnel is connected via Frame Relay IF? Or am I totally wrong? just some questions, I hope someone can answer... with best regards Walter From owner-l2tp@diameter.org Wed Nov 29 08:35:44 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23299 for ; Wed, 29 Nov 2000 08:35:44 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATCNSV10800 for l2tp-list; Wed, 29 Nov 2000 04:23:28 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATCNKH10792 for ; Wed, 29 Nov 2000 04:23:20 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id DAA09507 for ; Wed, 29 Nov 2000 03:30:33 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01316; Wed, 29 Nov 2000 06:30:26 -0500 (EST) Message-Id: <200011291130.GAA01316@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: l2tp@ipsec.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-eth-00.txt Date: Wed, 29 Nov 2000 06:30:25 -0500 Sender: owner-l2tp@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Ethernet Service Type for Layer Two Tunneling Protocol Author(s) : S. Nanji Filename : draft-ietf-l2tpext-eth-00.txt Pages : 6 Date : 28-Nov-00 The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. In accordance with the Layer Two Tunneling Protocol (L2TP) Service Type draft [L2TP_svctype], this document describes the details for transporting Ethernet frames over a session in an L2TP tunnel. That is, the details of an Ethernet service type for L2TP sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-eth-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-eth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2tpext-eth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-eth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-eth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134325.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Wed Nov 29 08:56:18 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00558 for ; Wed, 29 Nov 2000 08:56:18 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATCNZ610804 for l2tp-list; Wed, 29 Nov 2000 04:23:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATCNKH10791 for ; Wed, 29 Nov 2000 04:23:20 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id DAA09506 for ; Wed, 29 Nov 2000 03:30:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01356; Wed, 29 Nov 2000 06:30:30 -0500 (EST) Message-Id: <200011291130.GAA01356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: l2tp@ipsec.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-fr-01.txt Date: Wed, 29 Nov 2000 06:30:30 -0500 Sender: owner-l2tp@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol (L2TP) over Frame Relay Author(s) : V. Rawat, R. Tio, R. Verma, S. Nanji Filename : draft-ietf-l2tpext-fr-01.txt Pages : 7 Date : 28-Nov-00 Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over Frame Relay PVCs and SVCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-fr-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-fr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2tpext-fr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001128134336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-fr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-fr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001128134336.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Wed Nov 29 10:01:31 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25214 for ; Wed, 29 Nov 2000 10:01:31 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATDT8D10900 for l2tp-list; Wed, 29 Nov 2000 05:29:08 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATDT5H10894 for ; Wed, 29 Nov 2000 05:29:05 -0800 Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA09553 for ; Wed, 29 Nov 2000 04:36:19 -0800 (PST) Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 07:35:05 -0500 Received: from globespan.net (india.globespan.net [172.25.2.100]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XDX5R2S3; Wed, 29 Nov 2000 07:34:51 -0500 Received: from globespan.net (jkochar.india.ficon-tech.com [172.25.1.102]) by globespan.net (8.9.3/8.9.3) with ESMTP id SAA01580; Wed, 29 Nov 2000 18:02:49 +0530 (IST) (envelope-from jkochar@globespan.net) From: Jhilmil Kochar To: Pat Calhoun Cc: l2tp@l2tp.net, l2tp@ipsec.org Message-ID: <3A24F99F.841C9D51@globespan.net> Date: Wed, 29 Nov 2000 18:12:07 +0530 X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: BOUNCE l2tp@diameter.org: Non-member submission from [Internet-Drafts@ietf.org] (Fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had a question on the L2TP MIB draft. Is the object l2tpDomainConfigSecret assumed to be an OCTET STRING or a DISPLAY STRING. The MIB defines it to be a variable length OCTET STRING. In such a case, it can have null characters and then its length also must be configured. Else if it is a Null terminated string, it should be of syntax DISPLAY STRING. Thanks in advance Jhilmil - ------------------------------ Jhilmil Kochar Globespan India E-mail:mailto:jkochar@globespan.net Web: http://www.globespan.net From owner-l2tp@diameter.org Wed Nov 29 10:03:45 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26302 for ; Wed, 29 Nov 2000 10:03:45 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATDORW10880 for l2tp-list; Wed, 29 Nov 2000 05:24:27 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATDONH10874 for ; Wed, 29 Nov 2000 05:24:23 -0800 Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id EAA09550 for ; Wed, 29 Nov 2000 04:31:37 -0800 (PST) Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 07:30:13 -0500 Received: from globespan.net (india.globespan.net [172.25.2.100]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XDX5R2R6; Wed, 29 Nov 2000 07:29:58 -0500 Received: from globespan.net (jkochar.india.ficon-tech.com [172.25.1.102]) by globespan.net (8.9.3/8.9.3) with ESMTP id RAA01512; Wed, 29 Nov 2000 17:57:54 +0530 (IST) (envelope-from jkochar@globespan.net) From: Jhilmil Kochar To: William Mark Townsley Cc: l2tp@l2tp.net, l2tp@ipsec.org Message-ID: <3A24F877.544A4E25@globespan.net> Date: Wed, 29 Nov 2000 18:07:11 +0530 X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Please post draft-ietf-l2tpext-l2tpbis-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had two questions regarding the latest L2TP draft. 1.section 4.3. AVP Hiding. "The H bit MUST only be set if a shared secret exists between the LAC and LNS and tunnel authentication has completed. The shared secret is the same secret that is used for tunnel authentication (see section 5.1.1). Hidden values MUST NOT be unhidden until after tunnel authentication has completed successfully (perhaps requiring the hidden value to be stored until after receipt of additional setup messages). To do otherwise runs the risk of AVP data being utilized without verifying the integrity of the shared secret. If the H bit is set in any AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1." I am a little confused with this paragraph. I will mention my interpretation of this. Please correct me if I go wrong. a) If peer is sending SCCRQ and does not use any authentication, then it may hide AVPs in the messsage. b) If peer is sending SCCRQ and uses some tunnel authentication procedure (CHAP or hostname), then it MUST not hide any AVPs in the messsage (SCCRQ). c) On receiving side, for SCCRQ, the peer will need to have a 2 step procedure for decoding, first it should decode Hostname and use that to identify the tunnel (or some other means to identify the tunnel), get the shared secret, once it has been identified, then decode the hidden AVPs of that message. OR, does the peer need to wait for further messages (that may contain CHAP response) before it can decode hidden AVPs? Under what condition will additional setup messages be awaited for? When we say authentication, is it local , or at the remote end, ie if the local peer has received CHAP resp and has authenticated, it talks of that , or after sending a message and getting a SCCCN indicating that peer authentication is complete. Please clarify the various scenarios here for both peers identifying who can enable AVP hiding and when based on whether they are using CHAP, or authentication using hostname or no authentication. 2. section 4.4.4. "If the CDN is sent before an Assigned Session ID is communicated (e.g. in response to an ICRQ), it MUST NOT be sent in the CDN message." Does this also imply that this SHOULD not be retransmitted as in the case of Stop CCN in this case? Thanks in advance for the response. regards Jhilmil ------------------------------ Jhilmil Kochar Globespan India E-mail:mailto:jkochar@globespan.net Web: http://www.globespan.net From owner-l2tp@diameter.org Wed Nov 29 10:06:28 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27475 for ; Wed, 29 Nov 2000 10:06:27 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATDSfu10892 for l2tp-list; Wed, 29 Nov 2000 05:28:41 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATDScH10886 for ; Wed, 29 Nov 2000 05:28:38 -0800 Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 07:35:05 -0500 Received: from globespan.net (india.globespan.net [172.25.2.100]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XDX5R2S3; Wed, 29 Nov 2000 07:34:51 -0500 Received: from globespan.net (jkochar.india.ficon-tech.com [172.25.1.102]) by globespan.net (8.9.3/8.9.3) with ESMTP id SAA01580; Wed, 29 Nov 2000 18:02:49 +0530 (IST) (envelope-from jkochar@globespan.net) From: Jhilmil Kochar To: Pat Calhoun Cc: l2tp@l2tp.net, l2tp@ipsec.org Message-ID: <3A24F99F.841C9D51@globespan.net> Date: Wed, 29 Nov 2000 18:12:07 +0530 X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: BOUNCE l2tp@diameter.org: Non-member submission from [Internet-Drafts@ietf.org] (Fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had a question on the L2TP MIB draft. Is the object l2tpDomainConfigSecret assumed to be an OCTET STRING or a DISPLAY STRING. The MIB defines it to be a variable length OCTET STRING. In such a case, it can have null characters and then its length also must be configured. Else if it is a Null terminated string, it should be of syntax DISPLAY STRING. Thanks in advance Jhilmil - ------------------------------ Jhilmil Kochar Globespan India E-mail:mailto:jkochar@globespan.net Web: http://www.globespan.net From owner-l2tp@diameter.org Wed Nov 29 10:07:43 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28042 for ; Wed, 29 Nov 2000 10:07:42 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATDNpc10872 for l2tp-list; Wed, 29 Nov 2000 05:23:51 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from rambo.globespan.net (p1.globespan.net [209.191.59.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATDNkH10866 for ; Wed, 29 Nov 2000 05:23:47 -0800 Received: by rambo.globespan.net with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Nov 2000 07:30:13 -0500 Received: from globespan.net (india.globespan.net [172.25.2.100]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XDX5R2R6; Wed, 29 Nov 2000 07:29:58 -0500 Received: from globespan.net (jkochar.india.ficon-tech.com [172.25.1.102]) by globespan.net (8.9.3/8.9.3) with ESMTP id RAA01512; Wed, 29 Nov 2000 17:57:54 +0530 (IST) (envelope-from jkochar@globespan.net) From: Jhilmil Kochar To: William Mark Townsley Cc: l2tp@l2tp.net, l2tp@ipsec.org Message-ID: <3A24F877.544A4E25@globespan.net> Date: Wed, 29 Nov 2000 18:07:11 +0530 X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Please post draft-ietf-l2tpext-l2tpbis-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had two questions regarding the latest L2TP draft. 1.section 4.3. AVP Hiding. "The H bit MUST only be set if a shared secret exists between the LAC and LNS and tunnel authentication has completed. The shared secret is the same secret that is used for tunnel authentication (see section 5.1.1). Hidden values MUST NOT be unhidden until after tunnel authentication has completed successfully (perhaps requiring the hidden value to be stored until after receipt of additional setup messages). To do otherwise runs the risk of AVP data being utilized without verifying the integrity of the shared secret. If the H bit is set in any AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1." I am a little confused with this paragraph. I will mention my interpretation of this. Please correct me if I go wrong. a) If peer is sending SCCRQ and does not use any authentication, then it may hide AVPs in the messsage. b) If peer is sending SCCRQ and uses some tunnel authentication procedure (CHAP or hostname), then it MUST not hide any AVPs in the messsage (SCCRQ). c) On receiving side, for SCCRQ, the peer will need to have a 2 step procedure for decoding, first it should decode Hostname and use that to identify the tunnel (or some other means to identify the tunnel), get the shared secret, once it has been identified, then decode the hidden AVPs of that message. OR, does the peer need to wait for further messages (that may contain CHAP response) before it can decode hidden AVPs? Under what condition will additional setup messages be awaited for? When we say authentication, is it local , or at the remote end, ie if the local peer has received CHAP resp and has authenticated, it talks of that , or after sending a message and getting a SCCCN indicating that peer authentication is complete. Please clarify the various scenarios here for both peers identifying who can enable AVP hiding and when based on whether they are using CHAP, or authentication using hostname or no authentication. 2. section 4.4.4. "If the CDN is sent before an Assigned Session ID is communicated (e.g. in response to an ICRQ), it MUST NOT be sent in the CDN message." Does this also imply that this SHOULD not be retransmitted as in the case of Stop CCN in this case? Thanks in advance for the response. regards Jhilmil ------------------------------ Jhilmil Kochar Globespan India E-mail:mailto:jkochar@globespan.net Web: http://www.globespan.net From owner-l2tp@diameter.org Wed Nov 29 11:32:00 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00440 for ; Wed, 29 Nov 2000 11:31:59 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATEqcC10989 for l2tp-list; Wed, 29 Nov 2000 06:52:38 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.69.24.144]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATEpIH10983 for ; Wed, 29 Nov 2000 06:51:18 -0800 Received: from cisco.com (townsley-home-1.cisco.com [161.44.99.51]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id FAA18767; Wed, 29 Nov 2000 05:58:27 -0800 (PST) Message-ID: <3A250A9E.8B32BF7@cisco.com> Date: Wed, 29 Nov 2000 08:54:38 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jhilmil Kochar CC: l2tp@l2tp.net Subject: Re: Please post draft-ietf-l2tpext-l2tpbis-01.txt References: <3A24F877.544A4E25@globespan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Rereading this, I believe the first sentence is confusing. It should read "The H bit MUST only be set if a shared secret exists between the LAC and LNS and tunnel authentication is enabled." Completion of tunnel authentication has nothing to do with *setting* the H bit. The most important point I was trying to make is covered in the third sentence, "Hidden values MUST NOT be unhidden until..." Answers to your questions below: Jhilmil Kochar wrote: > > Hi, > I had two questions regarding the latest L2TP draft. > > 1.section 4.3. AVP Hiding. > "The H bit MUST only be set if a shared secret exists between the LAC > and LNS and tunnel authentication has completed. The shared secret is > the same secret that is used for tunnel authentication (see section > 5.1.1). Hidden values MUST NOT be unhidden until after tunnel > authentication has completed successfully (perhaps requiring the > hidden value to be stored until after receipt of additional setup > messages). To do otherwise runs the risk of AVP data being utilized > without verifying the integrity of the shared secret. If the H bit is > set in any AVP(s) in a given control message, a Random Vector AVP > must also be present in the message and MUST precede the first AVP > having an H bit of 1." > > I am a little confused with this paragraph. I will mention my interpretation of > this. Please correct me if I go wrong. > a) If peer is sending SCCRQ and does not use any authentication, then it > may hide AVPs in the messsage. No, it may NOT hide AVPs if authentication is turned off. > b) If peer is sending SCCRQ and uses some tunnel authentication procedure (CHAP > or hostname), then it MUST not hide any AVPs in the messsage (SCCRQ). Hostname is not a tunnel authentication procedure, only CHAP is. You have it backwards, you may only hide if tunnel auth is configured and unhide AVPs if tunnel auth occurred. > c) On receiving side, for SCCRQ, the peer will need to have a 2 step procedure > for decoding, first it should decode Hostname and use that to identify the > tunnel (or some other means to identify the tunnel), get the shared secret, > once it has been identified, then decode the hidden AVPs of that message. > OR, does the peer need to wait for further messages (that may contain CHAP > response) before it can decode hidden AVPs? Under what condition will > additional setup messages be awaited for? When we say authentication, is it > local , or at the remote end, ie if the local peer has received CHAP resp and > has authenticated, it talks of that , or after sending a message and getting a > SCCCN indicating that peer authentication is complete. The idea is that if you do receive any hidden AVPs in the SCCxxx messages, you should wait until your peer has been authenticated before unhiding the values. To do otherwise risks unhiding with an incorrect password and sending bogus values into your AVP processing logic. If there were a checksum of sorts on each AVP being unhidden, this would not be a problem. As it stands, if tunnel auth is not configured and a shared secret is used for hiding/unhiding that does not match between the LAC and LNS, there is no way to verify the integrity of the unhidden value. > > Please clarify the various scenarios here for both peers identifying who can > enable AVP hiding and when based on whether they are using CHAP, or > authentication using hostname or no authentication. > > 2. section 4.4.4. > "If the CDN is sent before an Assigned Session ID > is communicated (e.g. in response to an ICRQ), it MUST NOT be sent > in the CDN message." > Does this also imply that this SHOULD not be retransmitted as in the case of > Stop CCN in this case? Additional text was included for the Assigned Tunnel ID AVP in the StopCCN as well, if that is what you mean. The StopCCN never contains an Assigned Session ID AVP. > > Thanks in advance for the response. > > regards > Jhilmil > > ------------------------------ > Jhilmil Kochar > Globespan India > E-mail:mailto:jkochar@globespan.net > Web: http://www.globespan.net From owner-l2tp@diameter.org Wed Nov 29 12:51:26 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00690 for ; Wed, 29 Nov 2000 12:51:26 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATG5Zq11080 for l2tp-list; Wed, 29 Nov 2000 08:05:35 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATG5UH11074 for ; Wed, 29 Nov 2000 08:05:30 -0800 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14867; Wed, 29 Nov 2000 07:12:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA18947; Wed, 29 Nov 2000 07:12:39 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21489; Wed, 29 Nov 2000 07:12:35 -0800 (PST) Date: Wed, 29 Nov 2000 07:09:36 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: l2tpDomainConfigSecret To: Jhilmil Kochar Cc: Pat Calhoun , l2tp@l2tp.net In-Reply-To: "Your message with ID" <3A24F99F.841C9D51@globespan.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk > Hi, > I had a question on the L2TP MIB draft. > Is the object l2tpDomainConfigSecret assumed to be an OCTET STRING or a > DISPLAY STRING. The MIB defines it to be a variable length OCTET STRING. In > such a case, it can have null characters and then its length also must be > configured. Else if it is a Null terminated string, it should be of syntax > DISPLAY STRING. > It would be a big mistake to make it a DISPLAY STRING. A secret SHOULD consist of ANY characters, not just ASCII printable ones. Of course, entering non-printable characters on a console is more complicated (during configuration), but that shouldn't limit the field type. PatC From owner-l2tp@diameter.org Wed Nov 29 16:32:59 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14007 for ; Wed, 29 Nov 2000 16:32:53 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eATJ2Pc11476 for l2tp-list; Wed, 29 Nov 2000 11:02:25 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from cdsinet.net (server1.cdsinet.net [38.195.110.10]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eATJ2AH11470 for ; Wed, 29 Nov 2000 11:02:12 -0800 Received: from dns1.cdsinet.net [38.195.110.12] by cdsinet.net with ESMTP (SMTPD32-6.03) id A6447BB03DE; Wed, 29 Nov 2000 12:09:08 -0600 Date: Wed, 29 Nov 2000 12:09:08 -0600 (CST) From: John Narron To: l2tp@l2tp.net Subject: L2F/L2TP emulators Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk Is there any software (preferrably freeware) available to emulate LACs and LNSs? I'd figure there would be to help troubleshoot tunnels, but I'm not having an easy time finding them. Any help would be appreciated. Thanks. - John From owner-l2tp@diameter.org Thu Nov 30 00:06:29 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19609 for ; Thu, 30 Nov 2000 00:06:29 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAU2LQD12747 for l2tp-list; Wed, 29 Nov 2000 18:21:26 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from center.mshindo.net (center.mshindo.net [210.231.221.221]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAU2LAH12739 for ; Wed, 29 Nov 2000 18:21:11 -0800 Received: from localhost (IDENT:mshindo@dhcp16.cosinecom.co.jp [202.229.42.16]) by center.mshindo.net (8.9.3/3.7W/00041811) with ESMTP id KAA02475; Thu, 30 Nov 2000 10:47:47 +0900 (JST) Date: Thu, 30 Nov 2000 10:28:39 +0900 (JST) Message-Id: <20001130.102839.74756154.mshindo@mshindo.net> To: zeek@cdsinet.net Cc: l2tp@l2tp.net Subject: Re: L2F/L2TP emulators From: Motonori Shindo In-Reply-To: References: X-Mailer: Mew version 1.95b76 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit John, From: John Narron Subject: L2F/L2TP emulators Date: Wed, 29 Nov 2000 12:09:08 -0600 (CST) Message-ID: > Is there any software (preferrably freeware) available to emulate > LACs and LNSs? I'd figure there would be to help troubleshoot > tunnels, but I'm not having an easy time finding them. Any help > would be appreciated. Thanks. > > - John There's an L2TP (LAC & LNS) implementation available that can be retrieved via anonymous CVS as follows: export CVSROOT=:pserver:anoncvs@marko.net:/usr/share/cvsroot (for bash) cvs login (password is anoncvs) cvs co l2tpd (checks out a copy of the l2tpd cvs tree) cvs update (be in the l2tpd directory, updates your tree) It hasn't been updated for a long time and there are some bugs but it works anyway:-) I am not aware of any L2F implementation. Sorry. Regards, =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= From owner-l2tp@diameter.org Thu Nov 30 08:44:39 2000 Received: from charizard.diameter.org (nobody@c900656-a.plstn1.sfba.home.com [24.20.167.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07775 for ; Thu, 30 Nov 2000 08:44:38 -0500 (EST) Received: (from majordomo@localhost) by charizard.diameter.org (8.10.0/8.10.0) id eAUBo0d13592 for l2tp-list; Thu, 30 Nov 2000 03:50:00 -0800 X-Authentication-Warning: charizard.diameter.org: majordomo set sender to owner-l2tp@diameter.org using -f Received: from ns1.sailpix.com (ns1.sailpix.com [155.53.1.250]) by charizard.diameter.org (8.10.0/8.10.0) with ESMTP id eAUBngH13586 for ; Thu, 30 Nov 2000 03:49:42 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns1.sailpix.com (8.8.8/8.6.9) with ESMTP id CAA10840 for ; Thu, 30 Nov 2000 02:56:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27825; Thu, 30 Nov 2000 05:56:55 -0500 (EST) Message-Id: <200011301056.FAA27825@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: l2tp@ipsec.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tpbis-01.txt Date: Thu, 30 Nov 2000 05:56:55 -0500 Sender: owner-l2tp@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol 'L2TP' Author(s) : W. Townsley, A. Valencia, G. Zorn, A. Rubens, G. Pall, B. Palter Filename : draft-ietf-l2tpext-l2tpbis-01.txt Pages : 77 Date : 29-Nov-00 This document describes the Layer Two Tunneling Protocol (L2TP). RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tpbis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-l2tpbis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2tpext-l2tpbis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001129114509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-l2tpbis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-l2tpbis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129114509.I-D@ietf.org> --OtherAccess-- --NextPart--