From owner-l2tp@diameter.org Thu Jul 5 16:14:32 2001 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 QAA26159 for ; Thu, 5 Jul 2001 16:14:31 -0400 (EDT) Received: (qmail 445 invoked by alias); 5 Jul 2001 19:56:07 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 439 invoked by uid 200); 5 Jul 2001 19:56:07 -0000 Received: (qmail 434 invoked from network); 5 Jul 2001 19:56:00 -0000 Received: from unknown (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jul 2001 19:56:00 -0000 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA28442 for ; Thu, 5 Jul 2001 15:08:59 -0500 (CDT) Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com; Thu, 5 Jul 2001 12:59:45 -0700 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <325NMPT4>; Thu, 5 Jul 2001 13:06:57 -0700 Message-ID: From: "Reinaldo Penno" To: "'l2tp@l2tp.net'" Subject: I-D ACTION:draft-penno-l2tp-switching-00.txt Date: Thu, 5 Jul 2001 13:06:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1058E.09C8E420" 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_01C1058E.09C8E420 Content-Type: text/plain; charset="iso-8859-1" A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L2TP Tunnel Switching Author(s) : V. Jain, R. Penno, S. McGeown Filename : draft-penno-l2tp-switching-00.txt Pages : Date : 03-Jul-01 For some time now several equipment manufactures have been implementing what is called L2TP tunnel switching or L2TP multihop. Although this technology has several applications and is quite widespread, there has been no effort to standardize the nomenclature and methods associated with it. The goal of this document is to achieve a common denominator in what is tunnel switching, its advantages and nomenclature associated with it . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-l2tp-switching-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-penno-l2tp-switching-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 The information transmitted in this message is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, copying, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender and delete the material from all computers. ------_=_NextPart_001_01C1058E.09C8E420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-penno-l2tp-switching-00.txt

A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = L2TP Tunnel Switching
        Author(s)       : V. Jain, R. = Penno, S. McGeown
        Filename        : = draft-penno-l2tp-switching-00.txt
        Pages           : =
        Date    =         : 03-Jul-01
       =20
For some time now several equipment manufactures = have been
implementing what is called L2TP tunnel switching or = L2TP multihop.
Although this technology has several applications = and is quite
widespread, there has been no effort to standardize = the nomenclature
and methods associated with it.
The goal of this document is to achieve a common = denominator in what
is tunnel switching, its advantages and nomenclature = associated with
it .

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-penno-l2tp-s= witching-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-penno-l2tp-switching-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


The information transmitted in this message is = intended only for the person or entity to which it is addressed and may = contain confidential and/or privileged material. Any review, copying, = disclosure or other use of, or taking of any action in reliance upon, = this information by persons or entities other than the intended = recipient is prohibited. If you received this message in error, please = contact the sender and delete the material from all computers.  =

 

------_=_NextPart_001_01C1058E.09C8E420-- From owner-l2tp@diameter.org Fri Jul 6 06:50:01 2001 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 GAA25766 for ; Fri, 6 Jul 2001 06:49:58 -0400 (EDT) Received: (qmail 1954 invoked by alias); 6 Jul 2001 10:03:18 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 1948 invoked by uid 200); 6 Jul 2001 10:03:18 -0000 Received: (qmail 1943 invoked from network); 6 Jul 2001 10:03:16 -0000 Received: from zrc2s03g.nortelnetworks.com (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jul 2001 10:03:16 -0000 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id FAA27275 for ; Fri, 6 Jul 2001 05:16:15 -0500 (CDT) Received: from zsc4c002.us.nortel.com by zsc4s001.baynetworks.com; Fri, 6 Jul 2001 03:07:11 -0700 Received: by zsc4c002.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3L8TJL97>; Fri, 6 Jul 2001 03:14:24 -0700 Message-ID: <4F973E944951D311B6660008C7917CF0061132E8@zsc4c008.us.nortel.com> From: "Vipin Jain" To: "'Elwin Eliazer'" , l2tp@l2tp.net Subject: RE: Session update messages for L2TP ... Date: Fri, 6 Jul 2001 03:07:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10603.892B7640" 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_01C10603.892B7640 Content-Type: text/plain; charset="ISO-8859-1" Elwin, comments inline.. > 5.0 Introduction > > Following additional messages are defined to exchange session > characteristics: > > Session-Update-Request (SURQ) > > Session-Update-Reply (SURP) > > The SURQ is sent either from LAC to LNS or LNS to LAC. On receiving > this the recipient responds by sending SURP. SURP contains the > recognized and processed AVPs from SURQ. > > These messages can be used for user-specific service information to > be exchanged between LAC and LNS, even after the session is > established. shouldn't last para be: "These message SHOULD be used for user-specific service information to be exchanged between LAC and LNS, ONLY after session is established" > 6.0 Session Characteristics Update Messages > > 6.1 Session-Update-Request (SURQ) Message > > The Session-Update-Request is sent by the LNS/LAC to update peer > regarding session parameters. SURQ message is sent only after > session establishment is successful. In case of LNS this message can > be sent after receving ICCN or sending OCCN, and the session > reaching the established state. In case of LAC this message can be > sent after sending ICCN or receiving OCCN, and the session reaching > > > > Naveen, et al. [Page 2] > > INTERNET-DRAFT L2TP Session Update Mechanism June 2001 > > > > the established state. > > Recipient MUST be able to update its session information, if > required be, based on SURQ. > > The attribute value for Message Type AVP is TBD. The Mandatory bit > for this AVP MUST be Zero, so that the session can continue even > when the peer can not recognize this message. > Other existing or new AVPs can be added to the list of optional AVPs > in this message as and when required. > > The following AVPs MUST be present in the SURQ: > Message Type > > 6.2 Session-Update-Reply (SURP) Message > > The Session-Update-Reply is sent by LAC/LNS to inform the peer about > the acceptance of the information in SURQ received earlier. SURP > contains the recognized and processed AVPs in the same order as > received in SURQ. > > Recipient MUST be able to update its session information, if > required, based on SURP. > > The attribute value for Message Type AVP is TBD and the Mandatory > bit for this AVP MUST be Zero. Other existing or new AVPs can be > added to the list of optional AVPs in this message as and when > required. > > The following AVPs MUST be present in the SURP: > Message Type > SURQ and SURP doesn't include any AVP that explains the capability of a session. What is the use of sending LEX-AVP alone in SCCRQ etc. messages then? > 7.0 L2TP Extension AVP (LEX-AVP) > > The L2TP Extesion AVP, Attribute Type TBD, describe the L2TP > extension support capability of a system. This AVP can be sent in > SCCRQ and/or SCCRP messages. > > Tunnel initiator can send this AVP to indicate to the peer regarding > the extensions it supports and peer can also send its extension > support through this AVP in SCCRP. After processing this AVP both > the system can learn about the peer's capability to support > different L2TP extensions and behave based on the results. Pardon my ignorance: Are you referring to extentions that are defined in some other draft/rfc? Where are the definitions of extensions defined? > > > > > > > > > > Naveen, et al. [Page 3] > > INTERNET-DRAFT L2TP Session Update Mechanism June 2001 > > > > > > > 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|0|0|0|0| Length | Vendor ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Attribute Type | L2TP ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... Extension Capabilities | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > M bit MUST be set to 0 and this AVP can be hidden (H-bit set to 0 or > 1). Length (before hiding) is 10 octets. Vendor ID is TBD. > Attribute Type is 2 octet in length and its value is TBD. The L2TP > Extension Capabilities field is a 32-bit bit-map representing the > list of L2TP extensions supported. Each bit corresponds to one L2TP > extension, and the bit being set indicates the appropriate extension > is being supported. This also implies all the unallocated bits to be > cleared. The extensions mentioned in this draft uses the bit-0 in > this field. So, any implementation supporting this draft, needs to > have bit-0 set. > > > 8.0 Summary and Conclusions > > It is possible to change the session parameters during the life of > session without restarting the session, using the SURQ and SURP > messages. The LEX-AVP can be used to inform the peer about the list > of supported L2TP extensions. How can exchanging 32bit map allow exchanging the session parameters? Where are the parmeters exchanged in SURQ and SURP? > > > 9.0 IANA Considerations > > Should this document advance on as standards track official > attribute values need to be assigned for the LEX-AVP. Also message > type needs to be assigned for SURQ and SURP. > > > 10.0 Security Considerations > > This document does not introduce any new security issues beyond > those inherent in L2TP, and may use the same mechanisms proposed for > those technologies, where applicable. There is no explanation about what happens to the data flows when say DSCP is changed; for example: LAC LNS SURQ ---> valid SURQ (gets some DSCP value from this, act on it now?) <---- Send SCRP (or act on that DSCP now?) ZLB ----> or act on that now? thanks, -- vipin -----Original Message----- From: Elwin Eliazer [mailto:elwinietf@yahoo.com] Sent: Tuesday, June 19, 2001 3:47 PM To: l2tp@l2tp.net Subject: Session update messages for L2TP ... Hi all, Not sure if you got a chance to read the draft mentioned below. We would appreciate to hear your review comments on this. This draft emerged as a result of some earlier discussions we had in this list. Thanks. cheers, Elwin. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L2TP Session Update Mechanism Author(s) : N. Gowda, E. Stelzer, U. Sirsiwal Filename : draft-naveen-l2tpext-sessupdate-00.txt Pages : 5 Date : 11-Jun-01 Once a L2TP session is established, the current standard [RFC 2661] has no explicit mechanism to update the session characteristics, during the life of the session, between the L2TP tunnel endpoints. One such requirement for this mechanism is, LNS informing LAC about the PPP-user's service characteristics, so that user-specific service actions can be applied at LAC. Eg: DSCP marking. There is a need for additional messages that will address similar requirements. Two additional messages are defined in this draft for this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-naveen-l2tpext-sessupdate-00.txt ===== ------- Elwin Stelzer Eliazer Corona Networks ------- __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ------_=_NextPart_001_01C10603.892B7640 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Session update messages for L2TP ...

Elwin,

comments inline..


> 5.0 Introduction
>
>     Following additional = messages are defined to exchange session
>     characteristics:
>
>       = Session-Update-Request (SURQ)
>
>       = Session-Update-Reply (SURP)
>
>     The SURQ is sent either = from LAC to LNS or LNS to LAC. On receiving
>     this the recipient = responds by sending SURP. SURP contains the
>     recognized and = processed AVPs from SURQ.
>
>     These messages can be = used for user-specific service information to
>     be exchanged between = LAC and LNS, even after the session is
>     established.
shouldn't last para be:
"These message SHOULD be used for user-specific = service
information to be exchanged between LAC and LNS, = ONLY after
session is established"


> 6.0 Session Characteristics Update = Messages
>
> 6.1 Session-Update-Request (SURQ) = Message
>
>     The = Session-Update-Request is sent by the LNS/LAC to update peer
>     regarding session = parameters. SURQ message is sent only after
>     session establishment = is successful. In case of LNS this message can
>     be sent after receving = ICCN or sending OCCN, and the session
>     reaching the = established state. In case of LAC this message can be
>     sent after sending ICCN = or receiving OCCN, and the session reaching
>
>
>
> Naveen, et = al.           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  [Page 2]
>

> = INTERNET-DRAFT          = L2TP Session Update = Mechanism          June = 2001
>
>
>
>     the established = state.
>
>     Recipient MUST be able = to update its session information, if
>     required be, based on = SURQ.
>
>     The attribute value for = Message Type AVP is TBD. The Mandatory bit
>     for this AVP MUST be = Zero, so that the session can continue even
>     when the peer can not = recognize this message.
>     Other existing or new = AVPs can be added to the list of optional AVPs
>     in this message as and = when required.
>
>     The following AVPs MUST = be present in the SURQ:
>       Message = Type
>
> 6.2 Session-Update-Reply (SURP) Message
>
>     The = Session-Update-Reply is sent by LAC/LNS to inform the peer about
>     the acceptance of the = information in SURQ received earlier.  SURP
>     contains the recognized = and processed AVPs in the same order as
>     received in = SURQ.
>
>     Recipient MUST be able = to update its session information, if
>     required, based on = SURP.
>
>     The attribute value for = Message Type AVP is TBD and the Mandatory
>     bit for this AVP MUST = be Zero. Other existing or new AVPs can be
>     added to the list of = optional AVPs in this message as and when
>     required.
>
>     The following AVPs MUST = be present in the SURP:
>       Message = Type
>
SURQ and SURP doesn't include any AVP that explains = the capability of a session. What is the use of sending LEX-AVP alone = in SCCRQ etc. messages then?


> 7.0 L2TP Extension AVP (LEX-AVP)
>
>     The L2TP Extesion AVP, = Attribute Type TBD, describe the L2TP
>     extension support = capability of a system. This AVP can be sent in
>     SCCRQ and/or SCCRP = messages.
>
>     Tunnel initiator can = send this AVP to indicate to the peer regarding
>     the extensions it = supports and peer can also send its extension
>     support through this = AVP in SCCRP. After processing this AVP both
>     the system can learn = about the peer's capability to support
>     different L2TP = extensions and behave based on the results.
Pardon my ignorance:
Are you referring to extentions that are defined in = some other draft/rfc?
Where are the definitions of extensions = defined?

>
>
>
>
>
>
>
>
>
> Naveen, et = al.           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  [Page 3]
>
> = INTERNET-DRAFT          = L2TP Session Update = Mechanism          June = 2001
>
>
>
>
>
>
>      = 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|0|0|0|0|    = Length         = |            = Vendor ID          = |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>     = |        Attribute = Type         = |            = ; L2TP  = ...           &n= bsp;    
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>        ... = Extension Capabilities   |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>     M bit MUST be set to 0 = and this AVP can be hidden (H-bit set to 0 or
>     1). Length (before = hiding) is 10 octets. Vendor ID is TBD.
>     Attribute Type is 2 = octet in length and its value is TBD. The L2TP
>     Extension Capabilities = field is a 32-bit bit-map representing the
>     list of L2TP extensions = supported. Each bit corresponds to one L2TP
>     extension, and the bit = being set indicates the appropriate extension
>     is being supported. = This also implies all the unallocated bits to be
>     cleared. The extensions = mentioned in this draft uses the bit-0 in
>     this field. So, any = implementation supporting this draft, needs to
>     have bit-0 set.
>
>
> 8.0 Summary and Conclusions
>
>     It is possible to = change the session parameters during the life of
>     session without = restarting the session, using the SURQ and SURP
>     messages. The LEX-AVP = can be used to inform the peer about the list
>     of supported L2TP = extensions.
How can exchanging 32bit map allow exchanging the = session parameters?
Where are the parmeters exchanged in SURQ and = SURP?

>
>
> 9.0 IANA Considerations
>    
>     Should this document = advance on as standards track official
>     attribute values need = to be assigned for the LEX-AVP. Also message
>     type needs to be = assigned for SURQ and SURP.
>
>
> 10.0 Security Considerations
> 
>     This document does not = introduce any new security issues beyond
>     those inherent in L2TP, = and may use the same mechanisms proposed for
>     those technologies, = where applicable.

There is no explanation about what happens to the = data flows when say DSCP is
changed; for example:

LAC          =        LNS
  SURQ   --->    = valid SURQ (gets some DSCP value from this, act on it now?)
         = <----   Send SCRP (or act on that DSCP now?)
 ZLB     = ---->   or act on that now?


thanks,
-- vipin

-----Original Message-----
From: Elwin Eliazer [mailto:elwinietf@yahoo.com]
Sent: Tuesday, June 19, 2001 3:47 PM
To: l2tp@l2tp.net
Subject: Session update messages for L2TP ...


Hi all,

Not sure if you got a chance to read the draft
mentioned below. We would appreciate to hear = your
review comments on this. This draft emerged as = a
result of some earlier discussions we had in = this
list.

Thanks.

cheers,
Elwin.


A New Internet-Draft is available from the = on-line
Internet-Drafts
directories.


        Title           : = L2TP Session Update Mechanism
        Author(s)       : N. Gowda, E. = Stelzer, U. Sirsiwal
        Filename        : = draft-naveen-l2tpext-sessupdate-00.txt
        Pages           : = 5
        Date    =         : 11-Jun-01
       =20
Once a L2TP session is established, the = current
standard [RFC 2661]
has no explicit mechanism to update the = session
characteristics,
during the life of the session, between the = L2TP
tunnel
endpoints. One such requirement for this mechanism = is,
LNS informing
LAC about the PPP-user's service characteristics, = so
that
user-specific service actions can be applied at = LAC.
Eg: DSCP
marking.
There is a need for additional messages that = will
address similar
requirements. Two additional messages are defined = in
this draft for
this.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-naveen-l2tpe= xt-sessupdate-00.txt


=3D=3D=3D=3D=3D
-------
Elwin Stelzer Eliazer
Corona Networks
-------

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and = more.
http://buzz.yahoo.com/

------_=_NextPart_001_01C10603.892B7640-- From owner-l2tp@diameter.org Fri Jul 6 12:08:09 2001 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 MAA10257 for ; Fri, 6 Jul 2001 12:08:04 -0400 (EDT) Received: (qmail 3208 invoked by alias); 6 Jul 2001 15:53:57 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 3202 invoked by uid 200); 6 Jul 2001 15:53:57 -0000 Received: (qmail 3197 invoked from network); 6 Jul 2001 15:53:55 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jul 2001 15:53:55 -0000 Received: from cisco.com (par-ilm-dhcp1-vl131-26.cisco.com [144.254.57.157]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA16656 for ; Fri, 6 Jul 2001 09:05:13 -0700 (PDT) Message-ID: <3B45E101.11DE9401@cisco.com> Date: Fri, 06 Jul 2001 18:02:09 +0200 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net Subject: IESG Approved l2tpext charter revision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit At long last, we have the l2tp charter as fully approved by the IESG. It has been changed a bit since the last version sent to this list. Possibly the biggest complaint of the earlier version was with regard to where the PWE3 began, L2TP ended, and how the two will interact. Thus, the alignment between PWE3 and L2TPEXT has hopefully been made more clear. The end result is, with the exception of PPP tunneling, the standards track specifications for tunneling as a "Pseudo Wire" with L2TP will be based upon the requirements and specifications first or simultaneously documented in PWE3. The most significant fallout of this is that the EoL2TP and FRoL2TP drafts in their current form will have to be modified to remain within the scope of L2TPEXT. Barring any overturning of this, we should see the charter below on the IETF web page as soon as administratively possible. Thanks, - Mark -------- Original Message -------- Subject: Re: l2tpext charter revision Date: Fri, 06 Jul 2001 11:12:31 -0400 From: Thomas Narten To: "W. Mark Townsley" Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and thereby take advantage of the work done for any protocol over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been used as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Milestones: Mar 2001 "L2TP Security" Submission to IESG for consideration as PS Apr 2001 "L2TP Disconnect Information" Submission to IESG for consideration as PS Apr 2001 "L2TP ATM Access Extensions" Submission to IESG for consideration as PS Jun 2001 "L2TP MIB" Submission to IESG for consideration as PS Jul 2001 "L2TP Link Information" Submission to IESG for consideration as PS Jul 2001 "L2TP Session Information" Submission to IESG for consideration as PS Aug 2001 "L2TP Header Compression" Submission to IESG for consideration as PS Aug 2001 "L2TP Differentiated Services" Submission to IESG for consideration as PS Aug 2001 "L2TP over AAL5" Submission to IESG for consideration as PS Aug 2001 L2TP Base Specification Internet Draft version 00 Aug 2001 PPP over L2TP Internet Draft version 00 *PWE3 Milestones to be determined at a later date From owner-l2tp@diameter.org Fri Jul 6 19:34:43 2001 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 TAA23588 for ; Fri, 6 Jul 2001 19:34:35 -0400 (EDT) Received: (qmail 5311 invoked by alias); 6 Jul 2001 23:20:03 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 5305 invoked by uid 200); 6 Jul 2001 23:20:02 -0000 Received: (qmail 5300 invoked from network); 6 Jul 2001 23:20:00 -0000 Received: from franklin.cisco.com (171.70.156.17) by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jul 2001 23:20:00 -0000 Received: from gwzpc (sjc-vpn-tmp143.cisco.com [10.21.64.143]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA27665; Fri, 6 Jul 2001 16:31:19 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "W. Mark Townsley" , Subject: RE: IESG Approved l2tpext charter revision Date: Fri, 6 Jul 2001 16:30:58 -0700 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) In-Reply-To: <3B45E101.11DE9401@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit W. Mark Townsley [mailto:townsley@cisco.com] writes: This is truly wonderful. I wonder if there has been any (invisible) progress on draft-ietf-l2tpext-security-02.txt? It's been quite some time since WG Last Call was completed... > At long last, we have the l2tp charter as fully approved by the > IESG. It has > been changed a bit since the last version sent to this list. Possibly the > biggest complaint of the earlier version was with regard to where the PWE3 > began, L2TP ended, and how the two will interact. Thus, the > alignment between > PWE3 and L2TPEXT has hopefully been made more clear. The end > result is, with the > exception of PPP tunneling, the standards track specifications > for tunneling as > a "Pseudo Wire" with L2TP will be based upon the requirements and > specifications > first or simultaneously documented in PWE3. The most significant > fallout of this > is that the EoL2TP and FRoL2TP drafts in their current form will > have to be > modified to remain within the scope of L2TPEXT. > > Barring any overturning of this, we should see the charter below > on the IETF web > page as soon as administratively possible. > > Thanks, > > - Mark > > -------- Original Message -------- > Subject: Re: l2tpext charter revision > Date: Fri, 06 Jul 2001 11:12:31 -0400 > From: Thomas Narten > To: "W. Mark Townsley" > > Description of Working Group: > > This group is responsible for extensions to the Layer 2 Tunneling > Protocol. Examples of L2TP "extensions" include any changes to the > L2TP encapsulation, control messages, or new AVPs sent in IETF > standard control messages. > > I. L2TP Background: > > L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP > can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), > etc.) it can effectively be used to tunnel arbitrary protocols over > IP. L2TP provides: > > - An extensible control protocol for dynamic setup, maintenance, and > teardown of multiple layer 2 tunnels between two logical endpoints. > > - An encapsulation method for tunneling PPP frames between each > endpoint. This includes multiplexing of multiple, discrete, PPP > streams between each endpoint. > > L2TP looks (in most ways) like just another point-to-point link to PPP > and thereby take advantage of the work done for any protocol over a > traditional PPP WAN link. It should be noted, however, that the > ability to dynamically establish a PPP connection between any two IP > connected endpoints brings new applications and challenges of scale to > existing PPP implementations and protocol definitions that must be > considered. > > As high-speed broadband access to the home replaces traditional dialup > infrastructure, L2TP has been used as one standard method for > aggregation and delivery of PPP connections over packet > networks. Thus, rather than a relatively small scale or low speed > circuit-switched connection such as an analog modem or ISDN connection > at the L2TP Access Concentrator (LAC), we see PPP being received over > ATM PVCs which are generally higher speed and "always-on" > vs. temporally connected. Further, there are non-IETF standard PPP > tunneling protocols that have been developed and deployed, including > PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol > Standard (http://www.3gpp.org) that interface with L2TP at various > points in the network. While it is unfortunate that there is more > than one standard method for tunneling PPP defined, each of these have > their own installed bases and specific application-driven > nuances. Proper integration with these various tunneling methods as > they "hand-off" to the L2TP portion of the network must be ensured. > > II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: > > In addition to tunneling PPP, L2TPEXT will develop protocol extensions > necessary for the tunneling of specific "pseudo-wires" as defined in > the PWE3 WG. Specific milestone identification for this activity is > currently subject to ongoing work and results from PWE3. > > III. WG Activities > > The Working Group is currently focussed on the following activities: > > - RFC2661 bundles data transport, protocol signaling, and PPP > emulation methods into a single document. This working group will > separate RFC2661 into stand-alone documents for greater > modularity. This will consist of a base L2TP document defining > common tunneling constructs and encapsulation, and a PPP document > defining the use of these constructs for tunneling of PPP sessions > as defined in RFC2661. Documents for tunneling of pseudo-wires > defined in PWE3 will be forthcoming as well. > > As RFC2661 is rewritten to separate the tunnel setup and maintenance > sections for support of new applications and increased modularity, > some modifications to the base protocol may be necessary. This > includes addition of a Pseudo Wire AVP to identify the pseudo wire > being carried (with PPP identified as 0). In all cases, these will > follow the extensible models offered in the L2TP base protocol > design, with as much attention to backwards compatibility as > possible given the new requirements. > > In addition to its broader scope, L2TPEXT has ongoing work to complete > from its inception as a tunneling protocol for PPP only. While RFC2661 > will ultimately be made obsolete by a new L2TP base specification and > companion PPP over L2TP specification, documents based on RFC2661 > which do not require this new degree of modularity will still be > published in the near term. These include: > > - Identification of specific parameters and modes of IPsec in order to > aid interoperability when IPsec is used to secure L2TP traffic. > > - An L2TP MIB for network management. > > - An L2TP Differentiated Services Extension to negotiate DSCP > parameters to be set for packets associated with a given L2TP > tunnel, sessions within a tunnel, or L2TP control traffic which may > need differentiated QoS settings. > > - Extensions to L2TP for additional or more robust control information > for informational or operational purposes as deemed necessary based > on operational experience. These include better transfer of L2TP PPP > LCP Information between tunnel endpoints when such state needs to be > shared, PPP Disconnect codes within L2TP control messages for better > debugging, and L2TP session information for enhanced logging, > billing, and error reporting. > > - Standard methods for operation over such packet networks such as > Frame Relay and AAL5. > > - L2TP defines a base encapsulation for operation in typical > environments for tunneling PPP at the time RFC2661 was being > developed. In cases where bandwidth cost is at a premium, the size > of the L2TP header becomes more significant. L2TP will define a > compressed version of the L2TP header for these environments that > takes advantage of the L2TP control plane to establish operational > parameters allowing removal of information from individual packets. > > Milestones: > > Mar 2001 "L2TP Security" Submission to IESG for consideration as PS > > Apr 2001 "L2TP Disconnect Information" Submission to IESG for > consideration as PS > > Apr 2001 "L2TP ATM Access Extensions" Submission to IESG for > consideration as PS > > Jun 2001 "L2TP MIB" Submission to IESG for consideration as PS > > Jul 2001 "L2TP Link Information" Submission to IESG > for consideration as PS > > Jul 2001 "L2TP Session Information" Submission to IESG > for consideration as PS > > Aug 2001 "L2TP Header Compression" Submission to IESG > for consideration as PS > > Aug 2001 "L2TP Differentiated Services" Submission to IESG > for consideration as PS > > Aug 2001 "L2TP over AAL5" Submission to IESG > for consideration as PS > > Aug 2001 L2TP Base Specification Internet Draft version 00 > > Aug 2001 PPP over L2TP Internet Draft version 00 > > *PWE3 Milestones to be determined at a later date > From owner-l2tp@diameter.org Mon Jul 9 12:33:07 2001 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 MAA20800 for ; Mon, 9 Jul 2001 12:33:06 -0400 (EDT) Received: (qmail 1701 invoked by alias); 9 Jul 2001 16:21:05 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 1695 invoked by uid 200); 9 Jul 2001 16:21:05 -0000 Received: (qmail 1690 invoked from network); 9 Jul 2001 16:21:03 -0000 Received: from unknown (HELO usa03.ambernetworks.com) (63.121.148.130) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 16:21:03 -0000 Received: by usa03.ambernetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jul 2001 09:27:55 -0700 Message-ID: <6DE2BA4DE0F6D411A5BB00B0D0AA6DA11DC5E3@usa03.ambernetworks.com> From: Nishit Vasavada To: "'l2tp@l2tp.net'" Subject: Encapsulation Services Protocol service type for L2TP Date: Mon, 9 Jul 2001 09:27:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10894.198B8300" 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_000_01C10894.198B8300 Content-Type: text/plain; charset="iso-8859-1" Folks, Here is a link to the draft on Encapsulation Service Protocol service type for L2TP. http://www.ietf.org/internet-drafts/draft-vasavada-l2tpext-es-svctype-00.txt Encapsulation Service Protocol emulates the control and encapsulates the data for L1 and L2 circuits over IP networks, and is being submitted to PWE3 WG. The draft that describes the protocol as well as a framework over L2TP is here: http://www.ietf.org/internet-drafts/draft-vasavada-pwe3-esp-00.txt Please comment. Thanks, Nishit > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, July 09, 2001 4:07 AM > Subject: I-D ACTION:draft-vasavada-l2tpext-es-svctype-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Encapsulation Services Protocol > Service Type for L2TP > Author(s) : N. Vasavada > Filename : draft-vasavada-l2tpext-es-svctype-00.txt > Pages : 5 > Date : 06-Jul-01 > > The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard > method for tunneling PPP [RFC1661] packets. In accordance with the > L2TP Service Type specification [L2TPST], this document provides a > solution for transporting Encapsulation Services Protocol (ESP) [ESP] > over L2TP. It uses [L2TPDS] for providing DS support to the L2TP > control and ESP packets. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vasavada-l2tpext-es- > svctype-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-vasavada-l2tpext-es-svctype-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-vasavada-l2tpext-es-svctype-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_000_01C10894.198B8300 Content-Type: message/rfc822 To: Subject: Date: Mon, 9 Jul 2001 08:37:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C10894.198B8300" ------_=_NextPart_002_01C10894.198B8300 Content-Type: text/plain ------_=_NextPart_002_01C10894.198B8300 Content-Type: application/octet-stream; name="ATT39126.txt" Content-Disposition: attachment; filename="ATT39126.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010706135127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vasavada-l2tpext-es-svctype-00.txt ------_=_NextPart_002_01C10894.198B8300 Content-Type: message/external-body; site="internet-drafts"; dir="draft-vasavada-l2tpext-es-svctype-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C10894.198B8300-- ------_=_NextPart_000_01C10894.198B8300-- From owner-l2tp@diameter.org Mon Jul 9 19:20:41 2001 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 TAA00945 for ; Mon, 9 Jul 2001 19:20:37 -0400 (EDT) Received: (qmail 4015 invoked by alias); 9 Jul 2001 23:07:03 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 4009 invoked by uid 200); 9 Jul 2001 23:07:02 -0000 Received: (qmail 4004 invoked from network); 9 Jul 2001 23:07:00 -0000 Received: from web13101.mail.yahoo.com (216.136.174.146) by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 23:07:00 -0000 Message-ID: <20010709231741.30275.qmail@web13101.mail.yahoo.com> Received: from [38.186.47.9] by web13101.mail.yahoo.com via HTTP; Mon, 09 Jul 2001 16:17:41 PDT Date: Mon, 9 Jul 2001 16:17:41 -0700 (PDT) From: Elwin Eliazer Subject: RE: Session update messages for L2TP ... To: vipin@nortelnetworks.com Cc: l2tp@l2tp.net In-Reply-To: <4F973E944951D311B6660008C7917CF0061132E8@zsc4c008.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-l2tp@diameter.org Precedence: bulk Vipin, Thanks for your comments. My responses are inlined. regards, Elwin. --- Vipin Jain wrote: > Elwin, > > comments inline.. > > > > 5.0 Introduction > > > > Following additional messages are defined to > exchange session > > characteristics: > > > > Session-Update-Request (SURQ) > > > > Session-Update-Reply (SURP) > > > > The SURQ is sent either from LAC to LNS or LNS > to LAC. On receiving > > this the recipient responds by sending SURP. > SURP contains the > > recognized and processed AVPs from SURQ. > > > > These messages can be used for user-specific > service information to > > be exchanged between LAC and LNS, even after > the session is > > established. > shouldn't last para be: > "These message SHOULD be used for user-specific > service > information to be exchanged between LAC and LNS, > ONLY after > session is established" We will make this change. > > > > 6.0 Session Characteristics Update Messages > > > > 6.1 Session-Update-Request (SURQ) Message > > > > The Session-Update-Request is sent by the > LNS/LAC to update peer > > regarding session parameters. SURQ message is > sent only after > > session establishment is successful. In case > of LNS this message can > > be sent after receving ICCN or sending OCCN, > and the session > > reaching the established state. In case of LAC > this message can be > > sent after sending ICCN or receiving OCCN, and > the session reaching > > > > > > > > Naveen, et al. > [Page 2] > > > > > INTERNET-DRAFT L2TP Session Update > Mechanism June 2001 > > > > > > > > the established state. > > > > Recipient MUST be able to update its session > information, if > > required be, based on SURQ. > > > > The attribute value for Message Type AVP is > TBD. The Mandatory bit > > for this AVP MUST be Zero, so that the session > can continue even > > when the peer can not recognize this message. > > Other existing or new AVPs can be added to the > list of optional AVPs > > in this message as and when required. > > > > The following AVPs MUST be present in the > SURQ: > > Message Type > > > > 6.2 Session-Update-Reply (SURP) Message > > > > The Session-Update-Reply is sent by LAC/LNS to > inform the peer about > > the acceptance of the information in SURQ > received earlier. SURP > > contains the recognized and processed AVPs in > the same order as > > received in SURQ. > > > > Recipient MUST be able to update its session > information, if > > required, based on SURP. > > > > The attribute value for Message Type AVP is > TBD and the Mandatory > > bit for this AVP MUST be Zero. Other existing > or new AVPs can be > > added to the list of optional AVPs in this > message as and when > > required. > > > > The following AVPs MUST be present in the > SURP: > > Message Type > > > SURQ and SURP doesn't include any AVP that explains > the capability of a > session. What is the use of sending LEX-AVP alone in > SCCRQ etc. messages > then? SURQ and SURP should be capable of supporting additional extension AVPs, and that is left outside this draft. (see the next response) > > > > 7.0 L2TP Extension AVP (LEX-AVP) > > > > The L2TP Extesion AVP, Attribute Type TBD, > describe the L2TP > > extension support capability of a system. This > AVP can be sent in > > SCCRQ and/or SCCRP messages. > > > > Tunnel initiator can send this AVP to indicate > to the peer regarding > > the extensions it supports and peer can also > send its extension > > support through this AVP in SCCRP. After > processing this AVP both > > the system can learn about the peer's > capability to support > > different L2TP extensions and behave based on > the results. > Pardon my ignorance: > Are you referring to extentions that are defined in > some other draft/rfc? > Where are the definitions of extensions defined? May be it must be reworded more clearly. The "IP services over L2TP" draft, submitted recently by Naveen and me, describe two such extensions (for IPSec and QOS). > > > > > > > > > > > > > > > > > > > > > Naveen, et al. > [Page 3] > > > > INTERNET-DRAFT L2TP Session Update > Mechanism June 2001 > > > > > > > > > > > > > > 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|0|0|0|0| Length | > Vendor ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Attribute Type | > L2TP ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ... Extension Capabilities | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > M bit MUST be set to 0 and this AVP can be > hidden (H-bit set to 0 or > > 1). Length (before hiding) is 10 octets. > Vendor ID is TBD. > > Attribute Type is 2 octet in length and its > value is TBD. The L2TP > > Extension Capabilities field is a 32-bit > bit-map representing the > > list of L2TP extensions supported. Each bit > corresponds to one L2TP > > extension, and the bit being set indicates the > appropriate extension > > is being supported. This also implies all the > unallocated bits to be > > cleared. The extensions mentioned in this > draft uses the bit-0 in > > this field. So, any implementation supporting > this draft, needs to > > have bit-0 set. > > > > > > 8.0 Summary and Conclusions > > > > It is possible to change the session > parameters during the life of > > session without restarting the session, using > the SURQ and SURP > > messages. The LEX-AVP can be used to inform > the peer about the list > > of supported L2TP extensions. > How can exchanging 32bit map allow exchanging the > session parameters? > Where are the parmeters exchanged in SURQ and SURP? The purpose of LEX AVP is just to understand the peer's capability to support an L2TP extension or not, apriori. It is not meant to be used in SURQ and SURP to obtain and user-specific service information. > > > > > > > 9.0 IANA Considerations > > > > Should this document advance on as standards > track official > > attribute values need to be assigned for the > LEX-AVP. Also message > > type needs to be assigned for SURQ and SURP. > > > > > > 10.0 Security Considerations > > > > This document does not introduce any new > security issues beyond > > those inherent in L2TP, and may use the same > mechanisms proposed for > > those technologies, where applicable. > > There is no explanation about what happens to the > data flows when say DSCP > is > changed; for example: > > LAC LNS > SURQ ---> valid SURQ (gets some DSCP value > from this, act on it now?) > <---- Send SCRP (or act on that DSCP > now?) > ZLB ----> or act on that now? The SURQ generating node should apply only after receiving SURP. The recepient of SURQ should start acting on it, as soon as it had sent a positive SURP. Though LAC to LNS for SURQ is also fine, as you have shown above, LNS to LAC is the most common case that we expect. > > > thanks, > -- vipin > > -----Original Message----- > From: Elwin Eliazer [mailto:elwinietf@yahoo.com] > Sent: Tuesday, June 19, 2001 3:47 PM > To: l2tp@l2tp.net > Subject: Session update messages for L2TP ... > > > Hi all, > > Not sure if you got a chance to read the draft > mentioned below. We would appreciate to hear your > review comments on this. This draft emerged as a > result of some earlier discussions we had in this > list. > > Thanks. > > cheers, > Elwin. > > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > > > Title : L2TP Session Update Mechanism > Author(s) : N. Gowda, E. Stelzer, U. Sirsiwal > Filename : draft-naveen-l2tpext-sessupdate-00.txt > Pages : 5 > Date : 11-Jun-01 > > Once a L2TP session is established, the current > standard [RFC 2661] > has no explicit mechanism to update the session > characteristics, > during the life of the session, between the L2TP > tunnel > endpoints. One such requirement for this mechanism > is, > LNS informing > LAC about the PPP-user's service characteristics, so > that > user-specific service actions can be applied at LAC. > Eg: DSCP > marking. > There is a need for additional messages that will > address similar > requirements. Two additional messages are defined in > this draft for > this. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-naveen-l2tpext-sessupdate-00.txt > > > ===== > ------- > Elwin Stelzer Eliazer > Corona Networks > ------- > > __________________________________________________ > Do You Yahoo!? > Spot the hottest trends in music, movies, and more. > http://buzz.yahoo.com/ > ===== ------- Elwin Stelzer Eliazer Corona Networks ------- __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-l2tp@diameter.org Tue Jul 10 10:28:57 2001 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 KAA01082 for ; Tue, 10 Jul 2001 10:28:56 -0400 (EDT) Received: (qmail 6818 invoked by alias); 10 Jul 2001 14:17:08 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 6812 invoked by uid 200); 10 Jul 2001 14:17:07 -0000 Received: (qmail 6807 invoked from network); 10 Jul 2001 14:17:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 14:17:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00774; Tue, 10 Jul 2001 10:26:56 -0400 (EDT) Message-Id: <200107101426.KAA00774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tp-mib-02.txt Date: Tue, 10 Jul 2001 10:26:56 -0400 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' Management Information Base Author(s) : E. Caves, P. Calhoun, R. Wheeler Filename : draft-ietf-l2tpext-l2tp-mib-02.txt Pages : 81 Date : 09-Jul-01 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-mib-02.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-02.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-02.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: <20010709103737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-l2tp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-l2tp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709103737.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Tue Jul 10 12:47:04 2001 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 MAA08146 for ; Tue, 10 Jul 2001 12:47:03 -0400 (EDT) Received: (qmail 11517 invoked by alias); 10 Jul 2001 16:35:18 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 11511 invoked by uid 200); 10 Jul 2001 16:35:17 -0000 Received: (qmail 11506 invoked from network); 10 Jul 2001 16:35:15 -0000 Received: from mail.occamnetworks.com (HELO occamnetworks.com) (216.64.159.194) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 16:35:15 -0000 Received: from occamnetworks.com (honeycombs.occamnetworks.com [10.0.0.203]) by occamnetworks.com (8.10.1/8.10.1) with ESMTP id f6AGjNm20407; Tue, 10 Jul 2001 09:45:23 -0700 Message-ID: <3B4B3123.E154FDEC@occamnetworks.com> Date: Tue, 10 Jul 2001 09:45:23 -0700 From: Evan Caves Organization: Occam Networks, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net CC: townsley@cisco.com Subject: Updated L2TP MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit A new L2TP MIB draft has just been posted. The new draft is a result of an IESG review and contains quite a few edits but no architectural changes. Please review the 'Change Log' section for specifics. Mark can you issue yet another WG last call please. thanx, evan - From owner-l2tp@diameter.org Tue Jul 10 13:20:42 2001 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 NAA09739 for ; Tue, 10 Jul 2001 13:20:39 -0400 (EDT) Received: (qmail 12348 invoked by alias); 10 Jul 2001 17:08:34 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 12342 invoked by uid 200); 10 Jul 2001 17:08:34 -0000 Received: (qmail 12337 invoked from network); 10 Jul 2001 17:08:31 -0000 Received: from fwns1d.raleigh.ibm.com (HELO fwns1.raleigh.ibm.com) (204.146.167.235) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 17:08:31 -0000 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA09532; Tue, 10 Jul 2001 13:18:43 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA36550; Tue, 10 Jul 2001 13:18:42 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA01688; Tue, 10 Jul 2001 12:59:10 -0400 Message-Id: <200107101659.MAA01688@rotala.raleigh.ibm.com> To: l2tp@l2tp.net cc: ebooth@cisco.com, gwz@cisco.com, wdixon@microsoft.com, bernarda@microsoft.com, baiju.v.patel@intel.com Subject: draft-ietf-l2tpext-security-02.txt Date: Tue, 10 Jul 2001 12:59:10 -0400 From: Thomas Narten Sender: owner-l2tp@diameter.org Precedence: bulk The WG reqested that this document be advanced as a Proposed Standard quite some time ago. After an inexcusable delay, I have reviewed the document and have the following questions/comments. I'm sending this to the WG rather than just the authors as some of the issues go beyond just editorial clarification. > (General Error) and the Error Code SHOULD be set to 7 (Try Another). If > the Error Code is set to 7, then the optional error message MUST be > present and the contents MUST contain the dotted decimal IP address > (UTF-8 encoded) that the Responder desires to use for subsequent > communications and the initiator MUST parse the result and error code > information and send a new SCCRQ to the new IP address contained in the > error message. This approach reduces complexity since now the initiator > always knows precisely the IP address of its peer. This also allows a > controlled mechanism for L2TP to tie IPSEC filters and policy to the > same peer. This seems like a bad way to go. My understanding is that the error message string is intended for human consumption, hence UTF-8. But above you are really using it to extend the protocol. Seems like it would be better to do this properly, i.e, by defining a new AVP or something (and perhaps putting this in the base L2TP spec?). > 7.1. L2TP Security Protocol > > The L2TP security protocol MUST provide authentication, integrity and > replay protection for control packets. In addition, it SHOULD protect > confidentiality of control packets. It MUST provide integrity and replay > protection of data packets, and MAY protect confidentiality of data > packets. An L2TP security protocol MUST also provide a scalable approach > to key management. > > To meet above requirements, all L2TP security compliant implementations > MUST implement IPSEC ESP for securing L2TP control packets and SHOULD > implement IPSEC ESP for protection of L2TP data packets. All mandated > cipher suites, including NULL encryption, of IPSEC ESP MUST be > supported. Note that if confidentiality is not required (e.g., L2TP data > traffic), ESP with NULL encryption may be used. The implementations > MUST implement replay protection mechanisms of IPSEC. It is not clear what "all mandated cipher suites" is. Can you list them, since they are a MUST? Also, I wonder if the "SHOULD protect confidentiality" should be a MUST. The IESG may have more to say about this. If its just a SHOULD, and a customer only controls one of the implementations, you may not get interoperability... And when it comes to security, you want the customer to be be able to enable it and have it work... > The following guidelines are established to meet L2TP security > requirements using IPSEC in practical situations. Note that this section > is not a requirement for an implementation to be L2TP security > compliant. Its purpose to make the implementors aware of certain > efficiency and security considerations. What does "this section" refer to? i.e., just what is not part of the specification? > The responder is not required to support the ability to float it's IP > address and port. However, the initiator MUST support the ability to > allow the responder to float it's port and SHOULD support the ability to > let the responder float it's IP address. My quick glance of 2661 doesn't find a mention of floating the IP address. Is it allowed there? And if not, why does this document say SHOULD support an undocumented, non-standard extension? Nits: For RFCs > 10 pages, its nice to have TOC; can you easily add one? > media guarantee ordering, and packet losses are typically low. .NH 1 .R stray nroff commands? > Given that the dial-in user will typically not trust the LAC and will > negotiate confidentiality and compression services on its own, the LAC > may only wish to negotiate IPSEC ESP with null encryption (described in > []) with the LNS, and the LNS will request replay protection. This will null reference?? IPSEC vs. IPsec? (I think the preferred spelling is IPsec... change throughout...) > >From the LNS's point of view, it will note a PPP packet encapsulated in Stray > in front of From (thanks to sendmail??) > Per IKE [7], when using pre-shared key authentication, a key must be > present for each peer which secure communication is required. When s/which/to which/ ?? Thomas From owner-l2tp@diameter.org Tue Jul 10 13:39:55 2001 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 NAA10669 for ; Tue, 10 Jul 2001 13:39:53 -0400 (EDT) Received: (qmail 13516 invoked by alias); 10 Jul 2001 17:27:47 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 13510 invoked by uid 200); 10 Jul 2001 17:27:46 -0000 Received: (qmail 13505 invoked from network); 10 Jul 2001 17:27:38 -0000 Received: from zrc2s03g.nortelnetworks.com (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 17:27:38 -0000 Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA01347 for ; Tue, 10 Jul 2001 12:39:40 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com; Tue, 10 Jul 2001 12:36:43 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3TLYNV1S>; Tue, 10 Jul 2001 10:36:34 -0700 Message-ID: <4F973E944951D311B6660008C7917CF006113316@zsc4c008.us.nortel.com> From: "Vipin Jain" To: "'Elwin Eliazer'" Cc: "'l2tp@l2tp.net'" Subject: RE: Session update messages for L2TP ... Date: Tue, 10 Jul 2001 10:36:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10966.DC915230" 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_01C10966.DC915230 Content-Type: text/plain; charset="iso-8859-1" Elwin, comments inline.. >> SURQ and SURP doesn't include any AVP that explains >> the capability of a >> session. What is the use of sending LEX-AVP alone in >> SCCRQ etc. messages >> then? > > SURQ and SURP should be capable of supporting > additional extension AVPs, and that is left > outside this draft. (see the next response) I don't understand how can one ensure interoperability among peers who happen to agree on certain AVPs >> Are you referring to extentions that are defined in >> some other draft/rfc? >> Where are the definitions of extensions defined? > > May be it must be reworded more clearly. > The "IP services over L2TP" draft, submitted > recently by Naveen and me, describe two such > extensions (for IPSec and QOS). yeah that would help.. > The SURQ generating node should apply only after > receiving SURP. The recepient of SURQ should start > acting on it, as soon as it had sent a positive > SURP. Though LAC to LNS for SURQ is also fine, as > you have shown above, LNS to LAC is the most common > case that we expect. it wasn't implied anywhere.. Anyways, does it also imply that LAC or LNS can't send the data unless SURQ, SURP exchange is reliably done? IMHO, I think it would be wise to allow SURQ and SURP for "zero session id" to identify similar characteristics for all sessions in a tunnel.. Of course it would be optional, but can give flexibility and efficiency.. just in case ;) thanks, -- vipin ------_=_NextPart_001_01C10966.DC915230 Content-Type: text/html; charset="iso-8859-1" RE: Session update messages for L2TP ...

