summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1378.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1378.txt')
-rw-r--r--doc/rfc/rfc1378.txt899
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