rfc1172.txt

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

Network Working Group                                         D. Perkins
Request for Comments: 1172                                           CMU
                                                                R. Hobby
                                                                UC Davis
                                                               July 1990



    The Point-to-Point Protocol (PPP) Initial Configuration Options



Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community.

   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.

   This proposal is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments on
   this memo should be submitted to the IETF Point-to-Point Protocol
   Working Group chair.

   Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) provides a method for transmitting
   datagrams over serial point-to-point links.  PPP is composed of

      1) a method for encapsulating datagrams over serial links,
      2) an extensible Link Control Protocol (LCP), and
      3) a family of Network Control Protocols (NCP) for establishing
      and configuring different network-layer protocols.

   The PPP encapsulating scheme, the basic LCP, and an NCP for
   controlling and establishing the Internet Protocol (IP) (called the
   IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol
   (PPP) [1].

   This document defines the intial options used by the LCP and IPCP. It
   also defines a method of Link Quality Monitoring and a simple
   authentication scheme.






Perkins & Hobby                                                 [Page i]

RFC 1172                  PPP Initial Options                  July 1990


                           Table of Contents


     1.     Introduction ..........................................    1

     2.     Link Control Protocol (LCP) Configuration Options .....    1
        2.1       Maximum-Receive-Unit ............................    2
        2.2       Async-Control-Character-Map .....................    3
        2.3       Authentication-Type .............................    5
        2.4       Magic-Number ....................................    7
        2.5       Link-Quality-Monitoring .........................   10
        2.6       Protocol-Field-Compression ......................   11
        2.7       Address-and-Control-Field-Compression ...........   13

     3.     Link Quality Monitoring ...............................   15
        3.1       Design Motivation ...............................   15
        3.2       Design Overview .................................   15
        3.3       Processes .......................................   16
        3.4       Counters ........................................   18
        3.5       Measurements, Calculations, State Variables .....   19
        3.6       Link-Quality-Report Packet Format ...............   21
        3.7       Policy Suggestions ..............................   25
        3.8       Example .........................................   25

     4.     Password Authentication Protocol ......................   27
        4.1       Packet Format ...................................   27
        4.2       Authenticate ....................................   29
        4.3       Authenticate-Ack ................................   31
        4.4       Authenticate-Nak ................................   32

     5.     IP Control Protocol (IPCP) Configuration Options ......   33
        5.1       IP-Addresses ....................................   34
        5.2       Compression-Type ................................   36

     REFERENCES ...................................................   37

     SECURITY CONSIDERATIONS ......................................   37

     AUTHOR'S ADDRESS .............................................   37












Perkins & Hobby                                                [Page ii]

RFC 1172                  PPP Initial Options                  July 1990


1.  Introduction

   The Point-to-Point Protocol (PPP) [1] proposes a standard method of
   encapsulating IP datagrams, and other Network Layer protocol
   information, over point-to-point links.  PPP also proposes an
   extensible Option Negotiation Protocol.  [1] specifies only the
   protocol itself; the initial set of Configuration Options are
   described in this document.  These Configuration Options allow MTUs
   to be changed, IP addresses to be dynamically assigned, header
   compression to be enabled, and much more.

   This memo is divided into several sections.  Section 2 describes
   Configuration Options for the Link Control Protocol. Section 3
   specifies the use of the Link Quality Monitoring option. Section 4
   defines a simple Password Authentication Protocol. Finally, Section 5
   specifies Configuration Options for the IP Control Protocol.

2.  Link Control Protocol (LCP) Configuration Options

   As described in [1], LCP Configuration Options allow modifications to
   the standard characteristics of a point-to-point link to be
   negotiated.  Negotiable modifications proposed in this document
   include such things as the maximum receive unit, async control
   character mapping, the link authentication method, etc.

   The initial proposed values for the LCP Configuration Option Type
   field (see [1]) are assigned as follows:

      1       Maximum-Receive-Unit
      2       Async-Control-Character-Map
      3       Authentication-Type
      4       NOT ASSIGNED
      5       Magic-Number
      6       Link-Quality-Monitoring
      7       Protocol-Field-Compression
      8       Address-and-Control-Field-Compression















Perkins & Hobby                                                 [Page 1]

RFC 1172                  PPP Initial Options                  July 1990


2.1.  Maximum-Receive-Unit

   Description

      This Configuration Option provides a way to negotiate the maximum
      packet size used across one direction of a link.  By default, all
      implementations must be able to receive frames with 1500 octets of
      Information.

      This Configuration Option may be sent to inform the remote end
      that you can receive larger frames, or to request that the remote
      end send you smaller frames.  If smaller frames are requested, an
      implementation MUST still be able to receive 1500 octet frames in
      case link synchronization is lost.

   A summary of the Maximum-Receive-Unit Configuration Option 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Maximum-Receive-Unit     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1

   Length

      4

   Maximum-Receive-Unit

      The Maximum-Receive-Unit field is two octets and indicates the new
      maximum receive unit.  The Maximum-Receive-Unit covers only the
      Data Link Layer Information field but not the header, trailer or
      any transparency bits or bytes.

   Default

      1500









Perkins & Hobby                                                 [Page 2]

RFC 1172                  PPP Initial Options                  July 1990


2.2.  Async-Control-Character-Map

   Description

      This Configuration Option provides a way to negotiate the use of
      control character mapping on asynchronous links.  By default, PPP
      maps all control characters into an appropriate two character
      sequence.  However, it is rarely necessary to map all control
      characters and often times it is unnecessary to map any
      characters.  A PPP implementation may use this Configuration
      Option to inform the remote end which control characters must
      remain mapped and which control characters need not remain mapped
      when the remote end sends them.  The remote end may still send
      these control characters in mapped format if it is necessary
      because of constraints at its (the remote) end.  This option does
      not solve problems for communications links that can send only 7-
      bit characters or that can not send all non-control characters.

      There may be some use of synchronous-to-asynchronous converters
      (some built into modems) in Point-to-point links resulting in a
      synchronous PPP implementation on one end of a link and an
      asynchronous implemention on the other. It is the responsibility
      of the converter to do all mapping conversions during operation.
      To enable this functionality, synchronous PPP implementations MUST
      always accept a Async-Control-Character-Map Configuration Option
      (it MUST always respond to an LCP Configure-Request specifying
      this Configuration Option with an LCP Configure-Ack). However,
      acceptance of this Configuration Option does not imply that the
      synchronous implementation will do any character mapping, since
      synchronous PPP uses bit-stuffing rather than character-stuffing.
      Instead, all such character mapping will be performed by the
      asynchronous-to-synchronous converter.

   A summary of the Async-Control-Character-Map Configuration Option
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Async-Control-Character-Map
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             (cont)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      2



Perkins & Hobby                                                 [Page 3]

RFC 1172                  PPP Initial Options                  July 1990


   Length

      6

   Async-Control-Character-Map

      The Async-Control-Character-Map field is four octets and indicates
      the new async control character map.  The map is encoded in big-
      endian fashion where each numbered bit corresponds to the ASCII
      control character of the same value.  If the bit is cleared to
      zero, then that ASCII control character need not be mapped.  If
      the bit is set to one, then that ASCII control character must
      remain mapped.  E.g., if bit 19 is set to zero, then the ASCII
      control character 19 (DC3, Control-S) may be sent in the clear.

   Default

      All ones (0xffffffff).

































Perkins & Hobby                                                 [Page 4]

RFC 1172                  PPP Initial Options                  July 1990


2.3.  Authentication-Type

   Description

      On some links it may be desirable to require a peer to
      authenticate itself before allowing Network Layer protocol data to
      be exchanged.  This Configuration Option provides a way to
      negotiate the use of a specific authentication protocol.  By
      default, authentication is not necessary.  If an implementation
      requires that the remote end authenticate with some specific
      authentication protocol, then it should negotiate the use of that
      authentication protocol with this Configuration Option.

      Successful negotiation of the Authentication-Type option adds an
      additional Authentication phase to the Link Control Protocol.
      This phase is after the Link Quality Determination phase, and
      before the Network Layer Protocol Configuration Negotiation phase.
      Advancement from the Authentication phase to the Network Layer
      Protocol Configuration Negotiation phase may not occur until the
      peer is successfully authenticated using the negotiated
      authentication protocol.

      An implementation may allow the remote end to pick from more than
      one authentication protocol. To achieve this, it may include
      multiple Authentication-Type Configuration Options in its
      Configure-Request packets.  An implementation receiving a
      Configure-Request specifying multiple Authentication-Types may
      accept at most one of the negotiable authentication protocols and
      should send a Configure-Reject specifying all of the other