As per Relevance of the word disconnect, we have this rfc below:
Network Working Group R.
Request for Comments: 3145 Deloitte
Category: Standards Track M.
3Com
J.
Sun
July 2001
L2TP Disconnect Cause
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document provides an extension to the Layer 2 Tunneling
("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP
sessions. L2TP lacks a mechanism for a host to provide PPP-
disconnect cause information to another host. This information
provided by the extension described in this document, can be
for accounting and debugging purposes
1.
L2TP [1] defines a general-purpose mechanism for tunneling PPP
various media. By design, it insulates L2TP operation from
details of the PPP session that is being encapsulated by L2TP.
are, however, cases where it may be desirable for PPP-
disconnect information to be provided to an L2TP host (L2TP
Concentrator [LAC] or L2TP Network Server [LNS]) in a
format. The lack of this information is especially a problem
the LAC and LNS are not owned or managed by the same entities
The Result and Error Codes defined for L2TP specify only L2TP
specific disconnect information. This document provides
additional Attribute Value Pair (AVP), called PPP Disconnect
Code, that MAY be used by an L2TP host to provide PPP-
Verma, et al. Standards Track [Page 1]
RFC 3145 L2TP Disconnect Cause Information July 2001
disconnect information to its peer. This AVP should be used
conjunction with, and not as a replacement for, the L2TP Result
Error Code AVPs
The PPP Disconnect Cause Code AVP can also be used to provide
human-readable disconnect reason to the user. This AVP should
have any effect on either the functioning of the tunnel or
functioning of the PPP session; it is for informational and
purposes only
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in BCP 14 [2].
2. PPP Disconnect Cause Code
The AVP is valid in the L2TP Call-Disconnect-Notify (CDN)
only, and it MUST NOT be marked Mandatory
The PPP Disconnect Cause Code AVP is encoded with Vendor ID 0 and
Attribute Type of PPP Disconnect Cause Code (46). The length of
Value field MUST be at least 11 octets. If the length is more
11 octets, the additional octets MUST contain a descriptive text
UTF-8 [3] format that can be displayed to the user or in a log file
The format of the AVP is shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Disconnect Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Protocol Number | Direction | Message...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: PPP Disconnect Cause Code
Mandatory (M) bit: MUST be 0.
Hidden (H) bit: MAY be 1 if the attribute is hidden
Length: The length of the entire attribute in octets, expressed as
single octet. The length MUST be at least 11.
Vendor ID: A two octet value in network byte order; set to 0
indicate that this is an IETF-assigned attribute
Verma, et al. Standards Track [Page 2]
RFC 3145 L2TP Disconnect Cause Information July 2001
Attribute Type: A two octet value in network byte order; set to 46
(PPP Disconnect Cause Code).
Disconnect Code: A two octet value in network byte order. (
in section 3 of this document.)
Control Protocol Number: The PPP Control Protocol number of
primary protocol known to have caused the error, if any. This
may be 0 unless mentioned otherwise in the description of
Disconnect Codes in section 3.
Direction: A single octet value; specifies the direction in which
Disconnect Code applies
The valid values of this field are
0: global
1: at
2: at
3-255:
This field SHOULD be 0 unless documented otherwise in the
of the specific Disconnect Code
3. Disconnect
This section contains the list of well-known values of the
Code field in the PPP Disconnect Cause Code AVP. The IANA
maintain a registry of the up-to-date values (see section 5 of
document). These values should be used in conjunction with
Direction value and the Control Protocol Number field to
the specific error condition
Unless documented otherwise for a specific Disconnect Code,
Direction value SHOULD be 0.
3.1. Global
The global error codes, given in the list below, are Disconnect
that do not relate to one particular PPP Control Protocol.
Control Protocol Number for these errors thus MUST be set to 0.
0 No information available
1 Administrative disconnect
2 Link Control Protocol (LCP) renegotiation at LNS disabled;
expects proxy LCP information, LAC did not send it
Verma, et al. Standards Track [Page 3]
RFC 3145 L2TP Disconnect Cause Information July 2001
3 Normal Disconnection, LCP Terminate-Request sent
Valid Direction values are
1: LCP Terminate-Request sent by
2: LCP Terminate-Request sent by
4 Compulsory encryption required by a PPP peer was refused by
other
Valid Direction values are
1: Required by local; refused by
2: Required by peer; refused by
3.2. LCP
The LCP error codes, listed below, are disconnect reasons that
directly related to the failure of PPP peers to negotiate
agreeable link parameters. The Control Protocol Number for
errors MUST be set to C021 hexadecimal (LCP).
5 FSM (Finite State Machine) Timeout error. (PPP event "TO-".)
6 No recognizable LCP packets were received
7 LCP failure: Magic Number error; link possibly looped back
8 LCP link failure: Echo Request timeout
9 Peer has unexpected Endpoint-Discriminator for
Multilink PPP (MP) bundle
10 Peer has unexpected MRRU for existing MP bundle
11 Peer has unexpected Short-Sequence-Number option for
MP bundle
12 Compulsory call-back required by a PPP peer was refused by
other
Valid Direction values are
1: Required by local; refused by
2: Required by peer; refused by
Verma, et al. Standards Track [Page 4]
RFC 3145 L2TP Disconnect Cause Information July 2001
3.3. Authentication
The authentication error codes, listed below, are disconnect
that are directly related to authentication failures between the
peers. The Control Protocol Number for such errors MUST
to the PPP Control Protocol number for the authentication protocol
use
13 FSM Timeout error
14 Peer has unexpected authenticated name for existing MP bundle
15 PPP authentication failure: Authentication
unacceptable
Valid Direction values are
1: All local authentication protocols were rejected by
peer
2: All authentication protocols requested by peer
unacceptable or unimplemented locally
16 PPP authentication failure: Authentication failed (bad name
password, or secret).
Valid Direction values are
1: Authentication of peer identity by local system
2: Authentication of local identity by peer system
3.4. Network Control Protocol (NCP)
NCP Errors are disconnect reasons that are directly related to
failure of PPP peers to negotiate a mutually agreeable set
parameters for the network protocols. The Control Protocol
for such errors SHOULD correspond to the PPP Network Control
number in use. Where multiple network protocols are in use,
copies of this AVP MAY be given to indicate failure reasons for
NCP. Otherwise, if only one copy of the AVP is given, the
Protocol Number SHOULD correspond to the last (most recent)
NCP
17 FSM Timeout error
18 No NCPs available (all disabled or rejected); no NCPs went
Opened state. (Control Protocol Number may be zero only
neither peer has enabled NCPs.)
Verma, et al. Standards Track [Page 5]
RFC 3145 L2TP Disconnect Cause Information July 2001
19 NCP failure: failed to converge on acceptable addresses
Valid Direction values are
1: Too many Configure-Naks received from peer
2: Too many Configure-Naks sent to peer
20 NCP failure: user not permitted to use any addresses
Valid Direction values are
1: Local link address not acceptable to peer
2: Remote link address not acceptable to local system
4.
This AVP MAY may be sent by either the LNS or LAC. It is
expected that this AVP will be most useful in sending
from the LNS to LAC in the compulsory tunneling case, although it
not precluded from use in any other case
A draft form of this AVP used Vendor ID 43 (3Com Corporation)
vendor-specific Attribute Type 46. Implementations MAY accept
with these values as equivalent to the message described in
document, but SHOULD NOT transmit an AVP using these values
5. Security
The integrity and confidentiality of this AVP relies on
underlying L2TP security mechanisms. It is intended for logging
diagnostic purposes in the event of PPP link failure and should
pose a threat to system security, but the AVP MAY be hidden
described in section 4.3 of RFC 2661.
The defined extension does not provide information that would
useful to an attacker. Future extensions should not be defined
lessen security. For instance, it is inappropriate to
distinguishing information that would inform the peer that a
authentication name is correct, but the password/secret is incorrect
Verma, et al. Standards Track [Page 6]
RFC 3145 L2TP Disconnect Cause Information July 2001
6. IANA
IANA has assigned an L2TP Attribute Type value of 46 for the
Disconnect Cause Code defined in Section 2.
This AVP includes an enumerated cause code value, called
"Disconnect Code." Values 0 through 20 are described in
document. Values 21 through 32767 (inclusive) are assigned by
IANA subject to IESG Approval. Values 32768 through 65279
(inclusive) are assigned by the IANA on a First Come First
basis, and are intended for vendor-specific features. Values 65280
through 65535 (inclusive) are allocated for Private or
Use, and no assignment through the IANA is expected
7.
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B
Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
2279, January 1998.
8.
The authors thank W. Mark Townsley and Thomas Narten for
comments and help
Verma, et al. Standards Track [Page 7]
RFC 3145 L2TP Disconnect Cause Information July 2001
9.
9.1. L2TP Working Group
W. Mark
Cisco
7025 Kit Creek
PO Box 14987
Research Triangle Park, NC 27709
EMail: townsley@cisco.
9.2. Authors'
Rohit
180 N. Stetson
Chicago IL 60601
Phone: +1 312 374 2475
Fax: +1 312 870 2475
EMail: rverma@dc.
Madhvi
3800 Golf
Rolling Meadows IL 60008
Phone: +1 847 262 2987
Fax: +1 847 262 2255
EMail: Madhvi_Verma@3com.
James
Sun
1 Network Drive MS UBUR02-212
Burlington MA 01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.
Verma, et al. Standards Track [Page 8]
RFC 3145 L2TP Disconnect Cause Information July 2001
10. Standard
10.1. IETF Intellectual Property
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP 11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights, which may cover technology that, may be required to
this standard. Please address the information to the IETF
Director
Verma, et al. Standards Track [Page 9]
RFC 3145 L2TP Disconnect Cause Information July 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Verma, et al. Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
