doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2023.txt b/doc/rfc/rfc2023.txt
new file mode 100644
index 0000000..3f6cbea
--- /dev/null
+++ b/doc/rfc/rfc2023.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         D. Haskin
+Request for Comments: 2023                                     E. Allen
+Category: Standards Track                            Bay Networks, Inc.
+                                                           October 1996
+
+                         IP Version 6 over 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) [1] provides a standard method of
+   encapsulating Network Layer protocol information over point-to-point
+   links.  PPP also defines an extensible Link Control Protocol, and
+   proposes a family of Network Control Protocols (NCPs) for
+   establishing and configuring different network-layer protocols.
+
+   This document defines the method for transmission of IP Version 6 [2]
+   packets over PPP links as well as the Network Control Protocol (NCP)
+   for establishing and configuring the IPv6 over PPP. It also specifies
+   the method of forming IPv6 link-local addresses on PPP links.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+        1.1.  Specification of Requirements ......................   2
+   2.     Sending IPv6 Datagrams ................................    3
+   3.     A PPP Network Control Protocol for IPv6 ...............    3
+   4.     IPV6CP Configuration Options ..........................    4
+        4.1.  Interface-Token ...................................    4
+        4.2.  IPv6-Compression-Protocol..........................    7
+   5.     Stateless Autoconfiguration and Link-Local Addresses ..    9
+   A.     IPV6CP Recommended Options .............................   9
+   Security Considerations .......................................  10
+   References ....................................................  10
+   Acknowledgments ...............................................  10
+   Authors' Addresses ............................................  10
+
+
+
+
+
+
+
+
+Haskin & Allen              Standards Track                     [Page 1]
+
+RFC 2023                 IP Version 6 over PPP              October 1996
+
+
+1.  Introduction
+
+   PPP has three main components:
+
+      1. A method for encapsulating datagrams over serial links.
+
+      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.
+
+   In order to establish communications over a point-to-point link, each
+   end of the PPP link must first send LCP packets to configure and test
+   the data link.  After the link has been established and optional
+   facilities have been negotiated as needed by the LCP, PPP must send
+   NCP packets to choose and configure one or more network-layer
+   protocols.  Once each of the chosen network-layer protocols has been
+   configured,  datagrams from each network-layer protocol can be sent
+   over the link.
+
+   In this document, the NCP for establishing and configuring the IPv6
+   over PPP is referred as the IPv6 Control Protocol (IPV6CP).
+
+   The link will remain configured for communications until explicit LCP
+   or NCP packets close the link down,  or until some external event
+   occurs (power failure at the other end, carrier drop, etc.).
+
+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
+
+
+
+Haskin & Allen              Standards Track                     [Page 2]
+
+RFC 2023                 IP Version 6 over PPP              October 1996
+
+
+             prepared to inter-operate with another implementation which
+             does include the option.
+
+2. Sending IPv6 Datagrams
+
+   Before any IPv6 packets may be communicated, PPP must reach the
+   Network-Layer Protocol phase, and the IPv6 Control Protocol must
+   reach the Opened state.
+
+   Exactly one IPv6 packet is encapsulated in the Information field of
+   PPP Data Link Layer frames where the Protocol field indicates type
+   hex 0057 (Internet Protocol Version 6).
+
+   The maximum length of an IPv6 packet transmitted over a PPP link is
+   the same as the maximum length of the Information field of a PPP data
+   link layer frame.  PPP links supporting IPv6 must allow at least 576
+   octets in the information field of a data link layer frame.
+
+3. A PPP Network Control Protocol for IPv6
+
+   The IPv6 Control Protocol (IPV6CP) is responsible for configuring,
+   enabling, and disabling the IPv6 protocol modules on both ends of the
+   point-to-point link.  IPV6CP uses the same packet exchange mechanism
+   as the Link Control Protocol (LCP).  IPV6CP packets may not be
+   exchanged until PPP has reached the Network-Layer Protocol phase.
+   IPV6CP packets received before this phase is reached should be
+   silently discarded.
+
+   The IPv6 Control Protocol is exactly the same as the Link Control
+   Protocol [1] with the following exceptions:
+
+   Data Link Layer Protocol Field
+
+     Exactly one IPV6CP packet is encapsulated in the Information field
+     of PPP Data Link Layer frames where the Protocol field indicates
+     type hex 8057 (IPv6 Control Protocol).
+
+   Code field
+
+     Only Codes 1 through 7 (Configure-Request, Configure-Ack,
+     Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
+     and Code-Reject) are used.  Other Codes should be treated as
+     unrecognized and should result in Code-Rejects.
+
+
+
+
+
+
+
+
+Haskin & Allen              Standards Track                     [Page 3]
+
+RFC 2023                 IP Version 6 over PPP              October 1996
+
+
+   Timeouts
+
+   IPV6CP packets may not be exchanged until PPP has reached the
+   Network-Layer Protocol phase.  An implementation should be prepared
+   to wait for Authentication and Link Quality Determination to finish
+   before timing out waiting for a Configure-Ack or other response.  It
+   is suggested that an implementation give up only after user
+   intervention or a configurable amount of time.
+
+   Configuration Option Types
+
+     IPV6CP has a distinct set of Configuration Options, which are
+     defined below.
+
+4.  IPV6CP Configuration Options
+
+   IPV6CP Configuration Options allow negotiation of desirable IPv6
+   parameters.  IPV6CP uses the same Configuration Option format defined
+   for LCP [1], with a separate set of Options.  If a Configuration
+   Option is not included in a Configure-Request packet,  the default
+   value for that Configuration Option is assumed.
+
+   Up-to-date values of the IPV6CP Option Type field are specified in
+   the most recent "Assigned Numbers" RFC [5].  Current values are
+   assigned as follows:
+
+    1       Interface-Token
+    2       IPv6-Compression-Protocol
+
+
+4.1.  Interface-Token
+
+   Description
+
+      This Configuration Option provides a way to negotiate a unique
+      32-bit interface token to be used for the address
+      autoconfiguration [3] at the local end of the link (see section
+      5).  The interface token MUST be unique within the PPP link; i.e.
+      upon completion of the negotiation different Interface-Token
+      values are to be selected for the ends of the PPP link.
+
+      Before this Configuration Option is requested, an implementation
+      must choose its tentative Interface-Token.  It is recommended that
+      a non-zero value be chosen in the most random manner possible in
+      order to guarantee with very high probability that an
+      implementation will arrive at a unique token value.  A good way to
+      choose a unique random number is to start with a unique seed.
+      Suggested sources of uniqueness include machine serial numbers,
+
+
+
+Haskin & Allen              Standards Track                     [Page 4]
+
+RFC 2023                 IP Version 6 over PPP              October 1996
+
+
+      other network hardware addresses, system clocks, etc. Note that it
+      may not be sufficient to use a link-layer address alone as the
+      seed, since it will not always be unique.  Thus it is suggested
+      that the seed should be calculated from a variety of sources that
+      are likely to be different even on identical systems and as many
+      sources as possible be used simultaneously.  Good sources of
+      uniqueness or randomness are required for the Interface-Token
+      negotiation to succeed.  If a good source of randomness cannot be
+      found,  it is recommended that a zero value be used for the
+      Interface-Token transmitted in the Configure-Request.  In this
+      case the PPP peer may provide a valid non-zero Interface-Token in
+      its response as described below.  Note that if at least one of the
+      PPP peers is able to generate a unique random number, the token
+      negotiation will succeed.
+
+      When a Configure-Request is received with the Interface-Token
+      Configuration Option and the receiving peer implements this
+      option, the received Interface-Token is compared with the
+      Interface-Token of the last Configure-Request sent to the peer.
+      Depending on the result of the comparison an implementation MUST
+      respond in one of the following ways:
+
+      If the two Interface-Tokens are different but the received
+      Interface-Token is zero, a Configure-Ack is sent with a non-zero
+      Interface-Token value suggested for use by the remote peer.  Such
+      a suggested Interface-Token MUST be different from the Interface-
+      Token of the last Configure-Request sent to the peer.
+
+      If the two Interface-Tokens are different and the received
+      Interface-Token is not zero, the Interface-Token MUST be
+      acknowledged, i.e. a Configure-Ack is sent with the requested
+      Interface-Token, meaning that the responding peer agrees with the
+      Interface-Token requested.
+
+      If the two Interface-Tokens are equal and are not zero, a
+      Configure-Nak MUST be sent specifying a different non-zero
+      Interface-Token value suggested for use by the remote peer.
+
+      If the two Interface-Tokens are equal to zero,  the Interface-
+      Tokens negotiation MUST be terminated by transmitting the
+      Configure-Reject with the Interface-Token value set to zero. In
+      this case a unique Interface-Token can not be negotiated.
+
+      If a Configure-Request is received with the Interface-Token
+      Configuration Option and the receiving peer does not implement
+      this option, Configure-Rej is sent.
+
+
+
+
+
+Haskin & Allen              Standards Track                     [Page 5]
+
+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: dhaskin@baynetworks.com
+
+   Ed Allen
+   Bay Networks, Inc.
+   2 Federal Street
+   Billerica, MA 01821
+   email: eallen@baynetworks.com
+
+
+
+
+
+
+
+
+Haskin & Allen              Standards Track                    [Page 10]
+