[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                    W. Simpson, Editor [DayDreamer]
Internet Draft
expires in six months                                        August 1998


                           PPP LCP Extensions                            -
                   draft-ietf-pppext-lcpext-ds-03.txt                    |


Status of this Memo

   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 (Northern Europe)                                    |
      ftp.nis.garr.it (Southern Europe)                                  |
      ftp.ietf.org (Eastern USA)                                         |
      ftp.isi.edu (Western USA)                                          |
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) William Allen Simpson (1992-1994, 1996-1998).  All
   Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [RFC-1661] 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 the Identification and Time-Remaining messages. |




Simpson                   expires in six months                 [Page i]

DRAFT                      PPP LCP extensions                August 1998


1.  Additional LCP Packets

   The Packet format and basic facilities are already defined for LCP    |
   [RFC-1661].

   Up-to-date values of the LCP Code field are specified in the most     |
   recent "Assigned Numbers" [RFC-1700].  This document concerns the
   following values:

      12      Identification
      13      Time-Remaining

   In this document, the key words "MAY", "MUST", "MUST NOT", "recom-    +
   mended", and "SHOULD", are to be interpreted as described in          +
   [RFC-2119].


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.



Simpson                   expires in six months                 [Page 1]

DRAFT                      PPP LCP extensions                August 1998


      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
      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.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     -
   |     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                August 1998


      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                August 1998


      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.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     -
   |     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                August 1998


   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.


Changes from RFC-1570                                                    +

   LCP Configuration Options were removed to separate documents.         +

   Otherwise, for your reading pleasure, this document has been wrapped  +
   in updated boilerplate.  It contains the complete text of the origi-  +
   nal version.  Not one word has been omitted.                          +


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.


















Simpson                   expires in six months                 [Page 5]

DRAFT                      PPP LCP extensions                August 1998


References

   [RFC-1661]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
               STD-51, DayDreamer, July 1994.                            |

   [RFC-1700]  Reynolds, J.K., Postel, J.B., "Assigned Numbers", STD-2,  |
               USC/Information Sciences Institute, October 1994.         |

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate       |
               Requirement Levels", BCP-14, Harvard University, March    |
               1997.


Contacts

   Comments about this document should be discussed on the ietf-
   ppp@merit.edu mailing list.

   This document was reviewed by 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@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)












Simpson                   expires in six months                 [Page 6]

DRAFT                      PPP LCP extensions                August 1998


Full Copyright Statement                                                 +

   Copyright (C) William Allen Simpson (1992-1994, 1996-1998).  All      +
   Rights Reserved.                                                      +

   This document and translations of it may be copied and furnished to   +
   others, and derivative works that comment on or otherwise explain it  +
   or assist in its implementation may be prepared, copied, published    +
   and distributed, in whole or in part, without restriction of any      +
   kind, provided that the above copyright notice and this paragraph are +
   included on all such copies and derivative works.  However, this doc- +
   ument itself may not be modified in any way, except as required to    +
   translate it into languages other than English.                       +

   This document and the information contained herein is provided on an  +
   "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR   +
   IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF  +
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED    +
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
































Simpson                   expires in six months                 [Page 7]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/