One document matched: draft-mistretta-l2tp-infomsg-01.txt
Differences from draft-mistretta-l2tp-infomsg-00.txt
Network Working Group T. Mistretta
Internet Draft Juniper Networks
Category: Standards Track
draft-mistretta-l2tp-infomsg-01.txt I. Goyret
Lucent Technologies
N. McGill
M. Townsley
cisco Systems
November 2002
L2TP Call Information Messages
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 10 of RFC 2026 [BCP9].
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. It is filed as "draft-
mistretta-l2tp-infomsg-01.txt" and expires April 30, 2003. Please
send comments to the L2TP mailing list (l2tp@l2tp.net).
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines additional L2TP AVPs to communicate
informational ASCII text messages between the tunnel endpoints during
call establishment. The message contents are not interpreted by the
receiving endpoint in any way but can be used for logging or
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 1]
INTERNET DRAFT L2TP Call Information Messages November 2002
debugging purposes.
Contents
Status of this Memo .......................................... 1
Abstract ..................................................... 1
1. Introduction .............................................. 2
1.1 Specification of Requirements ......................... 3
2. L2TP AVPs ................................................. 3
2.1 Common AVP Properties ................................. 3
2.2 Call-Information AVP .................................. 4
2.3 Platform-Information AVP .............................. 4
2.4 Software Information AVP .............................. 4
2.5 Vendor-Information AVP ................................ 5
3. RADIUS attributes ......................................... 5
3.1 Call-Information RADIUS attribute ..................... 5
3.2 Platform-Information RADIUS attribute ................. 6
3.3 Software-Information RADIUS attribute ................. 7
3.4 Vendor-Information RADIUS attribute ................... 8
4. Security Considerations ................................... 9
5. References ................................................ 9
6. IANA Considerations ....................................... 10
7. Authors' Addresses ........................................ 10
8. Full Copyright Statement .................................. 11
9. Expiration Date ........................................... 12
1. Introduction
It is often desirable to send adjunct information from the LAC to the
LNS during call setup. Some such information can be circuit
oriented, describing the attributes of the circuit interface. Other
information could describe the peer itself. In either case, the
information is typically used for for logging or debugging. L2TP
[RFC2661] already has a Physical Channel ID AVP that provides a
limited logging capability during call setup. It is limited in that
its length is only 4 octets. This draft defines extensions whereby
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 2]
INTERNET DRAFT L2TP Call Information Messages November 2002
human-readable ASCII strings are sent during call setup. The strings
are typed, but uninterpreted by L2TP. Their sole purposes are to
enhance logging and debugging capabilities in L2TP.
1.1 Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. L2TP AVPs
2.1 Common AVP Properties
All of the AVPs share the following traits:
The AVPs are not mandatory (the M bit MUST be set to 0). The AVP
SHOULD NOT be hidden (the H-bit SHOULD be set to 0).
The information strings themselves MUST be human readable, they
SHOULD contain UTF-8 encoded 10646 [RFC2279] characters using the
Default Language [BCP18].
The strings are not null-terminated. Valid lengths are between 1
and 253 octets, so it can fit on a RADIUS attribute.
The format of the information strings are purposely not defined.
The contents of the string MUST NOT be parsed nor interpreted by
the receiving L2TP endpoint.
As mentioned previously, possible uses of the strings are output
to a console or logging to a server. If the strings were to be
used in RADIUS accounting or authentication requests, it SHOULD be
mapped into corresponding RADIUS attributes defined in section 3.
The treatment of these AVPs through a L2TP tunnel switch follows
the "stacking" model introduced in the draft RFC [SESINFO]. This
model allows propagation of information from earlier L2TP nodes
while at the same time providing a capability to append new
information at each hop. A "list" format is defined for the AVPs,
where the last entry corresponds to the most recent sending node,
and all preceding values are for previous nodes. In the event
that an AVP is received where there is no local value to append,
an "empty" entry (one whose string length is zero) MUST be
appended. Interim L2TP tunnel switches can only append to existing
AVPs that are being passed through. They MUST NOT initiate a new
AVP if one does not already exist. This is done so that
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 3]
INTERNET DRAFT L2TP Call Information Messages November 2002
information across the AVPs can be correlated and reflected
accurately at the final location.
For incoming calls, the AVPs are valid either on ICRQ or ICCN. If
sent on both, the ICCN AVPs override the ICRQ values. For
outgoing calls, the AVPs are valid on OCRP and OCCN, with similar
override behavior.
All AVPs has the following format, the only difference being that
the attribute type is particular to the specific AVP being used.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor Id [IETF] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type [TBD] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length 0 | Information String 0 (1-253 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length 1 | Information String 1 (1-253 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length N | Information String N (1-253 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2 Call-Information AVP
The Call Information AVP, Attribute type TBD, allows a UTF-8 string
to be sent with a human readable description of the call. Examples
could include "Atlanta POP", or "Neptune-304x using frame2 module".
2.3 Platform-Information AVP
The Platform Information AVP, Attribute type TBD, allows a UTF-8
string to be sent with a human readable description of the platform.
Examples could be "Model 457", or "TPX-1700".
2.4 Software Information AVP
The Software Information AVP, Attribute type TBD, allows a UTF-8
string to be sent with a human readable description of the software
running on the platform. Examples could be "Version 4-0.12(c)-2" or
"Rev 10.4.2-beta".
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 4]
INTERNET DRAFT L2TP Call Information Messages November 2002
2.5 Vendor-Information AVP
The Vendor Information AVP, Attribute type TBD, allows a UTF-8 string
to be sent with a human readable description of the vendor of the
platform. Examples: "Hudson Computer Systems", or "Lightning
Networks".
3. RADIUS attributes
3.1 Call-Information RADIUS attribute
Description
This Attribute indicates text which MAY be supplied to the RADIUS
[RFC2865] server during authentication (Access-Request),
accounting (Accounting-Request) or tunnel-link accounting
[RFC2867] for the purposes of logging only. The message MUST NOT
be parsed and as such termination action MUST NOT be based on the
contents of this attribute.
In contrast to RADIUS Connect-Info [RFC2869], Call-Information
indicates where a call terminated, not what it terminated as. For
example, Call-Information MAY be used to report NAS module, slot,
port in a vendor specific format. Connect-Info MAY be used to
specify negotiated compression, connection protocol etc...
Multiple Call-Information's MAY be included and if any are
displayed, they MUST be displayed in the same order as they appear
in the packet.
A summary of the Call-Information Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
TBD for Call-Information.
Length
>= 3
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 5]
INTERNET DRAFT L2TP Call Information Messages November 2002
Text
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain UTF-8 encoded 10646 [RFC2279] characters
using the Default Language [BCP18]. The string is not null-
terminated.
For L2TP calls, this attribute SHOULD be used to log information
obtained via Call-Information AVPs. See section 2.
3.2 Platform-Information RADIUS attribute
Description
This Attribute indicates text which MAY be supplied to the RADIUS
[RFC2865] server during authentication (Access-Request),
accounting (Accounting-Request) or tunnel accounting [RFC2867] for
the purposes of logging only. The message MUST NOT be parsed and
as such termination action MUST NOT be based on the contents of
this attribute.
Multiple Platform-Information's MAY be included and if any are
displayed, they MUST be displayed in the same order as they appear
in the packet.
A summary of the Platform-Information Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
TBD for Platform-Information.
Length
>= 2
Text
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 6]
INTERNET DRAFT L2TP Call Information Messages November 2002
that the message contain UTF-8 encoded 10646 [RFC2279] characters
using the Default Language [BCP18]. The string is not null-
terminated.
For L2TP tunnels, this attribute MUST be used to log information
obtained via Platform-Information AVPs. See section 2. To cater for
L2TP multihop environments, if no Platform-Information is available,
then this attribute MUST be used with Length set to 2. Such
attributes indicate that no Platform-Information was available for a
particular node within the L2TP tunnel path. The sequence of RADIUS
Platform-Information attributes MUST follow that of any L2TP
Platform-Information AVPS received.
3.3 Software-Information RADIUS attribute
Description
This Attribute indicates text which MAY be supplied to the RADIUS
[RFC2865] server during authentication (Access-Request),
accounting (Accounting-Request) or tunnel accounting [RFC2867] for
the purposes of logging only. The message MUST NOT be parsed and
as such termination action MUST NOT be based on the contents of
this attribute.
Multiple Software-Information's MAY be included and if any are
displayed, they MUST be displayed in the same order as they appear
in the packet.
A summary of the Software-Information Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
TBD for Software-Information.
Length
>= 2
Text
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 7]
INTERNET DRAFT L2TP Call Information Messages November 2002
and MUST NOT affect operation of the protocol. It is recommended
that the message contain UTF-8 encoded 10646 [RFC2279] characters
using the Default Language [BCP18]. The string is not null-
terminated.
For L2TP tunnels, this attribute MUST be used to log information
obtained via Software-Information AVPs. See section 2. To cater for
L2TP multihop environments, if no Software-Information is available,
then this attribute MUST be used with Length set to 2. Such
attributes indicate that no Software-Information was available for a
particular node within the L2TP tunnel path. The sequence of RADIUS
Software-Information attributes MUST follow that of any L2TP
Software-Information AVPS received.
3.4 Vendor-Information RADIUS attribute
Description
This Attribute indicates text which MAY be supplied to the RADIUS
[RFC2865] server during authentication (Access-Request),
accounting (Accounting-Request) or tunnel accounting [RFC2867] for
the purposes of logging only. The message MUST NOT be parsed and
as such termination action MUST NOT be based on the contents of
this attribute.
Multiple Vendor-Information's MAY be included and if any are
displayed, they MUST be displayed in the same order as they appear
in the packet.
A summary of the Vendor-Information Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
TBD for Vendor-Information.
Length
>= 2
Text
The Text field is one or more octets, and its contents are
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 8]
INTERNET DRAFT L2TP Call Information Messages November 2002
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain UTF-8 encoded 10646 [RFC2279] characters
using the Default Language [BCP18]. The string is not null-
terminated.
For L2TP tunnels, this attribute MUST be used to log information
obtained via Vendor-Information AVPs. See section 2. To cater for
L2TP multihop environments, if no Vendor-Information is available,
then this attribute MUST be used with Length set to 2. Such
attributes indicate that no Vendor-Information was available for a
particular node within the L2TP tunnel path. The sequence of RADIUS
Vendor-Information attributes MUST follow that of any L2TP Vendor-
Information AVPS received.
4. Security Considerations
This document describes mechanisms where arbitrary, human-readable
information can be sent between L2TP peers. User of these AVPs
should have the understanding that any information sent is completely
insecure. If the information sent could be used for malicious
purposes, the use of the features described in this document
increases the possibility of that information being compromised. In
particular, since the text message AVP SHOULD NOT be hidden, even
that security feature cannot be employed.
5. References
[RFC2661] Townsley W., et al., "Layer Two Tunneling Protocol (L2TP)",
RFC 2661, August 1999.
[RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[RFC2866] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 9]
INTERNET DRAFT L2TP Call Information Messages November 2002
[BCP18] H. Alvestrand, "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[SESINFO] Palter, William et al, "L2TP Session Information", draft-ietf-
l2tpext-sesinfo-04.txt, February 2002.
6. IANA Considerations
The "Call Information", "Platform Information", "Software
Information", and "Vendor Information" AVPs needs to be assigned an
IETF "Attribute Type" from the "Control Message Attribute Value
Pairs" maintained by IANA for L2TP.
7. Authors' Addresses
Tom Mistretta
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
Email: tmistretta@juniper.net
Ignacio Goyret
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Email: igoyret@lucent.com
Mistretta, et al. draft-mistretta-l2tp-infomsg-01.txt [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-21 11:03:11 |