Elwin,

comments inline..

>> SURQ and SURP doesn't include any AVP that explains
>> the capability of a
>> session. What is the use of sending LEX-AVP alone in
>> SCCRQ etc. messages
>> then?
>
> SURQ and SURP should be capable of supporting
> additional extension AVPs, and that is left
> outside this draft. (see the next response)
I don't understand how can one ensure interoperability
among peers who happen to agree on certain AVPs

>> Are you referring to extentions that are defined in
>> some other draft/rfc?
>> Where are the definitions of extensions defined?
>
> May be it must be reworded more clearly.
> The "IP services over L2TP" draft, submitted
> recently by Naveen and me, describe two such
> extensions (for IPSec and QOS).
yeah that would help..


> The SURQ generating node should apply only after
> receiving SURP. The recepient of SURQ should start
> acting on it, as soon as it had sent a positive
> SURP. Though LAC to LNS for SURQ is also fine, as
> you have shown above, LNS to LAC is the most common
> case that we expect.
it wasn't implied anywhere.. Anyways, does it also imply
that LAC or LNS can't send the data unless SURQ, SURP
exchange is reliably done?

IMHO, I think it would be wise to allow SURQ and SURP
for "zero session id" to identify similar
characteristics for all sessions in a tunnel..
Of course it would be optional, but can give flexibility
and efficiency.. just in case ;)

