doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1763.txt b/doc/rfc/rfc1763.txt
new file mode 100644
index 0000000..02434c2
--- /dev/null
+++ b/doc/rfc/rfc1763.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                           S. Senum
+Request for Comments: 1763                                     DigiBoard
+Category: Standards Track                                     March 1995
+
+
+              The PPP Banyan Vines Control Protocol (BVCP)
+
+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 for
+   transporting multi-protocol datagrams over point-to-point links.  PPP
+   defines an extensible Link Control Protocol, and proposes a family of
+   Network Control Protocols for establishing and configuring different
+   network-layer protocols.
+
+   This document defines the Network Control Protocol for establishing
+   and configuring the Banyan VINES protocol over PPP.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+      1.1       Specification of Requirements ...................    2
+      1.2       Terminology .....................................    3
+   2.     A PPP Network Control Protocol for VINES ..............    3
+      2.1       Sending VINES Datagrams .........................    4
+      2.2       General Considerations ..........................    4
+   3.     BVCP Configuration Options ............................    5
+      3.1       BV-NS-RTP-Link-Type .............................    5
+      3.2       BV-FRP ..........................................    6
+      3.3       BV-RTP ..........................................    7
+      3.4       BV-Suppress-Broadcast ...........................    8
+   SECURITY CONSIDERATIONS ......................................    9
+   REFERENCES ...................................................    9
+      ACKNOWLEDGEMENTS ..........................................    9
+   CHAIR'S ADDRESS ..............................................   10
+   AUTHOR'S ADDRESS .............................................   10
+
+
+
+
+
+
+
+Senum                                                           [Page 1]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+1.  Introduction
+
+   PPP has 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 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
+   BVCP packets to choose and configure the VINES network-layer
+   protocol.  Once BVCP has reached the Opened state, VINES datagrams
+   can be sent over the link.
+
+   The link will remain configured for communications until explicit LCP
+   or BVCP packets close the link down, or until some external event
+   occurs (an inactivity timer expires or network administrator
+   intervention).
+
+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.
+
+
+
+
+Senum                                                           [Page 2]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+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.  A PPP Network Control Protocol for VINES
+
+   The Banyan VINES Control Protocol (BVCP) is responsible for
+   configuring, enabling, and disabling the VINES protocol modules on
+   both ends of the point-to-point link.  BVCP uses the same packet
+   exchange mechanism as the Link Control Protocol.  BVCP packets may
+   not be exchanged until PPP has reached the Network-Layer Protocol
+   phase.  BVCP packets received before this phase is reached should be
+   silently discarded.
+
+   The Baynan VINES Control Protocol is exactly the same as the Link
+   Control Protocol [1] with the following exceptions:
+
+   Frame Modifications
+
+      The packet may utilize any modifications to the basic frame format
+      which have been negotiated during the Link Establishment phase.
+
+
+
+
+
+
+Senum                                                           [Page 3]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+   Data Link Layer Protocol Field
+
+      Exactly one BVCP packet is encapsulated in the Information field
+      of a PPP Data Link Layer frame where the Protocol field indicates
+      type hex 8035 (Banyan VINES 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.
+
+   Timeouts
+
+      BVCP 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
+
+      BVCP has a distinct set of Configuration Options.
+
+2.1.  Sending VINES Datagrams
+
+   Before any VINES datagrams may be communicated, PPP must reach the
+   Network-Layer Protocol phase, and the Banyan VINES Control Protocol
+   must reach the Opened state.
+
+   Exactly one VINES packet is encapsulated in the Information field of
+   a PPP Data Link Layer frame where the Protocol field indicates type
+   hex 0035 (Banyan VINES datagram).  The maximum length of a VINES
+   datagram transmitted over a PPP link is the same as the maximum
+   length of the Information field of a PPP data link layer frame.
+
+   The format of the Information field itself is the same as that
+   defined in [2].
+
+2.2.  General Considerations
+
+   VINES supports an Address Resolution Protocol, VINES ARP, primarily
+   used for address assignment.  Since this protocol is part of VINES
+   IP, it is fully supported over BVCP.  VINES also supports a data-link
+   Echo Protocol (VINES Echo), used to test connectivity to a VINES
+   Server in a LAN environment, which is not supported over BVCP.
+
+
+
+Senum                                                           [Page 4]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+3.  BVCP Configuration Options
+
+   BVCP Configuration Options allow modifications to the standard
+   characteristics of the network-layer protocol to be negotiated.  If a
+   Configuration Option is not included in a Configure-Request packet,
+   the default value for that Configuration Option is assumed.
+
+   BVCP uses the same Configuration Option format defined for LCP [1],
+   with a separate set of Options.
+
+   Up-to-date values of the BVCP Option Type field are specified in the
+   most recent "Assigned Numbers" RFC [3].  Current values are assigned
+   as follows:
+
+      Value   Option
+
+        1     BV-NS-RTP-Link-Type
+        2     BV-FRP
+        3     BV-RTP
+        4     BV-Suppress-Broadcast
+
+   Note: A suggestion was made to combine the BV-NS-RTP-Link-Type option
+   and the BV-RTP option into a single option that could negotiate one
+   of four settings (S-RTP, NS-RTP-LAN, NS-RTP-WAN, NO-RTP).  This
+   suggestion has been rejected because VINES must already deal with a
+   mix of S-RTP and NS-RTP, and that pushing this information down to
+   the PPP layer is not desirable.
+
+3.1.  BV-NS-RTP-Link-Type
+
+   Description
+
+      This Configuration Option provides a way to negotiate the way the
+      Non-Sequenced Routing Update Protocol (NS-RTP) (pre-VINES 5.5,
+      i.e., 4.11 and 5.0) will run on the link.  NS-RTP handles updates
+      differently depending on whether the interface is a LAN type or a
+      WAN type.  For a LAN type, the full routing table is rebroadcast
+      every update interval (90 seconds).  For a WAN type, the full
+      routing table is only transmitted for the first 3 update intervals
+      after the link comes up.  After that only changes are transmitted
+      (for 5 update intervals).  Note that this has no effect if
+      Sequenced RTP (VINES 5.5) is being used.  More information on this
+      can be found in [2].
+
+      This option negotiates what an implementation is willing to
+      receive, and is negotiated separately per side of the PPP
+      connection.  The acceptance of this option (by the peer) indicates
+      that the peer will send NS-RTP updates as if the link was a LAN
+
+
+
+Senum                                                           [Page 5]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+      type.  The rejection (or absence) of this option indicates that
+      the peer will send NS-RTP updates as if the link was a WAN type.
+
+      By default, NS-RTP updates are sent as if the link was a WAN type.
+
+   A summary of the BV-NS-RTP-Link-Type Configuration Option format is
+   shown below.  The fields are transmitted from left to right.
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+      Type
+
+         1
+
+      Length
+
+         2
+
+3.2.  BV-FRP
+
+   Description
+
+      This Configuration Option provides a way to negotiate the use of
+      VINES Fragmentation Protocol (FRP).  This protocol is used to
+      allow fragmentation and reassembly of a VINES packet over the
+      link.  FRP prepends a two octet field to every packet going over
+      the link that contains a begin and end fragment information and a
+      sequence number.  With PPP's default MRU of 1500, FRP is not
+      normally needed, and no FRP header would be sent with the VINES
+      packet.  If a MRU of less than 1484 is negotiated, FRP will be
+      needed to send a full size VINES packet over the link.  More
+      information on this can be found in [2].
+
+      This option negotiates what an implementation is willing to
+      receive, and is negotiated separately per side of the PPP
+      connection.  The acceptance of this option (by the peer) indicates
+      that the peer will send VINES packets with a FRP header.  The
+      rejection (or absence) of this option indicates that the peer will
+      send VINES packets without a FRP header.
+
+      By default, VINES packets are sent without a FRP header.
+
+
+
+
+
+Senum                                                           [Page 6]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+   A summary of the BV-FRP Configuration Option format is shown below.
+   The fields are transmitted from left to right.
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+      Type
+
+         2
+
+      Length
+
+         2
+
+3.3.  BV-RTP
+
+   Description
+
+      This Configuration Option provides a way to negotiate whether RTP
+      is used over the link.  If dial-up lines with static routes are
+      being used, the use of RTP may be totally suppressed to conserve
+      bandwidth on the link.
+
+      This option negotiates what an implementation is willing to
+      receive, and is negotiated separately per side of the PPP
+      connection.  The acceptance of this option (by the peer) indicates
+      that the peer will not send RTP packets.  The rejection (or
+      absence) of this option indicates that the peer will send any RTP
+      packets.
+
+      By default, RTP packets are sent over the link.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senum                                                           [Page 7]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+   A summary of the BV-RTP Configuration Option format is shown below.
+   The fields are transmitted from left to right.
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+      Type
+
+         3
+
+      Length
+
+         2
+
+3.4.  BV-Suppress-Broadcast
+
+   Description
+
+      This Configuration Option provides a way to negotiate the sending
+      of VINES broadcast packets, i.e., packets with a destination VINES
+      network address of all ones.  This option only affects VINES
+      packets that are not of type VINES ARP or VINES RTP.  This option
+      can be used by a VINES Client to request that most of the
+      broadcast packets that would normally be sent to it by a VINES
+      Server be discarded, in order to conserve link bandwidth.  Most of
+      the broadcast packets sent by a VINES Server are not useful to a
+      VINES Client.
+
+      This option negotiates what an implementation is willing to
+      receive, and is negotiated separately per side of the PPP
+      connection.  The acceptance of this option (by the peer) indicates
+      that the peer MUST NOT send any VINES broadcast packets, other
+      than packets of type VINES ARP or VINES RTP.  The rejection (or
+      absence) of this option indicates that the peer will send all
+      VINES broadcast packets.
+
+      By default, all VINES broadcast packets are sent.
+
+
+
+
+
+
+
+
+
+
+Senum                                                           [Page 8]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+   A summary of the BV-Suppress-Broadcast Configuration Option format is
+   shown below.  The fields are transmitted from left to right.
+
+       0                   1
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+      Type
+
+         4
+
+      Length
+
+         2
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+       1661, Daydreamer, July 1994.
+
+   [2] Banyan, "VINES Protocol Definition", June 1993, Order No.
+       003673.
+
+   [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+       USC/Information Sciences Institute, October 1994.
+
+Acknowledgements
+
+   Some of the text in this document is taken from previous documents
+   produced by the Point-to-Point Protocol Working Group of the Internet
+   Engineering Task Force (IETF).
+
+   In particular, Bill Simpson provided the boiler-plate used to create
+   this document.
+
+
+
+
+
+
+
+
+
+
+Senum                                                           [Page 9]
+
+RFC 1763                        PPP BVCP                      March 1995
+
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Fred Baker
+   Cisco Systems
+   519 Lado Drive
+   Santa Barbara, California 93111
+
+   Phone: (805) 681-0115
+   EMail: fred@cisco.com
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Steven J. Senum
+   DigiBoard
+   6400 Flying Cloud Drive
+   Eden Prairie, Minnesota 55344
+
+   Phone: (612) 943-9020
+   EMail: sjs@digibd.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senum                                                          [Page 10]
+