rfc2472.txt

RFC 的详细文档！


RFC 2472                 IP Version 6 over PPP             December 1998


     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-Identifier
     option if a valid Interface-Identifier Configure-Reject is
     received.

     Reception of a Configure-Nak with a suggested Interface-Identifier
     different from that of the last Configure-Nak sent to the peer
     indicates a unique Interface-Identifier.  In this case a new
     Configure-Request MUST be sent with the identifier value suggested
     in the last Configure-Nak from the peer.  But if the received
     Interface-Identifier is equal to the one sent in the last
     Configure-Nak, a new Interface-Identifier MUST be chosen.  In this
     case, a new Configure-Request SHOULD be sent with the new tentative
     Interface-Identifier.  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-
     Identifiers chosen at either end will quickly diverge, terminating
     the sequence.

     If negotiation of the Interface-Identifier 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-Identifier given must be acceptable as the remote
     Interface-Identifier; i.e.  it should be different from the
     identifier 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-Identifier for its end of the PPP connection.

   A summary of the Interface-Identifier Configuration Option format is
   shown below.  The fields are transmitted from left to right.











Haskin & Allen              Standards Track                     [Page 8]

RFC 2472                 IP Version 6 over PPP             December 1998


   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-Identifier (MS Bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Interface-Identifier (cont)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Interface-Identifier (LS Bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type

       1

     Length

       10

     Interface-Identifier

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

     Default

       If no valid interface identifier can be successfully negotiated, no
       default Interface-Identifier value should be assumed. The procedures
       for recovering from such a case are unspecified.  One approach is to
       manually configure the interface identifier 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.

   A summary of the IPv6-Compression-Protocol Configuration Option format
   is shown below.  The fields are transmitted from left to right.



Haskin & Allen              Standards Track                     [Page 9]

RFC 2472                 IP Version 6 over PPP             December 1998


   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.

       No IPv6-Compression-Protocol field values are currently assigned.
       Specific assignments will be made in documents that define
       specific compression algorithms.

     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.

5.  Stateless Autoconfiguration and Link-Local Addresses

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

   As long as the Interface Identifier 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



Haskin & Allen              Standards Track                    [Page 10]

RFC 2472                 IP Version 6 over PPP             December 1998


   protocol [3].  Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Identifier 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  |        54 bits         |          64 bits            |
   +----------+------------------------+-----------------------------+
   |1111111010|           0            |    Interface Identifier     |
   +----------+------------------------+-----------------------------+

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

6.  Security Considerations

   The IPv6 Control Protocol extension to PPP can be used with all
   defined PPP authentication and encryption mechanisms.

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

8.  Changes from RFC-2023

   The following changes were made from RFC-2023 "IP Version 6 over
   PPP":

   - Changed to use "Interface Identifier" instead of the "Interface
     Token" term according to the terminology adopted in [6].

   - Increased the size of Interface Identifier to 64 bits according to
     the newly adopted IPv6 addressing architecture [6].

   - Added methods for selection of an interface identifier that is
     consistently reproducible across initializations of the IPV6CP
     finite state machine.

   - Added the interface identifier selection methods for generating
     globally unique interface identifier from an unique an IEEE global
     identifier when it is available anywhere on the node.

   - Changed to send a Configure-Nak instead a Configure-Ack in response
     to receiving a Configure-Request with a zero Interface-Identifier
     value.




Haskin & Allen              Standards Track                    [Page 11]

RFC 2472                 IP Version 6 over PPP             December 1998


   - Replaced the value assignment of the IPv6-Compression-Protocol
     field of the IPv6-Compression-Protocol Configuration option with
     the text stating that no IPv6-Compression-Protocol field values are
     currently assigned and that specific assignments will be made in
     documents that define specific compression algorithms.

   - Added new and updated references.

   - Minor text clarifications and improvements.

9.  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 2460, December 1998.

   [3]  Thomson, S., and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

   [4]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
        1700, October 1994.  See also: http://www.iana.org/numbers.html

   [5]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
        Registration Authority",
        http://standards.ieee.org/db/oui/tutorials/EUI64.html, March
        1997.

   [6]  Hinden, R., and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

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

   [8]  Narten T., and C. Burton, "A Caution On The Canonical Ordering
        Of Link-Layer Addresses", RFC 2469, December 1998.














Haskin & Allen              Standards Track                    [Page 12]

RFC 2472                 IP Version 6 over PPP             December 1998


10.  Authors' Addresses

   Dimitry Haskin
   Bay Networks, Inc.
   600 Technology Park
   Billerica, MA 01821

   EMail: [e-mail]


   Ed Allen
   Bay Networks, Inc.
   600 Technology Park
   Billerica, MA 01821

   EMail: [e-mail]



































Haskin & Allen              Standards Track                    [Page 13]

RFC 2472                 IP Version 6 over PPP             December 1998


11.  Full Copyright Statement

   Copyright (C) The Internet Society (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
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Haskin & Allen              Standards Track                    [Page 14]