thanks,
-- vipin

------_=_NextPart_001_01C10966.DC915230-- From owner-l2tp@diameter.org Tue Jul 10 17:11:15 2001 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 RAA24624 for ; Tue, 10 Jul 2001 17:11:13 -0400 (EDT) Received: (qmail 17277 invoked by alias); 10 Jul 2001 20:59:46 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 17271 invoked by uid 200); 10 Jul 2001 20:59:46 -0000 Received: (qmail 17266 invoked from network); 10 Jul 2001 20:59:43 -0000 Received: from web13103.mail.yahoo.com (216.136.174.148) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 20:59:43 -0000 Message-ID: <20010710211027.27858.qmail@web13103.mail.yahoo.com> Received: from [38.186.47.9] by web13103.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 14:10:27 PDT Date: Tue, 10 Jul 2001 14:10:27 -0700 (PDT) From: Elwin Eliazer Subject: RE: Session update messages for L2TP ... To: vipin@nortelnetworks.com Cc: l2tp@l2tp.net In-Reply-To: <4F973E944951D311B6660008C7917CF006113316@zsc4c008.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-l2tp@diameter.org Precedence: bulk Vipin, Responses inlined. cheers, Elwin. --- Vipin Jain wrote: > Elwin, > > comments inline.. > > >> SURQ and SURP doesn't include any AVP that > explains > >> the capability of a > >> session. What is the use of sending LEX-AVP alone > in > >> SCCRQ etc. messages > >> then? > > > > SURQ and SURP should be capable of supporting > > additional extension AVPs, and that is left > > outside this draft. (see the next response) > I don't understand how can one ensure > interoperability > among peers who happen to agree on certain AVPs The idea of LEX AVP is to know the capabilities of the peer, during the tunnel setup itself, so that both the ends need not send some surprise AVPs to figure out the capability of the other end. This way the capability of the peer is determined at an earlier stage, and hence decision need not be made on a per-AVP basis. The SURQ and SURP messages are added as the first item in the LEX AVP, so that a surprise SURQ/SURP need not be sent. I do not see any new interop issue caused by doing this. > > >> Are you referring to extentions that are defined > in > >> some other draft/rfc? > >> Where are the definitions of extensions defined? > > > > May be it must be reworded more clearly. > > The "IP services over L2TP" draft, submitted > > recently by Naveen and me, describe two such > > extensions (for IPSec and QOS). > yeah that would help.. > > > > The SURQ generating node should apply only after > > receiving SURP. The recepient of SURQ should start > > acting on it, as soon as it had sent a positive > > SURP. Though LAC to LNS for SURQ is also fine, as > > you have shown above, LNS to LAC is the most > common > > case that we expect. > it wasn't implied anywhere.. Anyways, does it also > imply > that LAC or LNS can't send the data unless SURQ, > SURP > exchange is reliably done? The SURQ and SURP are not intended to change the state machine ... they are meant to be used as messages for changing default session characteristics. We need to see if there is some special handling needed for the IPSec case, but for all other cases it appears to be fine. > > IMHO, I think it would be wise to allow SURQ and > SURP > for "zero session id" to identify similar > characteristics for all sessions in a tunnel.. > Of course it would be optional, but can give > flexibility > and efficiency.. just in case ;) That is an interesting suggestion ... may be we can add this to indicate a tunnel as such, which might be interpreted as all sessions within a tunnel. Do you have any specific application in mind for this? > > thanks, > -- vipin > ===== ------- Elwin Stelzer Eliazer Corona Networks ------- __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-l2tp@diameter.org Tue Jul 10 18:50:08 2001 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 SAA28284 for ; Tue, 10 Jul 2001 18:50:06 -0400 (EDT) Received: (qmail 21072 invoked by alias); 10 Jul 2001 22:38:15 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 21066 invoked by uid 200); 10 Jul 2001 22:38:15 -0000 Received: (qmail 21061 invoked from network); 10 Jul 2001 22:38:12 -0000 Received: from zrc2s03g.nortelnetworks.com (HELO zrc2s03g.us.nortel.com) (47.103.122.66) by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 22:38:12 -0000 Received: from zsc4s001.baynetworks.com (zsc4s001.baynetworks.com [134.177.3.62]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA28221 for ; Tue, 10 Jul 2001 17:50:19 -0500 (CDT) Received: from zsc4c002.us.nortel.com by zsc4s001.baynetworks.com; Tue, 10 Jul 2001 15:40:33 -0700 Received: by zsc4c002.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3V2LNPQH>; Tue, 10 Jul 2001 15:47:45 -0700 Message-ID: <4F973E944951D311B6660008C7917CF00611331F@zsc4c008.us.nortel.com> From: "Vipin Jain" To: "'Elwin Eliazer'" Cc: l2tp@l2tp.net Subject: RE: Session update messages for L2TP ... Date: Tue, 10 Jul 2001 15:42:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10991.9DF3E800" 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_01C10991.9DF3E800 Content-Type: text/plain; charset="ISO-8859-1" comment inline.. > > IMHO, I think it would be wise to allow SURQ and > > SURP > > for "zero session id" to identify similar > > characteristics for all sessions in a tunnel.. > > Of course it would be optional, but can give > > flexibility > > and efficiency.. just in case ;) > > That is an interesting suggestion ... may be we > can add this to indicate a tunnel as such, which > might be interpreted as all sessions within a > tunnel. Do you have any specific application in > mind for this? Whenever a tunnel has an associated SLA... implicitly there can be multiple sessions that can come in on a particular tunnel (L2TP Tunnel for VPDNs probably?) > > > > > thanks, > > -- vipin > > > > > ===== > ------- > Elwin Stelzer Eliazer > Corona Networks > ------- > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > ------_=_NextPart_001_01C10991.9DF3E800 Content-Type: text/html; charset="ISO-8859-1" RE: Session update messages for L2TP ...

comment inline..

> > IMHO, I think it would be wise to allow SURQ and
> > SURP
> > for "zero session id" to identify similar
> > characteristics for all sessions in a tunnel..
> > Of course it would be optional, but can give
> > flexibility
> > and efficiency.. just in case ;)
>
> That is an interesting suggestion ... may be we
> can add this to indicate a tunnel as such, which
> might be interpreted as all sessions within a
> tunnel. Do you have any specific application in
> mind for this?
Whenever a tunnel has an associated SLA...
implicitly there can be multiple sessions that can
come in on a particular tunnel (L2TP Tunnel for VPDNs probably?)

