home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-lcpext-ds-02.txt < prev    next >
Text File  |  1997-07-29  |  12KB  |  386 lines
  1.  
  2. Network Working Group                                 W. Simpson, Editor
  3. Internet Draft                                                DayDreamer
  4. expires in six months                                          July 1997
  5.  
  6.  
  7.                            PPP LCP Extensions
  8.                    draft-ietf-pppext-lcpext-ds-02.txt                    |
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    Distribution of this memo is unlimited.
  14.  
  15.    This document is an Internet-Draft.  Internet Drafts are working doc-
  16.    uments of the Internet Engineering Task Force (IETF), its Areas, and
  17.    its Working Groups.  Note that other groups may also distribute work-
  18.    ing documents as Internet Drafts.
  19.  
  20.    Internet Drafts are draft documents valid for a maximum of six
  21.    months, and may be updated, replaced, or obsoleted by other documents
  22.    at any time.  It is not appropriate to use Internet Drafts as refer-
  23.    ence material, or to cite them other than as a ``working draft'' or
  24.    ``work in progress.''
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  28.    Directories on:
  29.  
  30.       ftp.is.co.za (Africa)
  31.       nic.nordu.net (Europe)
  32.       ds.internic.net (US East Coast)
  33.       ftp.isi.edu (US West Coast)
  34.       munnari.oz.au (Pacific Rim)
  35.  
  36.  
  37. Abstract
  38.  
  39.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  40.    transporting multi-protocol datagrams over point-to-point links.  PPP
  41.    defines an extensible Link Control Protocol (LCP) for establishing,
  42.    configuring, and testing the data-link connection.  This document     |
  43.    defines additional LCP features that have been suggested over the
  44.    past few years.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Simpson                   expires in six months                 [Page i]
  54. DRAFT                      PPP LCP extensions                  July 1997
  55.  
  56.  
  57. 1.  Additional LCP Packets
  58.  
  59.    The Packet format and basic facilities are already defined for LCP
  60.    [1].
  61.  
  62.    Up-to-date values of the LCP Code field are specified in the most
  63.    recent "Assigned Numbers" [2].  This document concerns the following
  64.    values:
  65.  
  66.       12      Identification
  67.       13      Time-Remaining
  68.  
  69.  
  70.  
  71. 1.1.  Identification
  72.  
  73.    Description
  74.  
  75.       This Code provides a method for an implementation to identify
  76.       itself to its peer.  This Code might be used for many diverse pur-
  77.       poses, such as link troubleshooting, license enforcement, etc.
  78.  
  79.       Identification is a Link Maintenance packet.  Identification pack-
  80.       ets MAY be sent at any time, including before LCP has reached the
  81.       Opened state.
  82.  
  83.       The sender transmits a LCP packet with the Code field set to 12
  84.       (Identification), the Identifier field set, the local Magic-Number
  85.       (if any) inserted, and the Message field filled with any desired
  86.       data, but not exceeding the default MRU minus eight.
  87.  
  88.       Receipt of an Identification packet causes the RXR or RUC event.
  89.       There is no response to the Identification packet.
  90.  
  91.       Receipt of a Code-Reject for the Identification packet SHOULD gen-
  92.       erate the RXJ+ (permitted) event.
  93.  
  94.    Rationale:
  95.  
  96.       This feature is defined as part of LCP, rather than as a separate
  97.       PPP Protocol, in order that its benefits may be available during
  98.       the earliest possible stage of the Link Establishment phase.  It
  99.       allows an operator to learn the identification of the peer even
  100.       when negotiation is not converging.  Non-LCP packets cannot be
  101.       sent during the Link Establishment phase.
  102.  
  103.       This feature is defined as a separate LCP Code, rather than a Con-
  104.       figuration-Option, so that the peer need not include it with other
  105.  
  106.  
  107.  
  108. Simpson                   expires in six months                 [Page 1]
  109. DRAFT                      PPP LCP extensions                  July 1997
  110.  
  111.  
  112.       items in configuration packet exchanges, and handle "corrected"
  113.       values or "rejection", since its generation is both rare and in
  114.       one direction.  It is recommended that Identification packets be
  115.       sent whenever a Configure-Reject is sent or received, as a final
  116.       message when negotiation fails to converge, and when LCP reaches
  117.       the Opened state.
  118.  
  119.    A summary of the Identification packet format is shown below.  The
  120.    fields are transmitted from left to right.
  121.  
  122.     0                   1                   2                   3
  123.     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
  124.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  125.    |     Code      |  Identifier   |            Length             |
  126.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  127.    |                         Magic-Number                          |
  128.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  129.    |    Message ...
  130.    +-+-+-+-+-+-+-+-+
  131.  
  132.    Code
  133.  
  134.       12 for Identification
  135.  
  136.    Identifier
  137.  
  138.       The Identifier field MUST be changed for each Identification sent.
  139.  
  140.    Length
  141.  
  142.       >= 8
  143.  
  144.    Magic-Number
  145.  
  146.       The Magic-Number field is four octets and aids in detecting links
  147.       which are in the looped-back condition.  Until the Magic-Number
  148.       Configuration Option has been successfully negotiated, the Magic-
  149.       Number MUST be transmitted as zero.  See the Magic-Number Configu-
  150.       ration Option for further explanation.
  151.  
  152.    Message
  153.  
  154.       The Message field is zero or more octets, and its contents are
  155.       implementation dependent.  It is intended to be human readable,
  156.       and MUST NOT affect operation of the protocol.  It is recommended
  157.       that the message contain displayable ASCII characters 32 through
  158.       126 decimal.  Mechanisms for extension to other character sets are
  159.       the topic of future research.  The size is determined from the
  160.  
  161.  
  162.  
  163. Simpson                   expires in six months                 [Page 2]
  164. DRAFT                      PPP LCP extensions                  July 1997
  165.  
  166.  
  167.       Length field.
  168.  
  169.       Implementation Note:
  170.  
  171.          The Message will usually contain such things as the sender's
  172.          hardware type, PPP software revision level, and PPP product
  173.          serial number, MIB information such as link speed and interface
  174.          name, and any other information that the sender thinks might be
  175.          useful in debugging connections.  The format is likely to be
  176.          different for each implementor, so that those doing serial num-
  177.          ber tracking can validate their numbers.  A robust implementa-
  178.          tion SHOULD treat the Message as displayable text, and SHOULD   |
  179.          be able to receive and display a full MRU length Message.
  180.  
  181.  
  182. 1.2.  Time-Remaining
  183.  
  184.    Description
  185.  
  186.       This Code provides a mechanism for notifying the peer of the time
  187.       remaining in this session.
  188.  
  189.       The nature of this information is advisory only.  It is intended
  190.       that only one side of the connection will send this packet (gener-
  191.       ally a "network access server").  The session is actually con-
  192.       cluded by the Terminate-Request packet.
  193.  
  194.       Time-Remaining is a Link Maintenance packet.  Time-Remaining pack-
  195.       ets may only be sent in the LCP Opened state.
  196.  
  197.       The sender transmits a LCP packet with the Code field set to 13
  198.       (Time-Remaining), the Identifier field set, the local Magic-Number
  199.       (if any) inserted, and the Message field filled with any desired
  200.       data, but not exceeding the peer's established MRU minus twelve.
  201.  
  202.       Receipt of an Time-Remaining packet causes the RXR or RUC event.
  203.       There is no response to the Time-Remaining packet.
  204.  
  205.       Receipt of a Code-Reject for the Time-Remaining packet SHOULD gen-
  206.       erate the RXJ+ (permitted) event.
  207.  
  208.    Rationale:
  209.  
  210.       This notification is defined as a separate LCP Code, rather than a
  211.       Configuration-Option, in order that changes and warning messages
  212.       may occur dynamically during the session, and that the information
  213.       might be determined after Authentication has occurred.  Typically,
  214.       this packet is sent when the link enters Network-Layer Protocol
  215.  
  216.  
  217.  
  218. Simpson                   expires in six months                 [Page 3]
  219. DRAFT                      PPP LCP extensions                  July 1997
  220.  
  221.  
  222.       phase, and at regular intervals throughout the session, particu-
  223.       larly near the end of the session.
  224.  
  225.    A summary of the Time-Remaining packet format is shown below.  The
  226.    fields are transmitted from left to right.
  227.  
  228.     0                   1                   2                   3
  229.     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
  230.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  231.    |     Code      |  Identifier   |            Length             |
  232.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  233.    |                         Magic-Number                          |
  234.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.    |                       Seconds-Remaining                       |
  236.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.    |    Message ...
  238.    +-+-+-+-+-+-+-+-+
  239.  
  240.    Code
  241.  
  242.       13 for Time-Remaining
  243.  
  244.    Identifier
  245.  
  246.       The Identifier field MUST be changed for each Time-Remaining sent.
  247.  
  248.    Length
  249.  
  250.       >= 12
  251.  
  252.    Magic-Number
  253.  
  254.       The Magic-Number field is four octets and aids in detecting links
  255.       which are in the looped-back condition.  Until the Magic-Number
  256.       Configuration Option has been successfully negotiated, the Magic-
  257.       Number MUST be transmitted as zero.  See the Magic-Number Configu-
  258.       ration Option for further explanation.
  259.  
  260.    Seconds-Remaining
  261.  
  262.       The Seconds-Remaining field is four octets and indicates the num-
  263.       ber of integral seconds remaining in this session.  This 32 bit
  264.       unsigned value is sent most significant octet first.  A value of
  265.       0xffffffff (all ones) represents no timeout, or "forever".
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273. Simpson                   expires in six months                 [Page 4]
  274. DRAFT                      PPP LCP extensions                  July 1997
  275.  
  276.  
  277.    Message
  278.  
  279.       The Message field is zero or more octets, and its contents are
  280.       implementation dependent.  It is intended to be human readable,
  281.       and MUST NOT affect operation of the protocol.  It is recommended
  282.       that the message contain displayable ASCII characters 32 through
  283.       126 decimal.  Mechanisms for extension to other character sets are
  284.       the topic of future research.  The size is determined from the
  285.       Length field.
  286.  
  287.  
  288. Security Considerations                                                  -
  289.  
  290.    There are no known security vulnerabilities.                          |
  291.  
  292.  
  293. Acknowledgements
  294.  
  295.    The Identification feature was suggested by Bob Sutterfield.          |
  296.  
  297.    The Time-Remaining feature was suggested by Brad Parker.              |
  298.  
  299.    Special thanks to Ascend Communications for providing computing       |
  300.    resources and network access support for writing this specification.
  301.  
  302.  
  303. References
  304.  
  305.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",       |
  306.          STD-51, RFC-1661, December 1993.
  307.  
  308.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
  309.          July 1992.                                                      -
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328. Simpson                   expires in six months                 [Page 5]
  329. DRAFT                      PPP LCP extensions                  July 1997
  330.  
  331.  
  332. Contacts
  333.  
  334.    Comments about this document should be discussed on the
  335.    ietf-ppp@merit.edu mailing list.
  336.  
  337.    This document is a submission to the Point-to-Point Protocol Working
  338.    Group of the Internet Engineering Task Force (IETF).  The working
  339.    group can be contacted via the current chair:
  340.  
  341.       Karl Fox
  342.       Ascend Communications
  343.       3518 Riverside Drive  Suite 101
  344.       Columbus, Ohio  43221
  345.  
  346.           karl@MorningStar.com
  347.           karl@Ascend.com
  348.  
  349.    Questions about this document can also be directed to:
  350.  
  351.       William Allen Simpson
  352.       DayDreamer
  353.       Computer Systems Consulting Services
  354.       1384 Fontaine
  355.       Madison Heights, Michigan  48071
  356.  
  357.           wsimpson@UMich.edu
  358.           wsimpson@GreenDragon.com (preferred)
  359.           bsimpson@MorningStar.com
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383. Simpson                   expires in six months                 [Page 6]
  384.  
  385.  
  386.