doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc1378.txt b/doc/rfc/rfc1378.txt
new file mode 100644
index 0000000..6780ecc
--- /dev/null
+++ b/doc/rfc/rfc1378.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          B. Parker
+Request for Comments: 1378                                Cayman Systems
+                                                           November 1992
+
+
+               The PPP AppleTalk Control Protocol (ATCP)
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" 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 NCP for establishing and configuring the
+   AppleTalk Protocol [3] over PPP.
+
+   This memo is a joint effort of the AppleTalk-IP Working Group and the
+   Point-to-Point Protocol Working Group of the Internet Engineering
+   Task Force (IETF).  Comments on this memo should be submitted to the
+   ietf-ppp@ucdavis.edu mailing list.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+   2.     A PPP Network Control Protocol (NCP) for AppleTalk ....    2
+   2.1    Sending AppleTalk Datagrams ...........................    3
+   2.2    Half-Routers ..........................................    4
+   3.     ATCP Configuration Options ............................    4
+   3.1    AppleTalk-Address .....................................    5
+   3.2    Routing-Protocol ......................................    7
+   3.3    Suppress-Broadcasts ...................................    8
+   3.4    AT-Compression-Protocol ...............................    9
+   3.5    Server-information ....................................   10
+   3.6    Zone-Information ......................................   12
+   3.7    Default-Router-Address ................................   13
+   APPENDICES ...................................................   14
+   A.     ATCP Recommended Options ..............................   14
+   REFERENCES ...................................................   15
+
+
+
+Parker                                                          [Page 1]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   ACKNOWLEDGEMENTS .............................................   15
+   SECURITY CONSIDERATIONS ......................................   16
+   CHAIR'S ADDRESS ..............................................   16
+   AUTHOR'S ADDRESS .............................................   16
+
+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.
+
+   The link will remain configured for communications until explicit LCP
+   or NCP packets close the link down, or until some external event
+   occurs (an inactivity timer expires or network administrator
+   intervention).
+
+2.  A PPP Network Control Protocol (NCP) for AppleTalk
+
+   The AppleTalk Control Protocol (ATCP) is responsible for configuring,
+   enabling, and disabling the AppleTalk protocol modules on both ends
+   of the point-to-point link.  ATCP uses the same packet exchange
+   machanism as the Link Control Protocol (LCP).  ATCP packets may not
+   be exchanged until PPP has reached the Network-Layer Protocol phase.
+   ATCP packets received before this phase is reached should be silently
+   discarded.
+
+   The AppleTalk 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.
+
+
+
+Parker                                                          [Page 2]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   Data Link Layer Protocol Field
+
+      Exactly one ATCP packet is encapsulated in the Information field
+      of a PPP Data Link Layer frame where the Protocol field indicates
+      type hex 8029 (AppleTalk 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
+
+      ATCP 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
+
+      ATCP has a distinct set of Configuration Options, which are
+      defined below.
+
+2.1.  Sending AppleTalk Datagrams
+
+   Before any AppleTalk packets may be communicated, PPP must reach the
+   Network-Layer Protocol phase, and the AppleTalk Control Protocol must
+   reach the Opened state.
+
+   Unless otherwise negotiated (via option 4), exactly one AppleTalk
+   packet is encapsulated in the Information field of a PPP Data Link
+   Layer frame where the Protocol field indicates type hex 0029
+   (AppleTalk).
+
+   Note that the negotiation of compression may imply the use of
+   different encapsulation and hence different protocol fields.  These
+   different protocol fields imply packet types which are sub-protocols
+   of the base AppleTalk NCP.
+
+   An encapsulated AppleTalk packet begins with an extended DDP
+   (Datagram Delivery Protocol) header -- also known as a Long DDP
+   header.  The maximum length of a DDP datagram is 599 octets.
+
+   Since there is no standard method for fragmenting and reassembling
+
+
+
+Parker                                                          [Page 3]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   AppleTalk datagrams, it is required that PPP links supporting
+   AppleTalk allow at least 599 octets in the information field of a
+   data link layer frame.
+
+2.2.  Half-Routers
+
+   One model for routers in [3] is two remote AppleTalk routers linked
+   as "half-routers" without a Node ID or Network number assigned to
+   either side of the link.  When acting as half-routers, the only
+   effect on transported packets is that the hop count is incremented
+   when it is received over the link.  Routing updates received over a
+   half-router link should also increment the hop count of routing table
+   updates.
+
+   As part of normal operation, AppleTalk will send RTMP Routing updates
+   every 10 seconds.
+
+3.  ATCP Configuration Options
+
+   ATCP Configuration Options allow negotiation of desirable AppleTalk
+   parameters.  ATCP uses the same Configuration Option format defined
+   for LCP [1], with a separate set of Options.
+
+   The most up-to-date values of the ATCP Option Type field are
+   specified in the most recent "Assigned Numbers" RFC [2].  Current
+   values are assigned as follows:
+
+   1       AppleTalk-Address
+
+   2       Routing-Protocol
+
+   3       Suppress-Broadcasts
+
+   4       AT-Compression-Protocol
+
+   5       RESERVED
+
+   6       Server-information
+
+   7       Zone-information
+
+   8       Default-Router-Address
+
+
+
+
+
+
+
+
+
+Parker                                                          [Page 4]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+3.1.  AppleTalk-Address
+
+   Description
+
+      This Configuration Option provides a way to negotiate the
+      AppleTalk network and node number to be used on the local end of
+      the link.  It allows the sender of the Configure-Request to state
+      which AppleTalk-address is desired, or to request that the peer
+      provide the information.  The peer can provide this information by
+      NAKing the option, and returning a valid AppleTalk-address.
+
+      If negotiation about the remote AppleTalk-address is required, and
+      the peer did not provide the option in its Configure-Request, the
+      option SHOULD be appended to a Configure-Nak.  The value of the
+      AppleTalk-address given must be acceptable as the remote
+      AppleTalk-address, or indicate a request that the peer provide the
+      information.
+
+      By default, no AppleTalk address is assigned.  A network or node
+      number specified as zero in a Configure-Request shall be
+      interpreted as requesting the remote end to specify a value via a
+      Configure-Nak.  A network or node number specified as zero in a
+      Configure-Ack shall be interpreted as agreement that no value
+      exists.
+
+      An implementation which requires that no AppleTalk addresses be
+      assigned (such as a intermediate system to intermediate system
+      "half-routing") MUST Configure-Reject all AppleTalk-Address
+      Configuration Options.
+
+      An implementation which requires that AppleTalk addresses be
+      assigned to it (such as a end system) MUST fail configuration if
+      the remote side Configure-Rejects all AppleTalk-Address requests,
+      or fails to provide a valid value.
+
+      If this option is negotiated, the two sides MUST negotiate a
+      common AppleTalk network number and two unique Appletalk node
+      numbers.  The network number MAY be zero but the Appletalk node
+      numbers MUST be non-zero.  Values selected for network and node
+      numbers must adhere to the ranges defined in [3].
+
+      The AppleTalk protocol, phase 2, defines the concept of "extended"
+      and "non-extended" networks.  Extended networks can support a
+      large number (hundreds) of nodes, and requires multiple network
+      numbers and multiple zone names to be managed effectively.  Non-
+      extended networks can only support a small number of devices, and
+      require only a single network number and zone name to be managed
+      effectively.
+
+
+
+Parker                                                          [Page 5]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+      If a PPP link transporting AppleTalk is assigned an AppleTalk
+      address, it must have the "non-extended" characteristics as
+      defined in [3].
+
+      The format of the network and node data is defined to be the same
+      as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP
+      packet formats on Ethernet and token ring".
+
+   A summary of the AppleTalk-Address 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     |    Reserved   |     AT-Net    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     AT-Net    |    AT-Node    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      1
+
+   Length
+
+      6
+
+   Reserved
+
+      This octet is reserved and MUST be set to zero on transmission and
+      ignored on reception.
+
+   AT-Net
+
+      The two octet AT-Net is the desired local AppleTalk network number
+      of the sender of the Configure-Request.  This two octet quantity
+      represents a 16 bit unsigned number sent "network byte order"
+      (most significant octet first).
+
+   AT-Node
+
+      The one octet AT-Node is the desired local AppleTalk node ID of
+      the sender of the Configure-Request.
+
+
+
+
+
+
+
+Parker                                                          [Page 6]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+3.2.  Routing-Protocol
+
+   Description
+
+      This Configuration Option provides a way to negotiate the use of a
+      specific routing protocol.  In particular, "half-routers" may want
+      to exchange routing information using a protocol optimized for the
+      PPP connection.  By default, AppleTalk RTMP (Routing Table
+      Maintenance Protocol) routing information is sent over the PPP
+      connection.
+
+      By default, AppleTalk RTMP routing information is sent over the
+      PPP connection.
+
+   A summary of the Routing-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     |       Routing-Protocol        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Data ...
+   +-+-+-+-+
+
+
+   Type
+
+      2
+
+   Length
+
+      >= 4
+
+   Routing-Protocol
+
+      The Routing-Protocol field is two octets and indicates the type of
+      Routing-Protocol desired.  This two octet quantity represents a 16
+      bit number sent "network byte order" (most significant octet
+      first).
+
+      Negotiation of some routing protocols implies that you will
+      receive packet types which transport these protocols.
+
+      For example, negotiating AppleTalk AURP to exchange routing
+      information implies both sides will accept EDDP type packets,
+      since this is the transport type used by AURP.
+
+
+
+
+Parker                                                          [Page 7]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+      Initial values are assigned as follows:
+
+      Value       Protocol
+
+        0         No routing information exchange
+        1         AppleTalk RTMP is used to exchange routing information
+        2         AppleTalk AURP is used to exchange routing information
+        3         AppleTalk ABGP is used to exchange routing information
+
+
+   Data
+
+      The Data field is zero or more octets and contains additional data
+      as determined by the routing protocol indicated in the Routing-
+      Protocol field.
+
+      None of the Routing-Protocol options defined here require
+      additional data.
+
+3.3.  Suppress-Broadcasts
+
+   Description
+
+      This Configuration Option provides a way to negotiate the
+      suppression of AppleTalk broadcast datagrams which might otherwise
+      use up limitted PPP bandwidth.  This Configuration Option is used
+      to inform the remote end that no AppleTalk broadcast datagrams of
+      a given DDP type should be sent.
+
+      This option is useful when negotiated by a single end system.  It
+      allows the local end system to request that broadcast packets
+      generated on a remote network not be propagated across the PPP
+      link.  In the case of a single end system connected to a large
+      network, this can be used to suppress regular NBP lookups
+      generated by other end systems on the remote network.  This will
+      mean that protocols such as NBP can no longer be used to find
+      network entities on the local system, but since the option
+      configuration is asymmetric, it does not inhibit the local
+      system's ability to find network entities on the remote network.
+
+      By default, no AppleTalk broadcast datagrams are suppressed.  Note
+      that this option may conflict with other options (such as Routing
+      Protocol).  If so, the Suppress-Broadcasts option takes
+      precedence.
+
+   A summary of the Suppress-Broadcasts Configuration Option format is
+   shown below.  The fields are transmitted from left to right.
+
+
+
+
+Parker                                                          [Page 8]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+    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     |  DDP-Type  1  |  DDP-Type  2  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | etc...
+   +-+-+-+-+
+
+
+   Type
+
+      3
+
+   Length
+
+      >= 2
+
+   DDP-Types
+
+      A vector of one or more single octet DDP type values, each of
+      which are to be suppressed if sent to the broadcast address.
+
+      If no data is present (the length = 2), all broadcast packets are
+      to be suppressed, regardless of DDP type.
+
+3.4.  AT-Compression-Protocol
+
+   Description
+
+      This Configuration Option provides a way to negotiate the use of a
+      specific compression protocol.  By default, compression is not
+      enabled.
+
+   A summary of the AT-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     |   AT-Compression-Protocol     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Data ...
+   +-+-+-+-+
+
+
+   Type
+
+      4
+
+
+
+Parker                                                          [Page 9]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   Length
+
+      >= 4
+
+   AT-Compression-Protocol
+
+      The AT-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.
+
+      The most up-to-date values of the AT-Compression-Protocol field
+      are specified in the most recent "Assigned Numbers" RFC [2].
+      Current values are assigned as follows:
+
+
+         Value (in hex)          Protocol
+
+                                 none defined
+
+
+   Data
+
+      The Data field is zero or more octets and contains additional data
+      as determined by the particular compression protocol.
+
+3.5.  Server-information
+
+   Description
+
+      This Configuration Option provides a way to obtain information
+      about the communications server providing the remote side of the
+      PPP connection.
+
+      The nature of this option is advisory only.  It is provided as a
+      means of improving an end system's ability to provide a simple
+      user interface.
+
+   A summary of the Server-Information Option format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+Parker                                                         [Page 10]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+    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     |          Server-class         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   Server-implementation-id                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Server-name ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      6
+
+   Length
+
+      >= 8
+
+   Server-class
+
+      The Server-class field is two octets and indicates the class of
+      the communication server providing the remote end of the PPP
+      connection.
+
+      Initial values are assigned as follows:
+
+      Value        Class
+
+        1          AppleTalk PPP Dial-in server.
+
+                   The server-implementation-id is a four byte version
+                   id, with the first byte defined as the major
+                   version number (1-255) and the second byte defined
+                   as the minor version number (1-255).
+
+                   The third and fourth bytes are undefined and should
+                   be zero.
+
+        2          Generic AppleTalk PPP implementation.
+
+                   The server-implementation-id is undefined and
+                   vendor specific.
+
+        3          Both dial-in server and router
+
+
+
+
+
+
+Parker                                                         [Page 11]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   Server-implementation-id
+
+      The Server-implementation-id field is four octets and indicates
+      the version of the communication server providing the remote end
+      of the PPP connection.
+
+   Server-name
+
+      This optional field contains the "AppleTalk ASCII" name of the
+      server.  The character codes used in "AppleTalk ASCII" are defined
+      in [3], appendix D, "Character codes".  The length of the name is
+      bounded by the option length.
+
+3.6.  Zone-Information
+
+   Description
+
+      This Configuration Option provides a way to obtain information
+      about the AppleTalk zone used for the PPP connection.
+
+      The nature of this option is advisory only.  It is provided as a
+      means of improving the end system's ability to provide a simple
+      user interface.
+
+   A summary of the Zone-Information 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     |           Zone-name...        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      7
+
+   Length
+
+      >= 3
+
+   Zone-name
+
+      This field contains the "AppleTalk ASCII" zone name in which the
+      server resides.  The character codes used in "AppleTalk ASCII" are
+      defined in [3], appendix D, "Character codes".  The length of the
+      name is bounded by the option length.
+
+
+
+Parker                                                         [Page 12]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+3.7.  Default-Router-Address
+
+   Description
+
+
+      This Configuration Option provides a way to obtain information
+      about a "default" Appletalk router which may be used to obtain
+      network information such as zone names.  It is provided as a means
+      of obtaining the address of a router in the case both sides of the
+      link are end systems.
+
+      Any AppleTalk RTMP packets received should supercede information
+      negotiated in this option.
+
+      By default, no default router is present.
+
+   A summary of the Default-Router-Address 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     |    Reserved   |     AT-Net    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     AT-Net    |    AT-Node    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      8
+
+   Length
+
+      6
+
+   Reserved
+
+      This octet is reserved and MUST be set to zero on transmission and
+      ignored on reception.
+
+   AT-Net
+
+      The two octet AT-Net is the AppleTalk network number of the
+      default router.  This two octet quantity represents a 16 bit
+      unsigned number sent in "network byte order" (most significant
+      octet first).
+
+
+
+
+Parker                                                         [Page 13]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+   AT-Node
+
+      The one octet AT-Node is the AppleTalk node ID of the default
+      router.
+
+A.  ATCP Recommended Options
+
+   The ATCP is designed to support three different modes of operation.
+   Each mode places constraints on the configuration options used and
+   the values negotiated.
+
+   The options for server information, zone information and default
+   router address are "informational" options provided by one end of the
+   connection and are not intended to be negotiated.  These options are
+   provided to support a higher level of service to dial-in end systems.
+
+   The options which SHOULD be negotiated in each case are outlined
+   below.  Any option not listed may be rejected.
+
+End System to Intermediate System - "dial-in"
+
+   This mode of operation is intended to support end system dial-in.
+
+         1       AppleTalk-Address (required)
+         2       Routing-Protocol (required, no routing protocol)
+         3       Suppress-Broadcasts (optional)
+         4       AT-Compression-Protocol (optional)
+         6       Server-information (optional, request from end system)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parker                                                         [Page 14]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+Intermediate system to Intermediate system - with network number
+
+   This mode of operation is intended to support WAN-to-WAN, i.e.,
+   router to router, connections where the link is configured with a
+   network number.
+
+         1      AppleTalk-Address (required, nets must be zero or equal)
+         2      Routing-Protocol (optional)
+         3      Suppress-Broadcasts (optional)
+
+Intermediate system to Intermediate system - without network number
+
+   This mode of operation is intended to support WAN-to-WAN, i.e.,
+   router to router, connections where the link is not configured with a
+   network number.  Routers in this mode are referred to as "half-
+   routers" in [3].
+
+         1      AppleTalk-Address (optional, nets & nodes MUST be zero)
+         2      Routing-Protocol (optional)
+         3      Suppress-Broadcasts (optional, suppress all broadcasts)
+
+References
+
+   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
+       Daydreamer, May 1992.
+
+   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+   [3] Sidhu G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk,
+       Second Edition", Addison-Wesley Publishing Company, Inc., May
+       1990.
+
+Acknowledgments
+
+   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).
+
+   This document is derivative of drafts written by the following
+   people.  Many thanks for their work, and for taking an initial stab
+   at the protocol:
+
+   Steve Senum (sjs@network.com), Network Systems Corporation
+   Jim Muchow (muchow@anubis.network.com), Network Systems Corporation
+   Frank Slaughter (fgs@Shiva.COM), Shiva Corporation
+
+
+
+
+
+Parker                                                         [Page 15]
+
+RFC 1378                        PPP ATCP                   November 1992
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Chair's Address
+
+   The working groups can be contacted via the current chairs:
+
+   Brian Lloyd
+   Lloyd & Associates
+   3420 Sudbury Road
+   Cameron Park, California 95682
+
+   Phone: (916) 676-1147
+   EMail: brian@lloyd.com
+
+
+   John Veizades
+   Apple Computer, Inc.
+   20525 Mariani Avenue
+   Cupertino, CA 95014
+
+   Phone: (408) 996-1010
+   EMail: veizades@apple.com
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Brad Parker
+   Cayman Systems, Inc.
+   26 Landsdowne Street
+   Cambridge, Ma 02139
+
+   EMail: brad@cayman.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parker                                                         [Page 16]
+
\ No newline at end of file