>
> >
> > thanks,
> > -- vipin
> >
>
>
> =====
> -------
> Elwin Stelzer Eliazer
> Corona Networks
> -------
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>

------_=_NextPart_001_01C10991.9DF3E800-- From owner-l2tp@diameter.org Fri Jul 13 06:56:34 2001 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 GAA17309 for ; Fri, 13 Jul 2001 06:56:33 -0400 (EDT) Received: (qmail 21167 invoked by alias); 13 Jul 2001 10:44:02 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 21161 invoked by uid 200); 13 Jul 2001 10:44:02 -0000 Received: (qmail 21153 invoked from network); 13 Jul 2001 10:43:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 10:43:58 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16868; Fri, 13 Jul 2001 06:53:59 -0400 (EDT) Message-Id: <200107131053.GAA16868@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-link-02.txt Date: Fri, 13 Jul 2001 06:53:59 -0400 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 : L2TP Link Extensions Author(s) : W. Palter, W. Townsley Filename : draft-ietf-l2tpext-link-02.txt Pages : 7 Date : 12-Jul-01 The physical separation of the LAC and LNS with L2TP[2] and logical separation of the responsibilities of each with respect to negotiated link parameters introduces a lack of awareness between the tunnel endpoints that does not exist in a typical PPP dialup device. When possible, Proxy LCP provides a manner in which to negotiate link parameters at the LAC and communication of these in full to the LNS. If these options can be made acceptable to the LNS, then there should not be any insurmountable difficulty with regard to mismatch of link expectations. However, given that there are instances where negotiation of LCP[1] must take place at the LNS, some direction by the LAC as to what parameters are acceptable, as well as some communication from the LNS as to what parameters have been negotiated, is desirable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-link-02.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-link-02.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-link-02.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: <20010712144300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-link-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-link-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010712144300.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Fri Jul 13 07:01:17 2001 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 HAA17872 for ; Fri, 13 Jul 2001 07:01:15 -0400 (EDT) Received: (qmail 21205 invoked by alias); 13 Jul 2001 10:44:10 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 21199 invoked by uid 200); 13 Jul 2001 10:44:10 -0000 Received: (qmail 21185 invoked from network); 13 Jul 2001 10:44:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 10:44:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16885; Fri, 13 Jul 2001 06:54:05 -0400 (EDT) Message-Id: <200107131054.GAA16885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-mcast-00.txt Date: Fri, 13 Jul 2001 06:54:04 -0400 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 : L2TP Multicast Extension Author(s) : G. Bourdon Filename : draft-ietf-l2tpext-mcast-00.txt Pages : 20 Date : 12-Jul-01 The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for tunneling PPP [RFC1661] packets. This document describes an extension to L2TP, in order to have an efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by such tunnels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-mcast-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-mcast-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-mcast-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: <20010712144314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010712144314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Fri Jul 13 10:38:08 2001 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 KAA15798 for ; Fri, 13 Jul 2001 10:38:08 -0400 (EDT) Received: (qmail 24512 invoked by alias); 13 Jul 2001 14:26:12 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 24506 invoked by uid 200); 13 Jul 2001 14:26:11 -0000 Received: (qmail 24501 invoked from network); 13 Jul 2001 14:26:09 -0000 Received: from unknown (HELO mxic1.isus.emc.com) (168.159.129.100) by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 14:26:09 -0000 Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3NCGA>; Fri, 13 Jul 2001 10:23:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A20@corpmx14.us.dg.com> From: Black_David@emc.com To: l2tp@l2tp.net Subject: RFC 3140 and l2tp diffserv Date: Fri, 13 Jul 2001 10:17:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-l2tp@diameter.org Precedence: bulk RFC 2836 which defines Differentiated Services PHBIDs has been replaced by RFC 3140, which contains the following changes: (1) The oversight that prevented use of the Class Selector codepoints (xxx000, correspond to IP Precedence) has been corrected, and an explicit note has been added to say that the PHBIDs formed from these codepoints can be used to signal IP Precedence for networks that don't implement the full diffserv architecture. See Section 3 of RFC 3140. (2) The first paragraph of Section 10 of the l2tp diffserv draft essentially says "use of this diffserv signaling SHOULD NOT cause packet reordering within any microflow". That seemed like such a good idea that it was added to RFC 3140 and strengthened to say "MUST NOT" (last paragraph of Section 2 of RFC 3140). Both of these changes grew out of work on the l2tp diffserv draft, so I'd like to thank everyone who helped, and hope that the result is useful to l2tp. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-l2tp@diameter.org Sat Jul 14 02:17:58 2001 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 CAA01399 for ; Sat, 14 Jul 2001 02:17:58 -0400 (EDT) Received: (qmail 17984 invoked by alias); 14 Jul 2001 06:05:18 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 17978 invoked by uid 200); 14 Jul 2001 06:05:17 -0000 Received: (qmail 17973 invoked from network); 14 Jul 2001 06:05:14 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jul 2001 06:05:14 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA52936; Fri, 13 Jul 2001 23:08:06 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 13 Jul 2001 23:08:06 -0700 (PDT) From: Bernard Aboba To: l2tp@l2tp.net cc: narten@raleigh.ibm.com, aboba@internaut.com Subject: Re: draft-ietf-l2tpext-security--02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk >It is not clear what "all mandated cipher suites" is. Can you list >them, since they are a MUST? We didn't want to list them, since they can and will change. For example, DES may be deprecated in favor of 3DES. Since L2TP runs over IPSEC, it inherits the same mandatory ciphersuites as IPSEC. If we list them, then we create the danger of the specs getting out of sync. >Also, I wonder if the "SHOULD protect confidentiality" should be a >MUST. The IESG may have more to say about this. If its just a SHOULD, >and a customer only controls one of the implementations, you may not >get interoperability... And when it comes to security, you want the >customer to be be able to enable it and have it work... If both sides support ESP, then the side that wants confidentiality can negotiate it, and there is no interoperability problem. So again, I think we want to ride on top of IPSEC requirements, not create our own (potentially contradictory) ones. >What does "this section" refer to? i.e., just what is not part of the >specification? Good catch. It only meant to refer to three sections but other normative sections were added later. I'll put the non-normative sections in an Appendix to clarify this. >My quick glance of 2661 doesn't find a mention of floating the IP >address. Is it allowed there? I also don't see mention of it -- but it isn't explicitly prohibited either. Are you saying that it should be? It seems like it might be useful in clustering/load balancing situations. >For RFCs > 10 pages, its nice to have TOC; can you easily add one? Done. >stray nroff commands? Yup. Fixed this. >IPSEC vs. IPsec? (I think the preferred spelling is IPsec... change >throughout...) Fixed. >null reference?? Fixed. > Stray > in front of From (thanks to sendmail??) Not due to sendmail... will investigate. > s/which/to which/ ?? Got it. From owner-l2tp@diameter.org Sat Jul 14 11:58:22 2001 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 LAA02890 for ; Sat, 14 Jul 2001 11:58:21 -0400 (EDT) Received: (qmail 20436 invoked by alias); 14 Jul 2001 15:45:38 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 20430 invoked by uid 200); 14 Jul 2001 15:45:38 -0000 Received: (qmail 20425 invoked from network); 14 Jul 2001 15:45:35 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jul 2001 15:45:35 -0000 Received: from cisco.com (rtp-vpn-70.cisco.com [10.82.192.70]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA15052; Sat, 14 Jul 2001 08:52:25 -0700 (PDT) Message-ID: <3B5069F1.C5456505@cisco.com> Date: Sat, 14 Jul 2001 11:49:05 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: l2tp@l2tp.net, narten@raleigh.ibm.com Subject: Re: draft-ietf-l2tpext-security--02 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > >It is not clear what "all mandated cipher suites" is. Can you list > >them, since they are a MUST? > > We didn't want to list them, since they can and will change. For example, > DES may be deprecated in favor of 3DES. Since L2TP runs over IPSEC, it > inherits the same mandatory ciphersuites as IPSEC. If we list them, then > we create the danger of the specs getting out of sync. > > >Also, I wonder if the "SHOULD protect confidentiality" should be a > >MUST. The IESG may have more to say about this. If its just a SHOULD, > >and a customer only controls one of the implementations, you may not > >get interoperability... And when it comes to security, you want the > >customer to be be able to enable it and have it work... > > If both sides support ESP, then the side that wants confidentiality can > negotiate it, and there is no interoperability problem. So again, I think > we want to ride on top of IPSEC requirements, not create our own > (potentially contradictory) ones. > > >What does "this section" refer to? i.e., just what is not part of the > >specification? > > Good catch. It only meant to refer to three sections but other > normative sections were added later. I'll put the non-normative > sections in an Appendix to clarify this. > > >My quick glance of 2661 doesn't find a mention of floating the IP > >address. Is it allowed there? > > I also don't see mention of it -- but it isn't explicitly prohibited > either. Are you saying that it should be? It seems like it might be useful > in clustering/load balancing situations. It is built into l2tp-security, and l2tpbis, and now l2tp-base, as a "try another directed" result code for just the reasons you mention here (and some others as well). > > >For RFCs > 10 pages, its nice to have TOC; can you easily add one? > > Done. > > >stray nroff commands? > > Yup. Fixed this. > > >IPSEC vs. IPsec? (I think the preferred spelling is IPsec... change > >throughout...) > > Fixed. > > >null reference?? > > Fixed. > > > Stray > in front of From (thanks to sendmail??) > > Not due to sendmail... will investigate. > > > s/which/to which/ ?? > > Got it. From owner-l2tp@diameter.org Sun Jul 15 06:40:22 2001 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 GAA01573 for ; Sun, 15 Jul 2001 06:40:20 -0400 (EDT) Received: (qmail 23949 invoked by alias); 15 Jul 2001 10:27:35 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 23943 invoked by uid 200); 15 Jul 2001 10:27:34 -0000 Received: (qmail 23938 invoked from network); 15 Jul 2001 10:27:31 -0000 Received: from mx.bezeqint.net (192.115.106.20) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jul 2001 10:27:31 -0000 Received: from tiger.seabridge.co.il ([212.25.127.226]) by mx.bezeqint.net (8.9.3/8.9.3) with ESMTP id NAA16239 for ; Sun, 15 Jul 2001 13:34:32 +0300 (IDT) Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <31MX7RJV>; Sun, 15 Jul 2001 13:35:12 +0200 Message-ID: <00554D7E32E7D1118A8800805F31D8A3036723CE@tiger.seabridge.co.il> From: Nurit Sprecher To: "L2tp \(E-mail\)" Subject: A Question Regarding the Layer Two Tunneling Protocol "L2TP" Mana gement Information Base Date: Sun, 15 Jul 2001 13:35:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10D22.356C55F8" 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_01C10D22.356C55F8 Content-Type: text/plain; charset="windows-1255" In the Layer Two Tunneling Protocol "L2TP" Management Information Base there is a column defined in the l2tpSessionStatsTable named l2tpSessionStatsPhysChanId that indicates the physical channel identifier for the session. I thought that the l2tpSessionStatsPhysChanId relates to the whole tunnel and not to a certain session. Can you please explain me the need for such an attribute in the l2tpSessionStatsTable? What is the meaning of the Physical channel in the L2TP over IP case? ------_=_NextPart_001_01C10D22.356C55F8 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable A Question Regarding the Layer Two Tunneling Protocol = "L2TP" Management Information Base

In = the Layer Two = Tunneling Protocol "L2TP" Management Information Base there is a column defined in the l2tpSessionStatsTable   named l2tpSessionStatsPhysChanId that indicates the physical channel identifier for the = session.

I = thought that the l2tpSessionStatsPhysChanId relates to the whole tunnel and not to a certain = session.

Can = you please explain me the need for   such an attribute in the  l2tpSessionStatsTable?  What is = the meaning of the Physical channel in the L2TP over IP = case?  

