rfc2023.txt

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


RFC 2023                 IP Version 6 over PPP              October 1996


      A new Configure-Request SHOULD NOT be sent to the peer until
      normal processing would cause it to be sent (that is, until a
      Configure-Nak is received or the Restart timer runs out).

      A new Configure-Request MUST NOT contain the Interface-Token
      option if a valid Interface-Token Configure-Reject is received.

      Reception of a Configure-Nak with a suggested Interface-Token
      different from that of the last Configure-Nak sent to the peer
      indicates a unique Interface-Token.  In this case a new
      Configure-Request MUST be sent with the token value suggested in
      the last Configure-Nak from the peer.  But if the received
      Interface-Token is equal to the one sent in the last Configure-
      Nak, a new Interface-Token MUST be chosen.  In this case, a new
      Configure-Request SHOULD be sent with the new tentative
      Interface-Token.  This sequence (transmit Configure-Request,
      receive Configure-Request, transmit Configure-Nak, receive
      Configure-Nak) might occur a few times, but it is extremely
      unlikely to occur repeatedly.  More likely, the Interface-Tokens
      chosen at either end will quickly diverge, terminating the
      sequence.

      If negotiation about the Interface-Token is required, and the peer
      did not provide the option in its Configure-Request, the option
      SHOULD be appended to a Configure-Nak.  The tentative value of the
      Interface-Token given must be acceptable as the remote Interface-
      Token; i.e. should be different from the token value selected for
      the local end of the PPP link.  The next Configure-Request from
      the peer may include this option.  If the next Configure-Request
      does not include this option the peer MUST NOT send another
      Configure-Nak with this option included. It should assume that the
      peer's implementation does not support this option.

      By default, an implementation SHOULD attempt to negotiate the
      Interface-Token for its end of the PPP connection.
















Haskin & Allen              Standards Track                     [Page 6]

RFC 2023                 IP Version 6 over PPP              October 1996


   A summary of the Interface-Token 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     |        Interface-Token
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Interface-Token (cont)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1

   Length

      6

   Interface-Token

      The 32-bit Interface-Token which is very likely to  be unique on
      the link or zero if a good source of uniqueness can not be found.

   Default Token Value

      If no valid interface token can be successfully negotiated, no
      default Interface-Token value should be assumed. The procedures
      for recovering from such a case are unspecified. One approach is
      to manually configure the interface token of the interface.

4.2.  IPv6-Compression-Protocol

   Description

      This Configuration Option provides a way to negotiate the use of a
      specific IPv6 packet compression protocol.  The IPv6-Compression-
      Protocol Configuration Option is used to indicate the ability to
      receive compressed packets.  Each end of the link must separately
      request this option if bi-directional compression is desired.  By
      default, compression is not enabled.

      IPv6 compression negotiated with this option is specific to IPv6
      datagrams and is not to be confused with compression resulting
      from negotiations via Compression Control Protocol (CCP), which
      potentially effect all datagrams.





Haskin & Allen              Standards Track                     [Page 7]

RFC 2023                 IP Version 6 over PPP              October 1996


   A summary of the IPv6-Compression-Protocol 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     |   IPv6-Compression-Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Type

      2

   Length

      >= 4

   IPv6-Compression-Protocol

      The IPv6-Compression-Protocol field is two octets and indicates
      the compression protocol desired.  Values for this field are
      always the same as the PPP Data Link Layer Protocol field values
      for that same compression protocol.

      Up-to-date values of the IPv6-Compression-Protocol field are
      specified in the most recent "Assigned Numbers" RFC [5].

      Current values are assigned as follows:

      Value (in hex)          Protocol

      004f                    IPv6 Header Compression

   Data

      The Data field is zero or more octets and contains additional data
      as determined by the particular compression protocol.

   Default

      No IPv6 compression protocol enabled.







Haskin & Allen              Standards Track                     [Page 8]

RFC 2023                 IP Version 6 over PPP              October 1996


5.  Stateless Autoconfiguration and Link-Local Addresses

   The interface token, which is used for forming IPv6 addresses of a
   PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP
   connection setup (see section 4.1). If no valid interface token has
   been successfully negotiated, procedures for recovering from such a
   case are unspecified.  One approach is to manually configure the
   interface token of the interface.

   As long as the interface token is negotiated in the IPV6CP phase of
   the PPP connection setup,  it is redundant to perform duplicate
   address detection as a part of the IPv6 Stateless Autoconfiguration
   protocol [3].  Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Token option enabled the default value of the
   DupAddrDetectTransmits autoconfiguration variable [3] be zero.

   Link-local addresses of PPP interfaces have the following format:

   | 10 bits  |              86 bits               |     32 bits     |
   +----------+--------------+---------------------+-----------------+
   |1111111010|              0                     | Interface Token |
   +----------+--------------+---------------------+-----------------+

   The most significant 10 bits of the address is the Link-Local prefix
   FE80::.  86 zero bits pad out the address between the Link-Local
   prefix and the Interface Token fields.

A.  IPV6CP Recommended Options

   The following Configurations Options are recommended:

      Interface-Token

      IPv6-Compression-Protocol

















Haskin & Allen              Standards Track                     [Page 9]

RFC 2023                 IP Version 6 over PPP              October 1996


Security Considerations

   Security issues are not discussed in this memo.

References


   [1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661,
       July 1994.

   [2] Deering, S., and R. Hinden, Editors, "Internet Protocol,
       Version 6 (IPv6) Specification", RFC 1883, December 1995.

   [2] Hinden, R., and  S. Deering, "IP Version 6 Addressing
       Architecture", RFC 1884, December 1995.

   [3] Thomson, S., and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 1971, August 1996.

   [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
       for IP Version 6 (IPv6)", RFC 1970, August 1996.

   [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
       1700, October 1994.

Acknowledgments

   This document borrows from the Magic-Number LCP option and as such is
   partially based on previous work done by the PPP working group.

Authors' Addresses

   Dimitry Haskin
   Bay Networks, Inc.
   2 Federal Street
   Billerica, MA 01821
   email: [e-mail]

   Ed Allen
   Bay Networks, Inc.
   2 Federal Street
   Billerica, MA 01821
   email: [e-mail]








Haskin & Allen              Standards Track                    [Page 10]