rfc1548.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         W. Simpson
Request for Comments: 1548                                    Daydreamer
Obsoletes: RFC 1331                                        December 1993
Category: Standards Track


                   The Point-to-Point Protocol (PPP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   is comprised of three main components:

      1. A method for encapsulating multi-protocol datagrams.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols (NCPs) for establishing
         and configuring different network-layer protocols.

   This document defines the PPP organization and methodology, and the
   PPP encapsulation, together with an extensible option negotiation
   mechanism which is able to negotiate a rich assortment of
   configuration parameters and provides additional management
   functions.  The PPP Link Control Protocol (LCP) is described in terms
   of this mechanism.

   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the [e-mail] mailing list.











Simpson                                                         [Page 1]

RFC 1548              The Point-to-Point Protocol          December 1993


Table of Contents

   1.   Introduction ................................................3
   1.1  Specification of Requirements ...............................4
   1.2  Terminology .................................................5
   2.   PPP Encapsulation ...........................................5
   3.   PPP Link Operation ..........................................8
   3.1  Overview ....................................................8
   3.2  Phase Diagram ...............................................8
   3.3  Link Dead (physical-layer not ready) ........................9
   3.4  Link Establishment Phase ....................................9
   3.5  Authentication Phase ........................................9
   3.6  Network-Layer Protocol Phase ................................10
   3.7  Link Termination Phase ......................................10
   4.   The Option Negotiation Automaton ............................11
   4.1  State Diagram ...............................................12
   4.2  State Transition Table ......................................14
   4.3  A Day in the Life ...........................................15
   4.4  States ......................................................16
   4.5  Events ......................................................19
   4.6  Actions .....................................................23
   4.7  Loop Avoidance ..............................................26
   4.8  Counters and Timers .........................................26
   5.   LCP Packet Formats ..........................................27
   5.1  Configure-Request ...........................................29
   5.2  Configure-Ack ...............................................30
   5.3  Configure-Nak ...............................................31
   5.4  Configure-Reject ............................................33
   5.5  Terminate-Request and Terminate-Ack .........................34
   5.6  Code-Reject .................................................35
   5.7  Protocol-Reject .............................................36
   5.8  Echo-Request and Echo-Reply .................................37
   5.9  Discard-Request .............................................39
   6.   LCP Configuration Options ...................................40
   6.1  Maximum-Receive-Unit ........................................41
   6.2  Async-Control-Character-Map .................................42
   6.3  Authentication-Protocol .....................................43
   6.4  Quality-Protocol ............................................45
   6.5  Magic-Number ................................................46
   6.6  Protocol-Field-Compression ..................................49
   6.7  Address-and-Control-Field-Compression .......................50
   APPENDIX A. LCP Recommended Options ..............................51
   SECURITY CONSIDERATIONS ..........................................51
   REFERENCES .......................................................52
   ACKNOWLEDGEMENTS .................................................52
   CHAIR'S ADDRESS ..................................................52
   EDITOR'S ADDRESS .................................................53




Simpson                                                         [Page 2]

RFC 1548              The Point-to-Point Protocol          December 1993


1. Introduction

   Encapsulation

      The PPP encapsulation provides for multiplexing of different
      network-layer protocols simultaneously over the same link.  It is
      intended that PPP provide a common solution for easy connection of
      a wide variety of hosts, bridges and routers [1].

      The PPP encapsulation has been carefully designed to retain
      compatibility with most commonly used supporting hardware.

      Only 8 additional octets are necessary to form the encapsulation
      when used with the default HDLC framing.  In environments where
      bandwidth is at a premium, the encapsulation and framing may be
      shortened to 2 or 4 octets.

      To support high speed implementations, the default encapsulation
      uses only simple fields, only one of which needs to be examined
      for demultiplexing.  The default header and information fields
      fall on 32-bit boundaries, and the trailer may be padded to an
      arbitrary boundary.

    Link Control Protocol

      In order to be sufficiently versatile to be portable to a wide
      variety of environments, PPP provides a Link Control Protocol
      (LCP).  The LCP is used to automatically agree upon the
      encapsulation format options, handle varying limits on sizes of
      packets, authenticate the identity of its peer on the link,
      determine when a link is functioning properly and when it is
      defunct, detect a looped-back link and other common
      misconfiguration errors, and terminate the link.

    Network Control Protocols

      Point-to-Point links tend to exacerbate many problems with the
      current family of network protocols.  For instance, assignment and
      management of IP addresses, which is a problem even in LAN
      environments, is especially difficult over circuit-switched
      point-to-point links (such as dial-up modem servers).  These
      problems are handled by a family of Network Control Protocols
      (NCPs), which each manage the specific needs required by their
      respective network-layer protocols.  These NCPs are defined in
      companion documents.






Simpson                                                         [Page 3]

RFC 1548              The Point-to-Point Protocol          December 1993


    Configuration

      It is intended that PPP links be easy to configure.  By design,
      the standard defaults handle all common configurations.  The
      implementor can specify improvements to the default configuration,
      which are automatically communicated to the peer without operator
      intervention.  Finally, the operator may explicitly configure
      options for the link which enable the link to operate in
      environments where it would otherwise be impossible.

      This self-configuration is implemented through an extensible
      option negotiation mechanism, wherein each end of the link
      describes to the other its capabilities and requirements.
      Although the option negotiation mechanism described in this
      document is specified in terms of the Link Control Protocol (LCP),
      the same facilities are designed to be used by other control
      protocols, especially the family of NCPs.

1.1 Specification of Requirements

      In this document, several words are used to signify the
      requirements of the specification.  These words are often
      capitalized.

    MUST

      This word, or the adjective "required", means that the definition
      is an absolute requirement of the specification.

    MUST NOT

      This phrase means that the definition is an absolute prohibition
      of the specification.

    SHOULD

      This word, or the adjective "recommended", means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications must be understood and carefully
      weighed before choosing a different course.

    MAY

      This word, or the adjective "optional", means that this item is
      one of an allowed set of alternatives.  An implementation which
      does not include this option MUST be prepared to interoperate with
      another implementation which does include the option.




Simpson                                                         [Page 4]

RFC 1548              The Point-to-Point Protocol          December 1993


1.2 Terminology

      This document frequently uses the following terms:

    datagram

      The unit of transmission in the network layer (such as IP).  A
      datagram may be encapsulated in one or more packets passed to the
      data link layer.

    frame

      The unit of transmission at the data link layer.  A frame may
      include a header and/or a trailer, along with some number of units
      of data.

    packet

      The basic unit of encapsulation, which is passed across the
      interface between the network layer and the data link layer.  A
      packet is usually mapped to a frame; the exceptions are when data
      link layer fragmentation is being performed, or when multiple
      packets are incorporated into a single frame.

    peer

      The other end of the point-to-point link.

    silently discard

      This means the implementation discards the packet without further
      processing.  The implementation SHOULD provide the capability of
      logging the error, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.

2. PPP Encapsulation

   The PPP encapsulation is used to disambiguate multiprotocol
   datagrams.  This encapsulation requires framing to indicate the
   beginning and end of the encapsulation.  Methods of providing framing
   are specified in companion documents.









Simpson                                                         [Page 5]

RFC 1548              The Point-to-Point Protocol          December 1993


   A summary of the PPP encapsulation is shown below.  The fields are
   transmitted from left to right.

              +----------+-------------+---------+
              | Protocol | Information | Padding |
              | 16 bits  |      *      |    *    |
              +----------+-------------+---------+

    Protocol Field

      The Protocol field is two octets and its value identifies the
      datagram encapsulated in the Information field of the packet.  The
      field is transmitted and received most significant octet first.

      The structure of this field is consistent with the ISO 3309
      extension mechanism for address fields.  All Protocols MUST be
      odd; the least significant bit of the least significant octet MUST
      equal "1".  Also, all Protocols MUST be assigned such that the
      least significant bit of the most significant octet equals "0".
      Frames received which don't comply with these rules MUST be
      treated as having an unrecognized Protocol.

      Protocol field values in the "0***" to "3***" range identify the
      network-layer protocol of specific packets, and values in the
      "8***" to "b***" range identify packets belonging to the
      associated Network Control Protocols (NCPs), if any.

      Protocol field values in the "4***" to "7***" range are used for
      protocols with low volume traffic which have no associated NCP.
      Protocol field values in the "c***" to "f***" range identify
      packets as link-layer Control Protocols (such as LCP).

      Up-to-date values of the Protocol field are specified in the most
      recent "Assigned Numbers" RFC [2].  Current values are assigned as
      follows:

           Value (in hex)  Protocol Name

           0001            Padding Protocol
           0003 to 001f    reserved (transparency inefficient)
           0021            Internet Protocol
           0023            OSI Network Layer
           0025            Xerox NS IDP
           0027            DECnet Phase IV
           0029            Appletalk
           002b            Novell IPX
           002d            Van Jacobson Compressed TCP/IP
           002f            Van Jacobson Uncompressed TCP/IP



Simpson                                                         [Page 6]

RFC 1548              The Point-to-Point Protocol          December 1993