------_=_NextPart_001_01C10D22.356C55F8-- From owner-l2tp@diameter.org Sun Jul 15 17:28:16 2001 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 RAA02187 for ; Sun, 15 Jul 2001 17:28:16 -0400 (EDT) Received: (qmail 1320 invoked by alias); 15 Jul 2001 21:16:30 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 1314 invoked by uid 200); 15 Jul 2001 21:16:30 -0000 Received: (qmail 1309 invoked from network); 15 Jul 2001 21:16:28 -0000 Received: from fwns1d.raleigh.ibm.com (HELO fwns1.raleigh.ibm.com) (204.146.167.235) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jul 2001 21:16:28 -0000 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA31870; Sun, 15 Jul 2001 17:26:30 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA27224; Sun, 15 Jul 2001 17:26:30 -0400 Received: from localhost.localdomain (lig32-224-119-204.us.lig-dial.ibm.com [32.224.119.204]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id RAA27518; Sun, 15 Jul 2001 17:21:32 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.2/8.9.3) with ESMTP id f6FLOMV08197; Sun, 15 Jul 2001 17:24:22 -0400 Message-Id: <200107152124.f6FLOMV08197@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: narten owned process doing -bs To: Bernard Aboba cc: l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: Message from Bernard Aboba of "Fri, 13 Jul 2001 23:08:06 PDT." Date: Sun, 15 Jul 2001 17:24:22 -0400 From: Thomas Narten Sender: owner-l2tp@diameter.org Precedence: bulk > >It is not clear what "all mandated cipher suites" is. Can you list > >them, since they are a MUST? > We didn't want to list them, since they can and will change. For example, > DES may be deprecated in favor of 3DES. Since L2TP runs over IPSEC, it > inherits the same mandatory ciphersuites as IPSEC. If we list them, then > we create the danger of the specs getting out of sync. This makes sense, but I didn't understand that to be the intent from the wording the first time I read it. > >Also, I wonder if the "SHOULD protect confidentiality" should be a > >MUST. The IESG may have more to say about this. If its just a SHOULD, > >and a customer only controls one of the implementations, you may not > >get interoperability... And when it comes to security, you want the > >customer to be be able to enable it and have it work... > If both sides support ESP, then the side that wants confidentiality can > negotiate it, and there is no interoperability problem. So again, I think > we want to ride on top of IPSEC requirements, not create our own > (potentially contradictory) ones. What the current wording seems to suggest is that one MUST implement IPsec ESP for the control channel, but it is only a SHOULD for the data channel. This latter SHOULD is what triggered the above comment. However, thinking about it, it doesn't seem to make a lot of sense to me. If you have to implement it for the control channel, implementing for the data channel would presumably be trivial. Whether someone chooses to enable it is another manner. So just make it a MUST. I.e., how does it help an implementation to not bother implementing IPsec for the data channel? How about changing the paragraph: > To meet above requirements, all L2TP security compliant > implementations MUST implement IPSEC ESP for securing L2TP control > packets and SHOULD implement IPSEC ESP for protection of L2TP data > packets. All mandated cipher suites, including NULL encryption, of > IPSEC ESP MUST be supported. Note that if confidentiality is not > required (e.g., L2TP data traffic), ESP with NULL encryption may be > used. The implementations MUST implement replay protection > mechanisms of IPSEC. to something like: To meet above requirements, all L2TP security compliant implementations MUST implement IPSEC ESP for securing both L2TP control and data packets. All the IPsec-mandated cipher suites [RFC 2406, RFC 2402], including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec cyphersuites, it is an operator choice which ones will be used. Thomas From owner-l2tp@diameter.org Sun Jul 15 17:32:26 2001 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 RAA02650 for ; Sun, 15 Jul 2001 17:32:25 -0400 (EDT) Received: (qmail 1387 invoked by alias); 15 Jul 2001 21:16:44 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 1381 invoked by uid 200); 15 Jul 2001 21:16:44 -0000 Received: (qmail 1369 invoked from network); 15 Jul 2001 21:16:41 -0000 Received: from fwns1d.raleigh.ibm.com (HELO fwns1.raleigh.ibm.com) (204.146.167.235) by c900656-a.plstn1.sfba.home.com with SMTP; 15 Jul 2001 21:16:41 -0000 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA30368; Sun, 15 Jul 2001 17:26:53 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA28386; Sun, 15 Jul 2001 17:26:52 -0400 Received: from localhost.localdomain (lig32-224-119-204.us.lig-dial.ibm.com [32.224.119.204]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id RAA27523; Sun, 15 Jul 2001 17:21:55 -0400 Received: from localhost.localdomain (narten@localhost) by localhost.localdomain (8.11.2/8.9.3) with ESMTP id f6FLOjm08204; Sun, 15 Jul 2001 17:24:45 -0400 Message-Id: <200107152124.f6FLOjm08204@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: narten owned process doing -bs To: "W. Mark Townsley" cc: Bernard Aboba , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: Message from "W. Mark Townsley" of "Sat, 14 Jul 2001 11:49:05 EDT." <3B5069F1.C5456505@cisco.com> Date: Sun, 15 Jul 2001 17:24:44 -0400 From: Thomas Narten Sender: owner-l2tp@diameter.org Precedence: bulk "W. Mark Townsley" writes: > Bernard Aboba wrote: > > >My quick glance of 2661 doesn't find a mention of floating the IP > > >address. Is it allowed there? > > > > I also don't see mention of it -- but it isn't explicitly prohibited > > either. Are you saying that it should be? It seems like it might be useful > > in clustering/load balancing situations. > It is built into l2tp-security, and l2tpbis, and now l2tp-base, as a > "try another directed" result code for just the reasons you mention > here (and some others as well). If this is what implementations are doing and the direction that current specs are going in, I'm fine leaving it in. However, I am interested in hearing folks reaction to the following: Thomas Narten writes: > > (General Error) and the Error Code SHOULD be set to 7 (Try Another). If > > the Error Code is set to 7, then the optional error message MUST be > > present and the contents MUST contain the dotted decimal IP address > > (UTF-8 encoded) that the Responder desires to use for subsequent > > communications and the initiator MUST parse the result and error code > > information and send a new SCCRQ to the new IP address contained in the > > error message. This approach reduces complexity since now the initiator > > always knows precisely the IP address of its peer. This also allows a > > controlled mechanism for L2TP to tie IPSEC filters and policy to the > > same peer. > This seems like a bad way to go. My understanding is that the error > message string is intended for human consumption, hence UTF-8. But > above you are really using it to extend the protocol. Seems like it > would be better to do this properly, i.e, by defining a new AVP or > something (and perhaps putting this in the base L2TP spec?). An important consideration (as I understand it) is that UTF-8 is a character encoding scheme, but not a langauge. Thus, if someone puts a dotted IP address into UTF-8, you are also assuming that a particular language is being used. Presumably english. Is the above redirector stuff already implemented and deployed as described? Thomas From owner-l2tp@diameter.org Sun Jul 15 20:35:29 2001 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 UAA22785 for ; Sun, 15 Jul 2001 20:35:23 -0400 (EDT) Received: (qmail 2909 invoked by alias); 16 Jul 2001 00:24:00 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 2903 invoked by uid 200); 16 Jul 2001 00:24:00 -0000 Received: (qmail 2898 invoked from network); 16 Jul 2001 00:23:58 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 00:23:58 -0000 Received: from cisco.com (rtp-vpn-87.cisco.com [10.82.192.87]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA05493; Sun, 15 Jul 2001 17:29:34 -0700 (PDT) Message-ID: <3B5234A2.3425B1CA@cisco.com> Date: Sun, 15 Jul 2001 20:26:10 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Bernard Aboba , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 References: <200107152124.f6FLOjm08204@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > "W. Mark Townsley" writes: > > > Bernard Aboba wrote: > > > >My quick glance of 2661 doesn't find a mention of floating the IP > > > >address. Is it allowed there? > > > > > > I also don't see mention of it -- but it isn't explicitly prohibited > > > either. Are you saying that it should be? It seems like it might be useful > > > in clustering/load balancing situations. > > > It is built into l2tp-security, and l2tpbis, and now l2tp-base, as a > > "try another directed" result code for just the reasons you mention > > here (and some others as well). > > If this is what implementations are doing and the direction that > current specs are going in, I'm fine leaving it in. > > However, I am interested in hearing folks reaction to the following: > > Thomas Narten writes: > > > > (General Error) and the Error Code SHOULD be set to 7 (Try Another). If > > > the Error Code is set to 7, then the optional error message MUST be > > > present and the contents MUST contain the dotted decimal IP address > > > (UTF-8 encoded) that the Responder desires to use for subsequent > > > communications and the initiator MUST parse the result and error code > > > information and send a new SCCRQ to the new IP address contained in the > > > error message. This approach reduces complexity since now the initiator > > > always knows precisely the IP address of its peer. This also allows a > > > controlled mechanism for L2TP to tie IPSEC filters and policy to the > > > same peer. > > > This seems like a bad way to go. My understanding is that the error > > message string is intended for human consumption, hence UTF-8. But > > above you are really using it to extend the protocol. Seems like it > > would be better to do this properly, i.e, by defining a new AVP or > > something (and perhaps putting this in the base L2TP spec?). > > An important consideration (as I understand it) is that UTF-8 is a > character encoding scheme, but not a langauge. Thus, if someone puts a > dotted IP address into UTF-8, you are also assuming that a particular > language is being used. Presumably english. The field is for english, thus it likely would be displayed via a log message of some sort as part of the general parsing of the redult code. However, the instruction here is that it MAY also be used to as a method for determining a destination for redirection. > > Is the above redirector stuff already implemented and deployed as > described? I believe so. It's not so uncommon for text based instruction in this area when you consider, for better or worse, many commands are received from RADIUS these days via text commands within attribute value pairs. > > Thomas From owner-l2tp@diameter.org Sun Jul 15 23:11:17 2001 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 XAA11349 for ; Sun, 15 Jul 2001 23:11:17 -0400 (EDT) Received: (qmail 3654 invoked by alias); 16 Jul 2001 03:00:20 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 3648 invoked by uid 200); 16 Jul 2001 03:00:20 -0000 Received: (qmail 3643 invoked from network); 16 Jul 2001 03:00:18 -0000 Received: from mail.occamnetworks.com (HELO occamnetworks.com) (216.64.159.194) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 03:00:18 -0000 Received: from occamnetworks.com (cx634162-c.santab1.ca.home.com [24.21.84.187]) by occamnetworks.com (8.10.1/8.10.1) with ESMTP id f6G3ACC10240; Sun, 15 Jul 2001 20:10:16 -0700 Message-ID: <3B525B73.D8F476B8@occamnetworks.com> Date: Sun, 15 Jul 2001 20:11:47 -0700 From: Evan Caves X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Firstrade Securities Inc.} (Win98; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: Nurit Sprecher CC: "L2tp \(E-mail\)" Subject: Re: A Question Regarding the Layer Two Tunneling Protocol "L2TP" Management Information Base References: <00554D7E32E7D1118A8800805F31D8A3036723CE@tiger.seabridge.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit The Physical Channel Identifier object in the MIB is a reflection of the 'Physical Channel ID' AVP that may have been issued during the session setup. It has no specific interpretation (it is vendor specific). It is meant to be used to indicate which physical channel on the LAC is associated with this particular session. Each session has its own physical channel identifier. Please refer to RFC 2661 for additional details. evan - > Nurit Sprecher wrote: > > In the Layer Two Tunneling Protocol "L2TP" Management Information Base > there is a column defined in the l2tpSessionStatsTable named > l2tpSessionStatsPhysChanId that indicates the physical channel > identifier for the session. > > I thought that the l2tpSessionStatsPhysChanId relates to the whole > tunnel and not to a certain session. > > Can you please explain me the need for such an attribute in the > l2tpSessionStatsTable? What is the meaning of the Physical channel in > the L2TP over IP case? From owner-l2tp@diameter.org Mon Jul 16 02:37:36 2001 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 CAA06506 for ; Mon, 16 Jul 2001 02:37:34 -0400 (EDT) Received: (qmail 4713 invoked by alias); 16 Jul 2001 06:26:08 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 4707 invoked by uid 200); 16 Jul 2001 06:26:08 -0000 Received: (qmail 4701 invoked from network); 16 Jul 2001 06:26:06 -0000 Received: from franklin.cisco.com (171.70.156.17) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 06:26:06 -0000 Received: from gwzpc (ams-vpdn-client-76.cisco.com [144.254.46.77]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA08822; Sun, 15 Jul 2001 23:33:57 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Thomas Narten" , "W. Mark Townsley" Cc: "Bernard Aboba" , Subject: RE: draft-ietf-l2tpext-security--02 Date: Sun, 15 Jul 2001 23:34:01 -0700 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200107152124.f6FLOjm08204@localhost.localdomain> Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten [mailto:narten@raleigh.ibm.com] writes: > However, I am interested in hearing folks reaction to the following: > > Thomas Narten writes: > > > > (General Error) and the Error Code SHOULD be set to 7 (Try > Another). If > > > the Error Code is set to 7, then the optional error message MUST be > > > present and the contents MUST contain the dotted decimal IP address > > > (UTF-8 encoded) that the Responder desires to use for subsequent > > > communications and the initiator MUST parse the result and error code > > > information and send a new SCCRQ to the new IP address > contained in the > > > error message. This approach reduces complexity since now > the initiator > > > always knows precisely the IP address of its peer. This also allows a > > > controlled mechanism for L2TP to tie IPSEC filters and policy to the > > > same peer. > > > This seems like a bad way to go. My understanding is that the error > > message string is intended for human consumption, hence UTF-8. But > > above you are really using it to extend the protocol. Seems like it > > would be better to do this properly, i.e, by defining a new AVP or > > something (and perhaps putting this in the base L2TP spec?). > > An important consideration (as I understand it) is that UTF-8 is a > character encoding scheme, but not a langauge. Thus, if someone puts a > dotted IP address into UTF-8, you are also assuming that a particular > language is being used. Presumably english. If I understand Thomas correctly, he is saying that UTF-8 encoding IP addresses is basically silly; I agree completely. > > Is the above redirector stuff already implemented and deployed as > described? > > Thomas > From owner-l2tp@diameter.org Mon Jul 16 03:21:06 2001 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 DAA15350 for ; Mon, 16 Jul 2001 03:21:05 -0400 (EDT) Received: (qmail 8185 invoked by alias); 16 Jul 2001 07:10:13 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 8179 invoked by uid 200); 16 Jul 2001 07:10:12 -0000 Received: (qmail 8174 invoked from network); 16 Jul 2001 07:10:11 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 07:10:11 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA57900; Mon, 16 Jul 2001 00:12:30 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 16 Jul 2001 00:12:30 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: <200107152124.f6FLOMV08197@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk > How about changing the paragraph: > > > To meet above requirements, all L2TP security compliant > > implementations MUST implement IPSEC ESP for securing L2TP control > > packets and SHOULD implement IPSEC ESP for protection of L2TP data > > packets. All mandated cipher suites, including NULL encryption, of > > IPSEC ESP MUST be supported. Note that if confidentiality is not > > required (e.g., L2TP data traffic), ESP with NULL encryption may be > > used. The implementations MUST implement replay protection > > mechanisms of IPSEC. > > to something like: > > To meet above requirements, all L2TP security compliant > implementations MUST implement IPSEC ESP for securing both L2TP > control and data packets. All the IPsec-mandated cipher suites > [RFC 2406, RFC 2402], including NULL encryption MUST be > supported. Note that although an implementation MUST support all > IPsec cyphersuites, it is an operator choice which ones will be > used. > > Thomas > OK with me. From owner-l2tp@diameter.org Mon Jul 16 03:24:25 2001 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 DAA16025 for ; Mon, 16 Jul 2001 03:24:24 -0400 (EDT) Received: (qmail 8841 invoked by alias); 16 Jul 2001 07:13:49 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 8835 invoked by uid 200); 16 Jul 2001 07:13:49 -0000 Received: (qmail 8830 invoked from network); 16 Jul 2001 07:13:47 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 07:13:47 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA57907; Mon, 16 Jul 2001 00:16:14 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 16 Jul 2001 00:16:14 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: Thomas Narten , "W. Mark Townsley" , l2tp@l2tp.net Subject: RE: draft-ietf-l2tpext-security--02 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > addresses is basically silly; I agree completely. > Yup. I wish I had a dime for every recent RFC that suggests encoding of IP addresses or routes in UTF-8. From owner-l2tp@diameter.org Mon Jul 16 05:47:12 2001 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 FAA02016 for ; Mon, 16 Jul 2001 05:47:11 -0400 (EDT) Received: (qmail 10168 invoked by alias); 16 Jul 2001 09:36:28 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 10162 invoked by uid 200); 16 Jul 2001 09:36:27 -0000 Received: (qmail 10157 invoked from network); 16 Jul 2001 09:36:25 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 09:36:25 -0000 Received: from cisco.com (rtp-vpn-53.cisco.com [10.82.192.53]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id CAA10482; Mon, 16 Jul 2001 02:42:12 -0700 (PDT) Message-ID: <3B52B628.59F52CC8@cisco.com> Date: Mon, 16 Jul 2001 05:38:48 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: Glen Zorn , Thomas Narten , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > addresses is basically silly; I agree completely. > > > > Yup. I wish I had a dime for every recent RFC that suggests encoding of IP > addresses or routes in UTF-8. And if I had a nickel for every feature in any implementation that did something along these lines, I would still be ahead... - Mark From owner-l2tp@diameter.org Mon Jul 16 20:25:12 2001 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 UAA15818 for ; Mon, 16 Jul 2001 20:25:12 -0400 (EDT) Received: (qmail 24999 invoked by alias); 17 Jul 2001 00:13:16 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 24992 invoked by uid 200); 17 Jul 2001 00:13:16 -0000 Received: (qmail 24970 invoked from network); 17 Jul 2001 00:13:11 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 00:13:11 -0000 Received: from cisco.com (rtp-vpn-53.cisco.com [10.82.192.53]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA10678 for ; Mon, 16 Jul 2001 17:23:26 -0700 (PDT) Message-ID: <3B5384B1.27959400@cisco.com> Date: Mon, 16 Jul 2001 20:20:01 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net Subject: New l2tp-base draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit The new base specification for L2TP may be found in: http://townsley.net/mark/l2tpv3/draft-ietf-l2tpext-l2tp-base-00.txt This was sent before the cutoff last week, but I suspect the editor was fairly overwhelmed. More information is in the draft, but in short we tried to take as much as possible from RFC2661 after PPP was removed, together with the consensus reached from some recent discussions on the list here, and some proposed ideas of our own after looking at the result. This is still very much a -00 draft, and as such there still may be errors, new ideas that need refinement, replacement or removal, etc. Comments quite welcome. The PPP specification is still being edited and will be posted ASAP. Hopefully by the end of the week, though the principal editor was hit by a very unwelcome dose of sick leave over the past couple of weeks. Thanks, - Mark From owner-l2tp@diameter.org Tue Jul 17 11:46:15 2001 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 LAA04568 for ; Tue, 17 Jul 2001 11:46:15 -0400 (EDT) Received: (qmail 2867 invoked by alias); 17 Jul 2001 15:34:54 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 2861 invoked by uid 200); 17 Jul 2001 15:34:53 -0000 Received: (qmail 2856 invoked from network); 17 Jul 2001 15:34:51 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 15:34:51 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA59888; Tue, 17 Jul 2001 08:37:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 17 Jul 2001 08:37:12 -0700 (PDT) From: Bernard Aboba To: Glen Zorn cc: Thomas Narten , "W. Mark Townsley" , l2tp@l2tp.net Subject: RE: draft-ietf-l2tpext-security--02 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > addresses is basically silly; I agree completely. > > do we have recommended text to fix this? From owner-l2tp@diameter.org Tue Jul 17 12:52:41 2001 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 MAA18883 for ; Tue, 17 Jul 2001 12:52:40 -0400 (EDT) Received: (qmail 4966 invoked by alias); 17 Jul 2001 16:41:40 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 4960 invoked by uid 200); 17 Jul 2001 16:41:40 -0000 Received: (qmail 4955 invoked from network); 17 Jul 2001 16:41:37 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 16:41:37 -0000 Received: from cisco.com (rtp-vpn-174.cisco.com [10.82.192.174]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA19950; Tue, 17 Jul 2001 09:44:28 -0700 (PDT) Message-ID: <3B546A9D.DD3BB785@cisco.com> Date: Tue, 17 Jul 2001 12:41:01 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: Glen Zorn , Thomas Narten , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > > addresses is basically silly; I agree completely. > > > > > do we have recommended text to fix this? I think we would probably want to create a new AVP if we wanted to encode the IP address in a more native form. Might want to get a sense of the state of implementations here before we yank this out from under them. It has been in draft form unchanged for a rather long time. - Mark From owner-l2tp@diameter.org Tue Jul 17 18:01:43 2001 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 SAA24491 for ; Tue, 17 Jul 2001 18:01:42 -0400 (EDT) Received: (qmail 6512 invoked by alias); 17 Jul 2001 21:50:27 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 6506 invoked by uid 200); 17 Jul 2001 21:50:27 -0000 Received: (qmail 6501 invoked from network); 17 Jul 2001 21:50:25 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 21:50:25 -0000 Received: from cisco.com (dhcp-64-102-64-198.cisco.com [64.102.64.198]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA14025 for ; Tue, 17 Jul 2001 15:00:43 -0700 (PDT) Message-ID: <3B54B4BE.95C62E6D@cisco.com> Date: Tue, 17 Jul 2001 17:57:18 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net Subject: Call for L2TPEXT Agenda Items for the 51st IETF in London Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Please send me requests to make presentations at L2TPEXT. Be sure to include all of the information below. Even if you have already made a request, please do me the favor of responding (privately, no need to copy the list) to this email with the following items filled in. I will provide a digest after receiving all requests. Thanks. - Mark 1) Name of presenter, including e-mail address 2) Title of presentation 3) Internet draft name, if applicable 4) Amount of time requested Our slot: THURSDAY, August 9, 2001 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG INT idn Internationalized Domain Name WG INT l2tpext Layer Two Tunneling Protocol Extensions WG OPS hubmib Ethernet Interfaces and Hub MIB WG SEC kink Kerberized Internet Negotiation of Keys WG TSV & hip & Host Identity Payload BOF and APP geopriv Geographic Location/Privacy WG TSV mmusic Multiparty Multimedia Session Control WG http://www.ietf.org/meetings/agenda_51.txt From owner-l2tp@diameter.org Tue Jul 17 20:14:14 2001 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 UAA19621 for ; Tue, 17 Jul 2001 20:14:13 -0400 (EDT) Received: (qmail 7345 invoked by alias); 18 Jul 2001 00:02:54 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 7339 invoked by uid 200); 18 Jul 2001 00:02:54 -0000 Received: (qmail 7334 invoked from network); 18 Jul 2001 00:02:52 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 00:02:52 -0000 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6HGw3403532; Tue, 17 Jul 2001 09:58:37 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f6HGxeQ11820; Tue, 17 Jul 2001 09:59:40 -0700 (PDT) Received: from ebooth-u10.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA13713; Tue, 17 Jul 2001 09:59:38 -0700 (PDT) Received: (from ebooth@localhost) by ebooth-u10.cisco.com (8.11.4/8.11.3) id f6HGt6k01279; Tue, 17 Jul 2001 12:55:06 -0400 From: Skip Booth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15188.28138.700760.573224@dhcp-64-102-64-165.cisco.com> Date: Tue, 17 Jul 2001 12:55:06 -0400 To: "W. Mark Townsley" Cc: Bernard Aboba , Glen Zorn , Thomas Narten , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: <3B546A9D.DD3BB785@cisco.com> References: <3B546A9D.DD3BB785@cisco.com> X-Mailer: VM 6.90 under Emacs 20.5.1 Reply-To: ebooth@cisco.com Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit W. Mark Townsley writes: > > > Bernard Aboba wrote: > > > > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > > > addresses is basically silly; I agree completely. > > > > > > > > do we have recommended text to fix this? > > I think we would probably want to create a new AVP if we wanted to encode the IP > address in a more native form. Might want to get a sense of the state of > implementations here before we yank this out from under them. It has been in > draft form unchanged for a rather long time. Well we (cisco) are using this for a couple of features, so I think there's interest in keeping this as is. I don't think any of these features are in production releases yet, so there is a small window of time where we could change this. If we where to change this, then I would definitely suggest a new AVP. The optional message text of the Result and Error code AVP is supposed to be human readable if I recall correctly, so I think it's appropriate that it be UTF-8 encoded. -Skip > > - Mark From owner-l2tp@diameter.org Wed Jul 18 00:16:34 2001 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 AAA01297 for ; Wed, 18 Jul 2001 00:16:33 -0400 (EDT) Received: (qmail 8299 invoked by alias); 18 Jul 2001 04:05:11 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 8293 invoked by uid 200); 18 Jul 2001 04:05:11 -0000 Received: (qmail 8288 invoked from network); 18 Jul 2001 04:05:09 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 04:05:09 -0000 Received: from cisco.com (rtp-vpn-125.cisco.com [10.82.192.125]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA11927; Tue, 17 Jul 2001 21:15:27 -0700 (PDT) Message-ID: <3B550C90.E64A3C4C@cisco.com> Date: Wed, 18 Jul 2001 00:12:00 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net CC: narten@raleigh.ibm.com, Erik Nordmark Subject: Last call for L2TP MIB References: <3ACBC9DB.A9A7632C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit This is last call for draft-ietf-l2tpext-l2tp-mib-02.txt This version reflects changes made since the previous last call that the authors feel were beyond editorial in nature. These are detailed in the Change Log, Section 1.1. I will advise the Area Directors on August 13, 2001, to take this draft to Proposed Standard unless there is substantive comment raised on this list. Note that this is based on RFC2661 and does not include any extensions for future L2TP revisions. Thanks, - Mark From owner-l2tp@diameter.org Wed Jul 18 07:05:35 2001 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 HAA28329 for ; Wed, 18 Jul 2001 07:05:34 -0400 (EDT) Received: (qmail 9643 invoked by alias); 18 Jul 2001 10:49:29 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 9637 invoked by uid 200); 18 Jul 2001 10:49:29 -0000 Received: (qmail 9624 invoked from network); 18 Jul 2001 10:49:25 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 10:49:25 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25532; Wed, 18 Jul 2001 06:59:21 -0400 (EDT) Message-Id: <200107181059.GAA25532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt Date: Wed, 18 Jul 2001 06:59:20 -0400 Sender: owner-l2tp@diameter.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L2TP Active Discovery Relay for PPPoE Author(s) : W. Townsley, R.da Silva Filename : draft-dasilva-l2tp-relaysvc-00.txt Pages : 6 Date : 17-Jul-01 L2TP Active Discovery Relay for PPPoE describes a method for relay of PPPoE Active Discovery and Service Selection [PPPoE] over the reliable L2TP control channel [L2TP]. Two new L2TP control message types and associated PPPoE-specific AVPs are defined. This relay mechanism provides enhanced integration in L2TP of a specific feature in the PPPoE tunneling protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dasilva-l2tp-relaysvc-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-dasilva-l2tp-relaysvc-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-dasilva-l2tp-relaysvc-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: <20010717133225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dasilva-l2tp-relaysvc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dasilva-l2tp-relaysvc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717133225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Wed Jul 18 12:10:21 2001 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 MAA02277 for ; Wed, 18 Jul 2001 12:10:20 -0400 (EDT) Received: (qmail 12466 invoked by alias); 18 Jul 2001 15:58:58 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 12460 invoked by uid 200); 18 Jul 2001 15:58:58 -0000 Received: (qmail 12455 invoked from network); 18 Jul 2001 15:58:56 -0000 Received: from unknown (HELO internaut.com) (64.38.134.99) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 15:58:56 -0000 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA61772; Wed, 18 Jul 2001 09:01:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 18 Jul 2001 09:01:12 -0700 (PDT) From: Bernard Aboba To: Skip Booth cc: "W. Mark Townsley" , Glen Zorn , Thomas Narten , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: <15188.28138.700760.573224@dhcp-64-102-64-165.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-l2tp@diameter.org Precedence: bulk On Tue, 17 Jul 2001, Skip Booth wrote: > > W. Mark Townsley writes: > > > > > > Bernard Aboba wrote: > > > > > > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > > > > addresses is basically silly; I agree completely. > > > > > > > > > > > do we have recommended text to fix this? > > > > I think we would probably want to create a new AVP if we wanted to encode the IP > > address in a more native form. Might want to get a sense of the state of > > implementations here before we yank this out from under them. It has been in > > draft form unchanged for a rather long time. > > Well we (cisco) are using this for a couple of features, so I think there's > interest in keeping this as is. I don't think any of these features are in > production releases yet, so there is a small window of time where we could > change this. If we where to change this, then I would definitely suggest a > new AVP. The optional message text of the Result and Error code AVP is > supposed to be human readable if I recall correctly, so I think it's > appropriate that it be UTF-8 encoded. > > -Skip > I can understand wanting to encode a human readable message in UTF-8. But encoding an IP address that way? Perhaps we can clarify what parts are UTF-8 and what is plan ASCII? From owner-l2tp@diameter.org Wed Jul 18 14:57:24 2001 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 OAA04719 for ; Wed, 18 Jul 2001 14:57:24 -0400 (EDT) Received: (qmail 13365 invoked by alias); 18 Jul 2001 18:45:43 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 13359 invoked by uid 200); 18 Jul 2001 18:45:43 -0000 Received: (qmail 13354 invoked from network); 18 Jul 2001 18:45:41 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 18:45:41 -0000 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6IIroe03995; Wed, 18 Jul 2001 11:53:51 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f6IIrej13512; Wed, 18 Jul 2001 11:53:40 -0700 (PDT) Received: from ebooth-u10.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA10210; Wed, 18 Jul 2001 11:53:38 -0700 (PDT) Received: (from ebooth@localhost) by ebooth-u10.cisco.com (8.11.4/8.11.3) id f6IIn8701300; Wed, 18 Jul 2001 14:49:08 -0400 From: Skip Booth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.55844.4476.600783@dhcp-64-102-64-165.cisco.com> Date: Wed, 18 Jul 2001 14:49:08 -0400 To: Bernard Aboba Cc: "W. Mark Townsley" , Glen Zorn , Thomas Narten , l2tp@l2tp.net Subject: Re: draft-ietf-l2tpext-security--02 In-Reply-To: References: <15188.28138.700760.573224@dhcp-64-102-64-165.cisco.com> X-Mailer: VM 6.90 under Emacs 20.5.1 Reply-To: ebooth@cisco.com Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba writes: > On Tue, 17 Jul 2001, Skip Booth wrote: > > > > > W. Mark Townsley writes: > > > > > > > > > Bernard Aboba wrote: > > > > > > > > > > If I understand Thomas correctly, he is saying that UTF-8 encoding IP > > > > > > addresses is basically silly; I agree completely. > > > > > > > > > > > > > > do we have recommended text to fix this? > > > > > > I think we would probably want to create a new AVP if we wanted to encode the IP > > > address in a more native form. Might want to get a sense of the state of > > > implementations here before we yank this out from under them. It has been in > > > draft form unchanged for a rather long time. > > > > Well we (cisco) are using this for a couple of features, so I think there's > > interest in keeping this as is. I don't think any of these features are in > > production releases yet, so there is a small window of time where we could > > change this. If we where to change this, then I would definitely suggest a > > new AVP. The optional message text of the Result and Error code AVP is > > supposed to be human readable if I recall correctly, so I think it's > > appropriate that it be UTF-8 encoded. > > > > -Skip > > > I can understand wanting to encode a human readable message in UTF-8. But > encoding an IP address that way? Perhaps we can clarify what parts are > UTF-8 and what is plan ASCII? I think you are right. This should just be defined as ASCII since I don't even know what it means to have an IP address in another UTF-8 encoded form. My understanding is that ASCII is a subset of UTF-8 and thus the original wording was technically correct but just not completely clear. How about the following text: In section 8.2.3: The optional error message MUST be present and the contents MUST contain the dotted decimal IP address (ASCII encoded) the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. -Skip From owner-l2tp@diameter.org Thu Jul 19 07:20:01 2001 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 HAA01263 for ; Thu, 19 Jul 2001 07:20:00 -0400 (EDT) Received: (qmail 21764 invoked by alias); 19 Jul 2001 10:56:22 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 21757 invoked by uid 200); 19 Jul 2001 10:56:21 -0000 Received: (qmail 21725 invoked from network); 19 Jul 2001 10:55:54 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 10:55:54 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28329; Thu, 19 Jul 2001 07:05:51 -0400 (EDT) Message-Id: <200107191105.HAA28329@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tp-base-00.txt Date: Thu, 19 Jul 2001 07:05:50 -0400 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 et al. Filename : draft-ietf-l2tpext-l2tp-base-00.txt Pages : 70 Date : 18-Jul-01 This document describes the Layer Two Tunneling Protocol (L2TP). L2TP tunnels Layer 2 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-l2tp-base-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-l2tp-base-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-l2tp-base-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: <20010718142235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-l2tp-base-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-l2tp-base-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142235.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Thu Jul 19 08:34:32 2001 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 IAA14094 for ; Thu, 19 Jul 2001 08:34:28 -0400 (EDT) Received: (qmail 24851 invoked by alias); 19 Jul 2001 12:15:28 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 24842 invoked by uid 200); 19 Jul 2001 12:15:25 -0000 Received: (qmail 24810 invoked from network); 19 Jul 2001 12:14:52 -0000 Received: from mx.bezeqint.net (192.115.106.20) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 12:14:54 -0000 Received: from tiger.seabridge.co.il ([212.25.127.226]) by mx.bezeqint.net (8.9.3/8.9.3) with ESMTP id PAA26788; Thu, 19 Jul 2001 15:20:32 +0300 (IDT) Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <31MX8AF3>; Thu, 19 Jul 2001 15:21:04 +0200 Message-ID: <00554D7E32E7D1118A8800805F31D8A3036723F8@tiger.seabridge.co.il> From: Nurit Sprecher To: "'Evan Caves'" , Nurit Sprecher Cc: "L2tp \(E-mail\)" Subject: RE: A Question Regarding the Layer Two Tunneling Protocol "L2TP" Management Information Base Date: Thu, 19 Jul 2001 15:21:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11055.A8E6550A" 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_01C11055.A8E6550A Content-Type: text/plain; charset="iso-8859-1" I understand that the Physical Channel ID relates to a certain session within the tunnel. I understand that different sessions within a tunnel may transmit on different physical channels. Is it possible that even different packets of the same session will transmit on different physical channels? * An example for such a case can be a LAC and an IP router that are implemented on the same host. When a LAC establishes a session within a tunnel that is transmitting above UDP/IP, it determines the IP address of the LNS (from the Radius or from local configuration). The LAC may associate the session ID with the IP address of the LNS, and lets the IP router determines the actual physical channel the packet will be transmitted through. In such a case, IP routing decision is taken for each packet within a session. Theoretically, it may happen that these packets will transmit on different physical channels. Can you please respond to the above? Thanks in advance, Nurit. -----Original Message----- From: Evan Caves [mailto:evan@occamnetworks.com] Sent: Monday, July 16, 2001 5:12 AM To: Nurit Sprecher Cc: L2tp (E-mail) Subject: Re: A Question Regarding the Layer Two Tunneling Protocol "L2TP" Management Information Base The Physical Channel Identifier object in the MIB is a reflection of the 'Physical Channel ID' AVP that may have been issued during the session setup. It has no specific interpretation (it is vendor specific). It is meant to be used to indicate which physical channel on the LAC is associated with this particular session. Each session has its own physical channel identifier. Please refer to RFC 2661 for additional details. evan ------_=_NextPart_001_01C11055.A8E6550A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A Question Regarding the Layer Two Tunneling Protocol = "L2TP" Management Information Base

I understand that the Physical Channel ID relates to = a certain session within the tunnel. I understand that different = sessions within a tunnel may transmit on different physical = channels.

Is it possible that even different packets of the = same session will transmit on different physical channels?
* An example for such a case can be a LAC and an IP = router that are implemented on the same host. When a LAC establishes a = session within a tunnel that is transmitting above UDP/IP, it = determines the IP address of the LNS (from the Radius or from local = configuration). The LAC may associate the session ID with the IP = address of the LNS, and lets the IP router determines the actual = physical channel the packet will be transmitted through. In such a = case, IP routing decision is taken for each packet within a session. = Theoretically, it may happen that these packets will transmit on = different physical channels.

Can you please respond to the above?

Thanks in advance, Nurit.

-----Original Message-----
From: Evan Caves [mailto:evan@occamnetworks.com= ]
Sent: Monday, July 16, 2001 5:12 AM
To: Nurit Sprecher
Cc: L2tp (E-mail)
Subject: Re: A Question Regarding the Layer Two = Tunneling Protocol "L2TP" Management Information Base

The Physical Channel Identifier object in the MIB is = a reflection of
the 'Physical Channel ID' AVP that may have been = issued during the
session setup. It has no specific interpretation (it = is vendor
specific).
It is meant to be used to indicate which physical = channel on the LAC
is associated with this particular session. Each = session has its own
physical channel identifier. Please refer to RFC = 2661 for additional
details.

evan

------_=_NextPart_001_01C11055.A8E6550A-- From owner-l2tp@diameter.org Thu Jul 19 09:45:30 2001 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 JAA02126 for ; Thu, 19 Jul 2001 09:45:28 -0400 (EDT) Received: (qmail 27737 invoked by alias); 19 Jul 2001 13:23:22 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 27729 invoked by uid 200); 19 Jul 2001 13:23:20 -0000 Received: (qmail 27702 invoked from network); 19 Jul 2001 13:23:01 -0000 Received: from team.iglou.com (HELO iglou.com) (sendmail@192.107.41.45) by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 13:23:01 -0000 Received: from jeffm by iglou.com with local (8.9.3/8.9.3) id 15NDuy-00042W-00; Thu, 19 Jul 2001 09:32:40 -0400 Date: Thu, 19 Jul 2001 09:32:40 -0400 From: Jeff Mcadams To: Nurit Sprecher Cc: "'Evan Caves'" , "L2tp \(E-mail\)" Subject: Re: A Question Regarding the Layer Two Tunneling Protocol "L2TP" Management Information Base Message-ID: <20010719093240.A14881@iglou.com> References: <00554D7E32E7D1118A8800805F31D8A3036723F8@tiger.seabridge.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <00554D7E32E7D1118A8800805F31D8A3036723F8@tiger.seabridge.co.il>; from nurit.sprecher@SeabridgeNetworks.com on Thu, Jul 19, 2001 at 03:21:02PM +0200 Sender: owner-l2tp@diameter.org Precedence: bulk Also sprach Nurit Sprecher >I understand that the Physical Channel ID relates to a certain session >within the tunnel. Not exactly (as I understand it). There is some correlation, in that a session will have a physical channel id associated with it, but it bears no correlation to how the session is transported. Instead, the physical channel id represents the physical channel that the call goes out from the LAC on (ie, where the data goes after its decapsulated). >I understand that different sessions within a tunnel may transmit on >different physical channels. >Is it possible that even different packets of the same session will >transmit on different physical channels? If the session is carrying traffic from a multi-link bundle (for example) that's bundled at the LAC, then, yes, it could happen. [snipped your example since it was founded on mistaken assumptions I believe] -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 From owner-l2tp@diameter.org Fri Jul 20 05:39:00 2001 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 FAA07395 for ; Fri, 20 Jul 2001 05:38:58 -0400 (EDT) Received: (qmail 24888 invoked by alias); 20 Jul 2001 09:27:16 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 24882 invoked by uid 200); 20 Jul 2001 09:27:16 -0000 Received: (qmail 24877 invoked from network); 20 Jul 2001 09:27:14 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 09:27:14 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06378; Fri, 20 Jul 2001 05:37:13 -0400 (EDT) Message-Id: <200107200937.FAA06378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-security-03.txt Date: Fri, 20 Jul 2001 05:37:13 -0400 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 : Securing L2TP using IPSEC Author(s) : B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth Filename : draft-ietf-l2tpext-security-03.txt Pages : 27 Date : 19-Jul-01 This document discusses how L2TP may utilize IPSEC to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-security-03.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-security-03.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-security-03.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: <20010719150046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-security-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-security-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150046.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Fri Jul 20 20:43:46 2001 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 UAA03443 for ; Fri, 20 Jul 2001 20:43:45 -0400 (EDT) Received: (qmail 989 invoked by alias); 21 Jul 2001 00:32:10 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 983 invoked by uid 200); 21 Jul 2001 00:32:10 -0000 Received: (qmail 978 invoked from network); 21 Jul 2001 00:32:07 -0000 Received: from drawbridge.ascend.com (198.4.92.1) by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jul 2001 00:32:07 -0000 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 RAA28322; Fri, 20 Jul 2001 17:41:58 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 21 Jul 2001 00:42:46 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 RAA22976; Fri, 20 Jul 2001 17:42:45 -0700 (PDT) Received: from grigri.eng.ascend.com (grigri.eng.ascend.com [135.140.53.45]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id RAA08963; Fri, 20 Jul 2001 17:42:46 -0700 (PDT) Received: from igoyret-pc by grigri.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id RAA14377; Fri, 20 Jul 2001 17:42:44 -0700 (PDT) Message-Id: <3.0.5.32.20010720174242.0176bd80@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Jul 2001 17:42:42 -0700 To: Elwin Eliazer From: Ignacio Goyret Subject: Re: Session update messages for L2TP ... Cc: l2tp@l2tp.net In-Reply-To: <20010619224720.14373.qmail@web13107.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-l2tp@diameter.org Precedence: bulk A minor nit: in section 6.1, it says: The Session-Update-Request is sent by the LNS/LAC to update peer regarding session parameters. SURQ message is sent only after session establishment is successful. In case of LNS this message can be sent after receving ICCN or sending OCCN, and the session ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ reaching the established state. In case of LAC this message can be sent after sending ICCN or receiving OCCN, and the session reaching ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the established state. ICCNs _and_ OCCNs are sent only by LACs, which are the only ones that can determine whether the call has been connected. A corrected version: ... In the case of an LNS, this message can be sent after receiving ICCN or OCCN. In the case of an LAC, this message can be sent after sending ICCN or OCCN. ... At 03:47 PM 6/19/01 -0700, Elwin Eliazer wrote: >Hi all, > >Not sure if you got a chance to read the draft >mentioned below. We would appreciate to hear your >review comments on this. This draft emerged as a >result of some earlier discussions we had in this >list. > >Thanks. > >cheers, >Elwin. > > >A New Internet-Draft is available from the on-line >Internet-Drafts >directories. > > > Title : L2TP Session Update Mechanism > Author(s) : N. Gowda, E. Stelzer, U. Sirsiwal > Filename : draft-naveen-l2tpext-sessupdate-00.txt > Pages : 5 > Date : 11-Jun-01 > >Once a L2TP session is established, the current >standard [RFC 2661] >has no explicit mechanism to update the session >characteristics, >during the life of the session, between the L2TP >tunnel >endpoints. One such requirement for this mechanism is, >LNS informing >LAC about the PPP-user's service characteristics, so >that >user-specific service actions can be applied at LAC. >Eg: DSCP >marking. >There is a need for additional messages that will >address similar >requirements. Two additional messages are defined in >this draft for >this. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-naveen-l2tpext-sessupdate-00.txt > > >===== >------- >Elwin Stelzer Eliazer >Corona Networks >------- > >__________________________________________________ >Do You Yahoo!? >Spot the hottest trends in music, movies, and more. >http://buzz.yahoo.com/ > From owner-l2tp@diameter.org Tue Jul 24 06:55:54 2001 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 GAA07683 for ; Tue, 24 Jul 2001 06:55:53 -0400 (EDT) Received: (qmail 23458 invoked by alias); 24 Jul 2001 10:22:37 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 23452 invoked by uid 200); 24 Jul 2001 10:22:37 -0000 Received: (qmail 23447 invoked from network); 24 Jul 2001 10:22:35 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 10:22:35 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06494; Tue, 24 Jul 2001 06:32:32 -0400 (EDT) Message-Id: <200107241032.GAA06494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-security-04.txt Date: Tue, 24 Jul 2001 06:32:31 -0400 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 : Securing L2TP using IPSEC Author(s) : B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth Filename : draft-ietf-l2tpext-security-04.txt Pages : 27 Date : 23-Jul-01 This document discusses how L2TP may utilize IPSEC to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-security-04.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-security-04.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-security-04.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: <20010723140941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-security-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-security-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Wed Jul 25 18:40:55 2001 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 SAA17311 for ; Wed, 25 Jul 2001 18:40:54 -0400 (EDT) Received: (qmail 32031 invoked by alias); 24 Jul 2001 23:56:24 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 32025 invoked by uid 200); 24 Jul 2001 23:56:24 -0000 Received: (qmail 32020 invoked by uid 500); 24 Jul 2001 23:56:23 -0000 Date: Tue, 24 Jul 2001 16:56:23 -0700 From: Pat Calhoun To: l2tp@l2tp.net Subject: RFC 3145 on L2TP Disconnect Cause Information Message-ID: <20010724165623.U10225@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-l2tp@diameter.org Precedence: bulk All, Unfortunately, this message bounced because I didn't have the RFC editor as a valid subscriber. I've added it for the future. Below is the bounced e-mail. PatC ----- Forwarded message from owner-l2tp@diameter.org ----- To: IETF-Announce: ; Subject: RFC 3145 on L2TP Disconnect Cause Information Cc: rfc-ed@ISI.EDU, l2tp@ipsec.org Date: Tue, 24 Jul 2001 17:01:11 -0700 From: RFC Editor A new Request for Comments is now available in online RFC libraries. RFC 3145 Title: L2TP Disconnect Cause Information Author(s): R. Verma, M. Verma, J. Carlson Status: Standards Track Date: July 2001 Mailbox: rverma@dc.com, Madhvi_Verma@3com.com, james.d.carlson@sun.com Pages: 10 Characters: 17421 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2tpext-ppp-discinfo-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3145.txt This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. L2TP lacks a mechanism for a host to provide PPP-related disconnect cause information to another host. This information, provided by the extension described in this document, can be useful for accounting and debugging purposes. This document is a product of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. L2TP lacks a mechanism for a host to provide PPP-related disconnect cause information to another host. This information, provided by the extension described in this document, can be useful for accounting and debugging purposes. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010724165541.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3145 --OtherAccess Content-Type: Message/External-body; name="rfc3145.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010724165541.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- ----- End forwarded message ----- From owner-l2tp@diameter.org Wed Jul 25 19:43:49 2001 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 TAA22232 for ; Wed, 25 Jul 2001 19:43:47 -0400 (EDT) Received: (qmail 377 invoked by alias); 25 Jul 2001 00:50:11 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 371 invoked by uid 200); 25 Jul 2001 00:50:11 -0000 Received: (qmail 366 invoked from network); 25 Jul 2001 00:50:09 -0000 Received: from prattle.redback.com (hiddenuser@155.53.12.9) by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jul 2001 00:50:09 -0000 Received: from docker (dhcp-45-114.redback.com [155.53.45.114]) by prattle.redback.com (Postfix) with SMTP id A99E9CAB75 for ; Tue, 24 Jul 2001 18:01:06 -0700 (PDT) From: "Suhail Nanji" To: Subject: L2TP over AAL5 draft Date: Tue, 24 Jul 2001 18:01:39 -0700 Message-ID: <000301c114a5$5c7c1680$722d359b@docker> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 8bit This draft was submitted after the Internet Draft final submission cutoff date. It will be resubmitted after the IETF Meeting in London. Suhail Network Working Group Mike Davison INTERNET DRAFT Cisco Category: Standards Track Arthur Lin Title: draft-ietf-l2tpext-l2tp-atm-02.txt Tahoe Networks Date: July 2001 Ajoy Singh Motorola John Stephens Cayman Systems Rollins Turner Paradyne Rene Tio Suhail Nanji Redback Networks L2TP Over AAL5 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 January, 2002. Please send comments to the authors. Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page1] INTERNET DRAFT July 2001 Abstract The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for transporting the link layer of PPP [RFC1661] between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point to point connection. This document describes the use of an ATM network for the underlying network connection. ATM User-Network Interface (UNI) Signalling Specification Version 4.0 [SIG40] or Version 3.1 [SIG31] with ATM Adaptation Layer 5 (AAL5) [ITU93] are supported as interfaces to the ATM network. Applicability This specification is intended for implementations of L2TP that use ATM to provide the communications link between the L2TP Access Concentrator and the L2TP Network Server. 1. Introduction The Point-to-Point Protocol, PPP, [RFC1661] is frequently used on the link between a personal computer with a dial modem and a network service provider, or NSP. The Layer Two Tunneling Protocol (L2TP) [RFC2661] enables a dial-up server to provide access to a remote NSP by extending the PPP connection through a tunnel in a network to which both it and the NSP are directly connected. A "tunnel" is a network layer connection between two nodes, used in the role of a data link layer connection between those nodes, possibly as part of a different network. In [RFC2661] the dial-up server is called an L2TP Access Concentrator, or LAC. The remote device that provides access to a network is called an L2TP Network Server, or LNS. L2TP uses a packet delivery service to create a tunnel between the LAC and the LNS. "L2TP is designed to be largely insulated from the details of the media over which the tunnel is established; L2TP requires only that the tunnel media provide packet oriented point-to-point connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable form of packet oriented connection. This standard supplements [RFC2661] by providing details specific to the use of AAL5 for a point-to-point connection between LAC and LNS. 2. Conventions Requirements keywords 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 Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page2] INTERNET DRAFT July 2001 [RFC2119]. A list of acronyms used in this document is given at the end of the document as Appendix A. 3. AAL5 Layer Service Interface L2TP treats the underlying ATM AAL5 layer service as a bit- synchronous point-to-point link. In this context, the L2TP link corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be full-duplex, point to point, and it MAY be either dedicated (i.e., permanent, set up by provisioning) or switched (set up on demand.) The AAL5 message mode service, in the non-assured mode of operation, without the corrupted delivery option MUST be used. Interface Format - The L2TP/AAL5 layer boundary presents an octet service interface to the AAL5 layer. There is no provision for sub- octets to be supplied or accepted. 3.1 Maximum Transfer Unit Each L2TP PDU MUST be transported within a single AAL5 PDU. Therefore the maximum transfer unit (MTU) of the AAL5 connection constrains the MTU of the L2TP tunnel that uses the connection and the MTU of all PPP connections that use the tunnel. ( [RFC1661] refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is the Forward and Backward Maximum CPCS-SDU Size.) An implementation MUST support a PPP MRU of at least 1500 bytes. An implementation SHOULD use a larger MTU than the minimum value specified above. It is RECOMMENDED that an implementation support an IP packet of at least 9180 bytes in the PPP PDU. 3.2 Quality of Service In order to provide a desired Quality of Service (QoS), and possibly different qualities of service to different client connections, an implementation MAY use more than one AAL5 connection between LAC and LNS. QoS mechanisms, such as Differentiated UBR [DUBR], that could involve inverse multiplexing a tunnel across multiple VCs are for further study. QoS mechanisms applicable to a single tunnel corresponding to a single VC, are independent of the ATM transport and out of scope of this document. Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page3] INTERNET DRAFT July 2001 3.3 ATM Connection Parameters The L2TP layer does not impose any restrictions regarding transmission rate or the underlying ATM layer traffic descriptor parameters. Specific traffic parameters MAY be set for a PVC connection by agreement between the communicating parties. The caller MAY request specific traffic parameters at the time an SVC connection is set up. Autoconfiguration of end-systems for PVCs can be faciliated by the use of the optional ILMI 4.0 extensions documented in [ILMIA]. This provides comparable information to the IEs used for control plane connection establishment. 4. Multi-Protocol Encapsulation This specification uses the principles, terminology, and frame structure described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC2684]. The purpose of this specification is not to reiterate what is already standardized in [RFC2684], but to specify how the mechanisms described in [RFC2684] are to be used to map L2TP onto an AAL5-based ATM network. As specified in [RFC2684], L2TP PDUs shall be carried in the payload field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be empty. Section 1 of [RFC2684] defines two mechanisms for identifying the protocol encapsulated in the AAL5 PDU's payload field: 1. Virtual circuit (VC) based multiplexing. 2. Logical Link Control (LLC) encapsulation. In the first mechanism, the payload's protocol type is implicitly agreed to by the end points for each virtual circuit using provisioning or control plane procedures. This mechanism will be referred to as "VC-multiplexed L2TP". In the second mechanism, the payload's protocol type is explicitly identified in each AAL5 PDU by an IEEE 802.2 LLC header. This mechanism will be referred to as "LLC encapsulated L2TP". Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page4] INTERNET DRAFT July 2001 An L2TP implementation: 1. MUST support LLC encapsulated L2TP on PVCs. 2. MAY support LLC encapsulated L2TP on SVCs. 3. MAY support VC-multiplexed L2TP on PVCs or SVCs. When a PVC is used, the endpoints must be configured to use one of the two encapsulation methods. If an implementation supports SVCs, it MUST use the [Q.2931] Annex C procedure to negotiate connection setup, encoding the Broadband Lower Layer Interface (B-LLI) information element (IE) to signal either VC- multiplexed L2TP or LLC encapsulated L2TP. The details of this control plane procedure are described in section 7. If an implementation is connecting through a Frame Relay/ATM FRF.8 [FRF8] service inter-working unit, then it MUST use LLC encapsulated L2TP. 5. LLC Encapsulated L2TP over AAL5 When LLC encapsulation is used, the payload field of the AAL5 CPCS PDU SHALL be encoded as shown in Figure 1. The pertinent fields in that diagram are: 1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA followed by a frame type of Un-numbered Information (value 0x03). This LLC header indicates that an IEEE 802.1a SNAP header follows [RFC2684]. 2. IEEE 802.1a SNAP Header: The three octet Organizationally Unique Identifier (OUI) value of 0x00-00-5E identifies IANA (Internet Assigned Numbers Authority.) The two octet Protocol Identifier (PID) identifies L2TP as the encapsulated protocol. The PID value is 0x0007. 3. The L2TP PDU. Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page5] INTERNET DRAFT July 2001 Figure 1 - LLC Encapsulated L2TP PDU +-------------------------+ -------- | Destination SAP (0xAA) | ^ +-------------------------+ | | Source SAP (0xAA) | LLC header +-------------------------+ | | Frame Type = UI (0x03) | V +-------------------------+ -------- | OUI (0x00-00-5E)| | +-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header | PID (0x00-07) | | +-------------------------+ -------- | | | | | L2TP PDU | | | +-------------------------+ -------- Note: The format of the overall AAL5 CPCS PDU is shown in the next section. The end points MAY be bi-laterally provisioned to send other LLC- encapsulated protocols besides L2TP across the same virtual connection. 6. Virtual Circuit Multiplexed L2TP over AAL5 VC-multiplexed L2TP over AAL5 is an alternative technique to LLC encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5 payload without an LLC header. This is sometimes called "Null encapsulation." Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page6] INTERNET DRAFT July 2001 Figure 2 - AAL5 CPCS-PDU Format +-------------------------------+ ------- | . | ^ | . | | | CPCS-PDU payload | L2TP PDU | up to 2^16 - 1 octets) | | | . | V +-------------------------------+ ------- | PAD ( 0 - 47 octets) | +-------------------------------+ ------- | CPCS-UU (1 octet ) | ^ +-------------------------------+ | | CPI (1 octet ) | | +-------------------------------+CPCS-PDU Trailer | Length (2 octets) | | +-------------------------------| | | CRC (4 octets) | V +-------------------------------+ ------- The Common Part Convergence Sub-layer (CPCS) PDU payload field contains user information up to 2^16 - 1 octets. The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such that the last 48 octet cell payload created by the SAR sublayer will have the CPCS-PDU Trailer right justified in the cell. The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field has no function under the multi-protocol ATM encapsulation and MAY be set to any value. The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. Possible additional functions are for further study in ITU- T. When only the 64 bit alignment function is used, this field SHALL be coded as 0x00. The Length field indicates the length, in octets, of the payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 MAY be used for the abort function. The CRC field SHALL be computed over the entire CPCS-PDU except the CRC field itself. The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in [RFC2661]. Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page7] INTERNET DRAFT July 2001 7. Out-of-Band Control Plane Signalling 7.1 Connection Setup An SVC connection can originate at either the LAC or the LNS. An implementation that supports the use of SVCs MUST be able to both originate and respond to SVC setup requests. Except for the B-LLI IE specified below, all other IEs required for ATM User-Network Interface (UNI) Signalling Specification Version 4.0 [SIG40] should be encoded as per [RFC2331]. When originating an SVC AAL5 connection, the caller MUST request in the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP, or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL be used to specify the requested encapsulation method. When a caller is offering both encapsulations, the two B-LLI IEs SHALL be encoded within a Broadband Repeat Indicator information element in the order of the sender's preference. An implementation MUST be able to accept an incoming call that offers LLC encapsulated L2TP in the caller's request. The called peer's implementation MUST reject a call setup request that only offers an encapsulation that it does not support. Implementations originating a call offering both protocol encapsulation techniques MUST be able to accept the use of either encapsulation technique. When originating an LLC encapsulated call that is to carry an L2TP payload, the [Q.2931] B-LLI IE user information layer 2 protocol field SHALL be encoded to select LAN Logical Link Control (ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example. When originating a VC-multiplexed call that is to carry an L2TP payload, the [Q.2931] B-LLI IE user information layer 2 protocol field SHALL be encoded to select no layer 2 protocol in octet 6 and layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577 [ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037 [DSLF037], the extension octets specify VC-multiplexed L2TP by using the SNAP IPI, followed by an OUI owned by IANA, followed by the PID assigned by IANA for L2TP. Thus, the User Information layer 3 protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's payload field will always contain an L2TP PDU. The SNAP IPI is employed only to use the IANA L2TP protocol value to specify the VC- multiplexed PDU. If the caller offers both encapsulation methods and the called peer accepts the call, the called peer SHALL specify the encapsulation method by including exactly one B-LLI IE in the Connect message. Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page8] INTERNET DRAFT July 2001 If an SVC tunnel is reset in accordance with section 4.1 of [RFC2661], both ends MUST clear the SVC. Any user sessions on the tunnel will be terminated by the reset. Either end MAY attempt to re-establish the tunnel upon receipt of a new request from a client. 7.2 Connection Setup Failure When a connection setup fails, the L2TP entity that attempted the connection setup MAY consider the called entity unreachable until notified that the unreachable entity is available. The conditions under which an entity determines that another is unreachable and how it determines that the other is available again are implementation decisions. 7.3 Connection Teardown When there are no active sessions on an SVC tunnel, either end MAY optionally clear the connection. 8. Connection Failure Upon notification that an AAL5 SVC connection has been cleared, an Implementation SHALL tear down the tunnel and return the control connection to the idle state. 9. Security Considerations ATM networks, being virtual circuit based, are generally less vulnerable to security attacks than IP based networks. The probability of a security breach caused by misrouted ATM cells is considered to be negligible. Currently there is no standard specification for ATM security. However, the ATM Forum is working on an ATM Security Framework document. In light of this work, the issue of security will be re- examined at a later date to see if L2TP over ATM specific protection mechanisms are still required. In the interim, basic security issues are discussed in the base L2TP specification [RFC2661]. 10. Acknowledgments This Internet Draft draws heavily on material from: "PPP Over AAL5" (RFC 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and John Stephens; the current Internet Draft on L2TP over Frame Relay, by Vipin Rawat, Rene Tio, Suhail Nanji and Rohit Verma; and an Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page9] INTERNET DRAFT July 2001 earlier Internet Draft on L2TP over AAL5 by by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin. Special thanks to David Allan of Nortel for his invaluable review of this document. 11. References [RFC2661] W. M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. Zorn, B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [SIG31] The ATM Forum, "ATM User-Network Interface Specification V3.1", af-uni-0010.002, 1994. [ITU93] International Telecommunication Union, "B-ISDN ATM Adaptation Layer(AAL) Specification", ITU-T Recommendation I.363, March 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2684] D. Grossman, J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. [Q.2931] International Telecommunication Union, "Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control", ITU-T Recommendation Q.2931, Feb. 1995. [FRF8] The Frame Relay Forum, "Frame Relay/ATM PVC Service Interworking Implementation Agreement", FRF.8, April 1995. [ISO9577] ISO/IEC DTR 9577.2, "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1995-08-16. [RFC2331] M. Maher, "ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", RFC 2331, April 1998. [DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for the Connection Between the DSL Broadband Network Termination (B-NT) and the Network using ATM", March 2001. [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signalling Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page10] INTERNET DRAFT July 2001 Specification Version 4.0", af-sig-0061.000, finalized July 1996; available at ftp://ftp.atmforum.com/pub. [DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af- tm-0149.000, finalized July, 2000; available at ftp://ftp.atmforum.com/pub [ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration Extension", af-nm-00165.000, April 2001. Authors' Addresses: Rollins Turner Paradyne Corporation 8545 126th Avenue North Largo, FL 33773 Email: rturner@eng.paradyne.com Ajoy Singh Motorola 1421 West Shure Dr, Arlington Heights, IL 60004 Email: asingh1@motorola.com Suhail Nanji Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134 Email: suhail@redback.com Rene Tio Redback Networks, Inc. 300 Holger Way Sunnyvale, CA 95134 Email: tor@redback.com Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page11] INTERNET DRAFT July 2001 Appendix A. Acronyms AAL5 ATM Adaptation Layer Type 5 ATM Asynchronous Transfer Mode B-LLI Broadband Low Layer Information CPCS Common Part Convergence Sublayer IANA Internet Assigned Numbers Authority IE Information Element L2TP Layer Two Tunneling Protocol LAC L2TP Access Concentrator LLC Logical Link Control LNS L2TP Network Server MTU Maximum Transfer Unit MRU Maximum Receive Unit NSP Network Service Provider OUI Organizationally Unique Identifier PDU Protocol Data Unit PID Protocol Identifier PPP Point-to-Point Protocol PVC Permanent Virtual Circuit SAP Service Access Point SNAP Subnetwork Address Protocol SVC Switched Virtual Circuit VC Virtual Circuit Davison, Lin, Singh, Stephens, Turner, Tio, Nanji [Page12] From owner-l2tp@diameter.org Fri Jul 27 07:24:18 2001 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 HAA07759 for ; Fri, 27 Jul 2001 07:24:17 -0400 (EDT) Received: (qmail 14894 invoked by alias); 27 Jul 2001 11:12:10 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 14887 invoked by uid 200); 27 Jul 2001 11:12:09 -0000 Received: (qmail 14882 invoked from network); 27 Jul 2001 11:12:05 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 11:12:05 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07574; Fri, 27 Jul 2001 07:22:10 -0400 (EDT) Message-Id: <200107271122.HAA07574@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-link-03.txt Date: Fri, 27 Jul 2001 07:22:10 -0400 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 : L2TP Link Extensions Author(s) : W. Palter, W. Townsley Filename : draft-ietf-l2tpext-link-03.txt Pages : 7 Date : 26-Jul-01 The physical separation of the LAC and LNS with L2TP[2] and logical separation of the responsibilities of each with respect to negotiated link parameters introduces a lack of awareness between the tunnel endpoints that does not exist in a typical PPP dialup device. When possible, Proxy LCP provides a manner in which to negotiate link parameters at the LAC and communication of these in full to the LNS. If these options can be made acceptable to the LNS, then there should not be any insurmountable difficulty with regard to mismatch of link expectations. However, given that there are instances where negotiation of LCP[1] must take place at the LNS, some direction by the LAC as to what parameters are acceptable, as well as some communication from the LNS as to what parameters have been negotiated, is desirable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-link-03.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-link-03.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-link-03.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: <20010726170946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-link-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-link-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170946.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Fri Jul 27 07:27:48 2001 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 HAA07990 for ; Fri, 27 Jul 2001 07:27:47 -0400 (EDT) Received: (qmail 14944 invoked by alias); 27 Jul 2001 11:12:16 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 14937 invoked by uid 200); 27 Jul 2001 11:12:16 -0000 Received: (qmail 14896 invoked from network); 27 Jul 2001 11:12:10 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 11:12:10 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07586; Fri, 27 Jul 2001 07:22:15 -0400 (EDT) Message-Id: <200107271122.HAA07586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2tp@l2tp.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tp-ppp-00.txt Date: Fri, 27 Jul 2001 07:22:15 -0400 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 : PPP Tunneling Using Layer Two Tunneling Protocol Author(s) : J. Lau, W. Townsley Filename : draft-ietf-l2tpext-l2tp-ppp-00.txt Pages : 24 Date : 26-Jul-01 This document describes the use of Layer Two Tunneling Protocol (L2TP) to tunnel PPP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-ppp-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-l2tp-ppp-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-l2tp-ppp-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: <20010726170956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2tpext-l2tp-ppp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2tpext-l2tp-ppp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170956.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-l2tp@diameter.org Sun Jul 29 01:33:49 2001 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 BAA10797 for ; Sun, 29 Jul 2001 01:33:49 -0400 (EDT) Received: (qmail 24571 invoked by alias); 29 Jul 2001 05:21:52 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 24565 invoked by uid 200); 29 Jul 2001 05:21:52 -0000 Received: (qmail 24560 invoked from network); 29 Jul 2001 05:21:50 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 29 Jul 2001 05:21:50 -0000 Received: from cisco.com (rtp-vpn-7.cisco.com [10.82.192.7]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA23843 for ; Sat, 28 Jul 2001 22:32:24 -0700 (PDT) Message-ID: <3B639F02.4CACE937@cisco.com> Date: Sun, 29 Jul 2001 01:28:34 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: l2tp@l2tp.net Subject: Time slots for London Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit These are the current requests I have for time slots in London. If you need a slot or an additional slot and are not mentioned below, please let me know ASAP. Currently I have suspiciously less requests for slots listed than there are new drafts being worked on. - Mark Reinaldo Penno, rpenno@nortelnetworks.com L2TP Tunnel Switching draft-penno-l2tp-switching-01.txt Nishit Vasavada, nishit@ambernetworks.com Encapsulation Services Protocol Service Type for L2TP draft-vasavada-l2tpext-es-svctype-00.txt Elwin Eliazer, elwinietf@yahoo.com L2TP Session Update Mechanism draft-naveen-l2tpext-sessupdate-00.txt Madhvi Verma, madhvi_verma@3com.com PPP Tunneling Using Layer Two Tunneling Protocol draft-ietf-l2tpext-l2tp-ppp-00.txt W. Mark Townsley, mark@townsley.net Layer Two Tunneling Protocol "L2TP" draft-ietf-l2tpext-l2tp-base-00.txt W. Mark Townsley, mark@townsley.net L2TP Active Discovery Relay for PPPoE draft-dasilva-l2tp-relaysvc-00.txt From owner-l2tp@diameter.org Mon Jul 30 16:22:07 2001 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 QAA21931 for ; Mon, 30 Jul 2001 16:22:06 -0400 (EDT) Received: (qmail 7696 invoked by alias); 30 Jul 2001 19:49:47 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 7690 invoked by uid 200); 30 Jul 2001 19:49:47 -0000 Received: (qmail 7685 invoked from network); 30 Jul 2001 19:49:44 -0000 Received: from iwan-view3.cisco.com (171.69.24.144) by c900656-a.plstn1.sfba.home.com with SMTP; 30 Jul 2001 19:49:44 -0000 Received: from cisco.com (sjc-vpn-tmp24.cisco.com [10.21.64.24]) by iwan-view3.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA05956; Mon, 30 Jul 2001 12:59:53 -0700 (PDT) Message-ID: <3B65BBCE.908CFC39@cisco.com> Date: Mon, 30 Jul 2001 15:55:58 -0400 From: "W. Mark Townsley" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org CC: l2tp@l2tp.net Subject: Agenda for 51st IETF L2TPEXT Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit THURSDAY, August 9, 2001 1300-1500 Afternoon Sessions I 1300 W. Mark Townsley, mark@townsley.net Agenda Bashing 1305 W. Mark Townsley, mark@townsley.net WG Status 1315 Elwin Eliazer, elwinietf@yahoo.com L2TP Session Update Mechanism draft-naveen-l2tpext-sessupdate-00.txt 1325 Reinaldo Penno, rpenno@nortelnetworks.com Fail over extensions for L2TP draft-vipin-l2tpext-failover-00.txt 1340 Reinaldo Penno, rpenno@nortelnetworks.com L2TP Tunnel Switching draft-penno-l2tp-switching-01.txt 1350 Nishit Vasavada, nishit@ambernetworks.com Encapsulation Services Protocol Service Type for L2TP draft-vasavada-l2tpext-es-svctype-00.txt 1400 W. Mark Townsley, mark@townsley.net L2TP Active Discovery Relay for PPPoE draft-dasilva-l2tp-relaysvc-00.txt 1410 W. Mark Townsley, mark@townsley.net Layer Two Tunneling Protocol "L2TP" draft-ietf-l2tpext-l2tp-base-00.txt 1430 Madhvi Verma, madhvi_verma@3com.com PPP Tunneling Using Layer Two Tunneling Protocol draft-ietf-l2tpext-l2tp-ppp-00.txt From owner-l2tp@diameter.org Tue Jul 31 05:52:51 2001 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 FAA10805 for ; Tue, 31 Jul 2001 05:52:50 -0400 (EDT) Received: (qmail 3522 invoked by alias); 31 Jul 2001 09:41:50 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 3516 invoked by uid 200); 31 Jul 2001 09:41:50 -0000 Received: (qmail 3511 invoked from network); 31 Jul 2001 09:41:48 -0000 Received: from eins.siemens.at (193.81.246.11) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Jul 2001 09:41:48 -0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id f6V9q3R22675 for ; Tue, 31 Jul 2001 11:52:03 +0200 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id LAA28912 for ; Tue, 31 Jul 2001 11:52:01 +0200 (MET DST) Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta) id xma028063; Tue, 31 Jul 01 11:51:32 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 11:51:31 +0200 Message-ID: From: Klausberger Walter To: l2tp@l2tp.net Subject: New L2TP MIB Date: Tue, 31 Jul 2001 11:51:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-l2tp@diameter.org Precedence: bulk Hi, I'd like to know, who will work on the new L2TP MIB, that will certainly be necessary after introducing the new L2TP concept according to the new agenda. As there are a lot of things to change, we should not delay the MIB as much this time and start as soon as possible. I think there are some major things to do... - separating PPP from L2TP - accept HDLC as one access transport protocol among others (eg. PPP over ATM/AAL5, PPP over Frame Relay, PPPoE,...) - provide additional tables for L2TP over AAL5, L2TP over Frame Relay,... - support different tables for LAC and LNS (L2TP is not symmetric, at least the sessions). - adapt the MIB to new L2TP base draft. - restructure the tables to support future extensions like PPP over L2TP ;-), DiffServ,... - and so on... I would like to volunteer in a new draft. So if someone already has some basic thoughts about that, maybe we should discuss this in London. Maybe we should provide the framework quite soon, so that drafts with extensions to L2TP can also handle the corresponding MIB extensions. - regards, walter From owner-l2tp@diameter.org Tue Jul 31 12:27:33 2001 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 MAA24763 for ; Tue, 31 Jul 2001 12:27:32 -0400 (EDT) Received: (qmail 8955 invoked by alias); 31 Jul 2001 16:16:17 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 8948 invoked by uid 200); 31 Jul 2001 16:16:16 -0000 Received: (qmail 8942 invoked from network); 31 Jul 2001 16:16:12 -0000 Received: from mail.occamnetworks.com (HELO occamnetworks.com) (216.64.159.194) by c900656-a.plstn1.sfba.home.com with SMTP; 31 Jul 2001 16:16:12 -0000 Received: from occamnetworks.com (honeycombs.occamnetworks.com [10.0.0.203]) by occamnetworks.com (8.10.1/8.10.1) with ESMTP id f6VGQAO07976; Tue, 31 Jul 2001 09:26:10 -0700 Message-ID: <3B66DC22.3F2378A8@occamnetworks.com> Date: Tue, 31 Jul 2001 09:26:10 -0700 From: Evan Caves Organization: Occam Networks, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Klausberger Walter CC: l2tp@l2tp.net Subject: Re: New L2TP MIB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-l2tp@diameter.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Walter, I cannot speak for the other editors but if you would like to help out on the L2TPng MIB then welcome. My thoughts on how we should evolve the MIB are similar to yours except that, like the revised L2TP base draft, we should provide a base L2TP MIB. That is reflect in the MIB what is in the base draft. Since we cannot predict what L2TP will transport in the future we should leave that to L2TP MIB extensions and provide support for those extensions in the base MIB. The current MIB provides for this (aleit for PPP payloads). I will not be in London but I think the other editors might be and you can always have a discussion with either the chair or other WG members. evan - Klausberger Walter wrote: > > Hi, > > I'd like to know, who will work on the new L2TP MIB, that will certainly be > necessary after introducing the new L2TP concept according to the new > agenda. As there are a lot of things to change, we should not delay the MIB > as much this time and start as soon as possible. > > I think there are some major things to do... > > - separating PPP from L2TP > - accept HDLC as one access transport protocol among others (eg. PPP over > ATM/AAL5, PPP over Frame Relay, PPPoE,...) > - provide additional tables for L2TP over AAL5, L2TP over Frame Relay,... > - support different tables for LAC and LNS (L2TP is not symmetric, at least > the sessions). > - adapt the MIB to new L2TP base draft. > - restructure the tables to support future extensions like PPP over L2TP > ;-), DiffServ,... > - and so on... > > I would like to volunteer in a new draft. So if someone already has some > basic thoughts about that, maybe we should discuss this in London. Maybe we > should provide the framework quite soon, so that drafts with extensions to > L2TP can also handle the corresponding MIB extensions. > > - regards, walter > > From owner-l2tp@diameter.org Tue Jul 31 12:32:05 2001 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 MAA25036 for ; Tue, 31 Jul 2001 12:32:05 -0400 (EDT) Received: (qmail 9709 invoked by alias); 31 Jul 2001 16:20:51 -0000 Delivered-To: l2tp-list@charizard.diameter.org Received: (qmail 9703 invoked by uid 200); 31 Jul 2001 16:20:50 -0000 Received: (qmail 9692 invoked by uid 500); 31 Jul 2001 16:20:45 -0000 Date: Tue, 31 Jul 2001 09:20:45 -0700 From: Pat Calhoun To: Evan Caves Cc: Klausberger Walter , l2tp@l2tp.net Subject: Re: New L2TP MIB Message-ID: <20010731092045.O6031@charizard.diameter.org> References: <3B66DC22.3F2378A8@occamnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B66DC22.3F2378A8@occamnetworks.com>; from evan@occamnetworks.com on Tue, Jul 31, 2001 at 09:26:10AM -0700 Sender: owner-l2tp@diameter.org Precedence: bulk I'll be there, but Ross will not. PatC On Tue, Jul 31, 2001 at 09:26:10AM -0700, Evan Caves wrote: > Hi Walter, > > I cannot speak for the other editors but if you would like to > help out on the L2TPng MIB then welcome. > > My thoughts on how we should evolve the MIB are similar to yours > except that, like the revised L2TP base draft, we should provide a > base L2TP MIB. That is reflect in the MIB what is in the base draft. > Since we cannot predict what L2TP will transport in the future we > should leave that to L2TP MIB extensions and provide support for > those extensions in the base MIB. The current MIB provides for > this (aleit for PPP payloads). > > I will not be in London but I think the other editors might be > and you can always have a discussion with either the chair or other > WG members. > > evan > - > > Klausberger Walter wrote: > > > > Hi, > > > > I'd like to know, who will work on the new L2TP MIB, that will certainly be > > necessary after introducing the new L2TP concept according to the new > > agenda. As there are a lot of things to change, we should not delay the MIB > > as much this time and start as soon as possible. > > > > I think there are some major things to do... > > > > - separating PPP from L2TP > > - accept HDLC as one access transport protocol among others (eg. PPP over > > ATM/AAL5, PPP over Frame Relay, PPPoE,...) > > - provide additional tables for L2TP over AAL5, L2TP over Frame Relay,... > > - support different tables for LAC and LNS (L2TP is not symmetric, at least > > the sessions). > > - adapt the MIB to new L2TP base draft. > > - restructure the tables to support future extensions like PPP over L2TP > > ;-), DiffServ,... > > - and so on... > > > > I would like to volunteer in a new draft. So if someone already has some > > basic thoughts about that, maybe we should discuss this in London. Maybe we > > should provide the framework quite soon, so that drafts with extensions to > > L2TP can also handle the corresponding MIB extensions. > > > > - regards, walter > > > >