Network Working Group W. Simpson, Editor Internet Draft DayDreamer expires in six months July 1997 PPP LCP Extensions draft-ietf-pppext-lcpext-ds-02.txt | Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing 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 not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document | defines additional LCP features that have been suggested over the past few years. Simpson expires in six months [Page i] DRAFT PPP LCP extensions July 1997 1. Additional LCP Packets The Packet format and basic facilities are already defined for LCP [1]. Up-to-date values of the LCP Code field are specified in the most recent "Assigned Numbers" [2]. This document concerns the following values: 12 Identification 13 Time-Remaining 1.1. Identification Description This Code provides a method for an implementation to identify itself to its peer. This Code might be used for many diverse pur- poses, such as link troubleshooting, license enforcement, etc. Identification is a Link Maintenance packet. Identification pack- ets MAY be sent at any time, including before LCP has reached the Opened state. The sender transmits a LCP packet with the Code field set to 12 (Identification), the Identifier field set, the local Magic-Number (if any) inserted, and the Message field filled with any desired data, but not exceeding the default MRU minus eight. Receipt of an Identification packet causes the RXR or RUC event. There is no response to the Identification packet. Receipt of a Code-Reject for the Identification packet SHOULD gen- erate the RXJ+ (permitted) event. Rationale: This feature is defined as part of LCP, rather than as a separate PPP Protocol, in order that its benefits may be available during the earliest possible stage of the Link Establishment phase. It allows an operator to learn the identification of the peer even when negotiation is not converging. Non-LCP packets cannot be sent during the Link Establishment phase. This feature is defined as a separate LCP Code, rather than a Con- figuration-Option, so that the peer need not include it with other Simpson expires in six months [Page 1] DRAFT PPP LCP extensions July 1997 items in configuration packet exchanges, and handle "corrected" values or "rejection", since its generation is both rare and in one direction. It is recommended that Identification packets be sent whenever a Configure-Reject is sent or received, as a final message when negotiation fails to converge, and when LCP reaches the Opened state. A summary of the Identification packet format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ... +-+-+-+-+-+-+-+-+ Code 12 for Identification Identifier The Identifier field MUST be changed for each Identification sent. Length >= 8 Magic-Number The Magic-Number field is four octets and aids in detecting links which are in the looped-back condition. Until the Magic-Number Configuration Option has been successfully negotiated, the Magic- Number MUST be transmitted as zero. See the Magic-Number Configu- ration Option for further explanation. Message The Message field is zero 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 displayable ASCII characters 32 through 126 decimal. Mechanisms for extension to other character sets are the topic of future research. The size is determined from the Simpson expires in six months [Page 2] DRAFT PPP LCP extensions July 1997 Length field. Implementation Note: The Message will usually contain such things as the sender's hardware type, PPP software revision level, and PPP product serial number, MIB information such as link speed and interface name, and any other information that the sender thinks might be useful in debugging connections. The format is likely to be different for each implementor, so that those doing serial num- ber tracking can validate their numbers. A robust implementa- tion SHOULD treat the Message as displayable text, and SHOULD | be able to receive and display a full MRU length Message. 1.2. Time-Remaining Description This Code provides a mechanism for notifying the peer of the time remaining in this session. The nature of this information is advisory only. It is intended that only one side of the connection will send this packet (gener- ally a "network access server"). The session is actually con- cluded by the Terminate-Request packet. Time-Remaining is a Link Maintenance packet. Time-Remaining pack- ets may only be sent in the LCP Opened state. The sender transmits a LCP packet with the Code field set to 13 (Time-Remaining), the Identifier field set, the local Magic-Number (if any) inserted, and the Message field filled with any desired data, but not exceeding the peer's established MRU minus twelve. Receipt of an Time-Remaining packet causes the RXR or RUC event. There is no response to the Time-Remaining packet. Receipt of a Code-Reject for the Time-Remaining packet SHOULD gen- erate the RXJ+ (permitted) event. Rationale: This notification is defined as a separate LCP Code, rather than a Configuration-Option, in order that changes and warning messages may occur dynamically during the session, and that the information might be determined after Authentication has occurred. Typically, this packet is sent when the link enters Network-Layer Protocol Simpson expires in six months [Page 3] DRAFT PPP LCP extensions July 1997 phase, and at regular intervals throughout the session, particu- larly near the end of the session. A summary of the Time-Remaining packet format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds-Remaining | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ... +-+-+-+-+-+-+-+-+ Code 13 for Time-Remaining Identifier The Identifier field MUST be changed for each Time-Remaining sent. Length >= 12 Magic-Number The Magic-Number field is four octets and aids in detecting links which are in the looped-back condition. Until the Magic-Number Configuration Option has been successfully negotiated, the Magic- Number MUST be transmitted as zero. See the Magic-Number Configu- ration Option for further explanation. Seconds-Remaining The Seconds-Remaining field is four octets and indicates the num- ber of integral seconds remaining in this session. This 32 bit unsigned value is sent most significant octet first. A value of 0xffffffff (all ones) represents no timeout, or "forever". Simpson expires in six months [Page 4] DRAFT PPP LCP extensions July 1997 Message The Message field is zero 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 displayable ASCII characters 32 through 126 decimal. Mechanisms for extension to other character sets are the topic of future research. The size is determined from the Length field. Security Considerations - There are no known security vulnerabilities. | Acknowledgements The Identification feature was suggested by Bob Sutterfield. | The Time-Remaining feature was suggested by Brad Parker. | Special thanks to Ascend Communications for providing computing | resources and network access support for writing this specification. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", | STD-51, RFC-1661, December 1993. [2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700, July 1992. - Simpson expires in six months [Page 5] DRAFT PPP LCP extensions July 1997 Contacts Comments about this document should be discussed on the ietf-ppp@merit.edu mailing list. This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chair: Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, Ohio 43221 karl@MorningStar.com karl@Ascend.com Questions about this document can also be directed to: William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Simpson expires in six months [Page 6]