summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1598.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1598.txt')
-rw-r--r--doc/rfc/rfc1598.txt445
1 files changed, 445 insertions, 0 deletions
diff --git a/doc/rfc/rfc1598.txt b/doc/rfc/rfc1598.txt
new file mode 100644
index 0000000..c5cc2db
--- /dev/null
+++ b/doc/rfc/rfc1598.txt
@@ -0,0 +1,445 @@
+
+
+
+
+
+
+Network Working Group W. Simpson
+Request for Comments: 1598 Daydreamer
+Category: Standards Track March 1994
+
+
+ PPP in X.25
+
+
+
+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.
+ This document describes the use of X.25 for framing PPP encapsulated
+ packets.
+
+ This document is the product of the Point-to-Point Protocol Working
+ Group of the Internet Engineering Task Force (IETF). Comments should
+ be submitted to the ietf-ppp@merit.edu mailing list.
+
+Applicability
+
+ This specification is intended for those implementations which desire
+ to use facilities which are defined for PPP, such as the Link Control
+ Protocol, Network-layer Control Protocols, authentication, and
+ compression. These capabilities require a point-to-point
+ relationship between peers, and are not designed for multi-point or
+ multi-access environments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page i]
+ RFC 1598 PPP in X.25 March 1994
+
+
+ Table of Contents
+
+
+ 1. Introduction .......................................... 1
+
+ 2. Physical Layer Requirements ........................... 2
+
+ 3. The Data Link Layer ................................... 2
+ 3.1 Frame Format .................................... 3
+ 3.2 Modification of the Basic Frame ................. 3
+
+ 4. Call Setup ............................................ 4
+
+ 5. Configuration Details ................................. 5
+
+ SECURITY CONSIDERATIONS ...................................... 6
+
+ REFERENCES ................................................... 6
+
+ ACKNOWLEDGEMENTS ............................................. 6
+
+ CHAIR'S ADDRESS .............................................. 7
+
+ AUTHOR'S ADDRESS ............................................. 7
+
+
+
+
+1. Introduction
+
+ CCITT recommendation X.25 [2] describes a network layer protocol
+ providing error-free, sequenced, flow controlled, virtual circuits.
+ X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
+ and 6256.
+
+ PPP also uses ISO 3309 HDLC as a basis for its framing [3].
+
+ When X.25 is configured as a point-to-point circuit, PPP can use X.25
+ as a framing mechanism, ignoring its other features. This is
+ equivalent to the technique used to carry SNAP headers over X.25 [4].
+
+ At one time, it had been hoped that PPP HDLC frames and X.25 frames
+ would co-exist on the same links. Equipment could gradually be
+ converted to PPP. Subsequently, it has been learned that some
+ switches actually remove the X.25 header, transport packets to
+ another switch using a different protocol such as Frame Relay, and
+ reconstruct the X.25 header at the final hop. Co-existance and
+ gradual migration are precluded.
+
+
+
+Simpson [Page 1]
+ RFC 1598 PPP in X.25 March 1994
+
+
+2. Physical Layer Requirements
+
+ PPP treats X.25 framing as a bit synchronous link. The link MUST be
+ full-duplex, but MAY be either dedicated (permanent) or switched.
+
+ Interface Format
+
+ PPP presents an octet interface to the physical layer. There is
+ no provision for sub-octets to be supplied or accepted.
+
+ Transmission Rate
+
+ PPP does not impose any restrictions regarding transmission rate,
+ other than that of the particular X.25 interface.
+
+ Control Signals
+
+ Implementation of X.25 requires the provision of control signals,
+ which indicate when the link has become connected or disconnected.
+ These in turn provide the Up and Down events to the LCP state
+ machine.
+
+ Because PPP does not normally require the use of control signals,
+ the failure of such signals MUST NOT affect correct operation of
+ PPP. Implications are discussed in [2].
+
+ Encoding
+
+ The definition of various encodings is the responsibility of the
+ DTE/DCE equipment in use, and is outside the scope of this
+ specification.
+
+ While PPP will operate without regard to the underlying
+ representation of the bit stream, X.25 requires NRZ encoding.
+
+
+
+3. The Data Link Layer
+
+ This specification uses the principles, terminology, and frame
+ structure described in "Multiprotocol Interconnect on X.25 and ISDN
+ in the Packet Mode" [4].
+
+ The purpose of this specification is not to document what is already
+ standardized in [4]. Instead, this document attempts to give a
+ concise summary and point out specific options and features used by
+ PPP.
+
+
+
+
+Simpson [Page 2]
+ RFC 1598 PPP in X.25 March 1994
+
+
+3.1. Frame Format
+
+ Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a basis
+ for framing, the X.25 header is easily substituted for the smaller
+ HDLC header. 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
+ +-+-+-+-+-+-+-+-+
+ | Flag (0x7e) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |p(r) |M|p(s) |0| PPP Protocol |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The PPP Protocol field and the following Information and Padding
+ fields are described in the Point-to-Point Protocol Encapsulation
+ [1].
+
+
+
+3.2. Modification of the Basic Frame
+
+ The Link Control Protocol can negotiate modifications to the basic
+ frame structure. However, modified frames will always be clearly
+ distinguishable from standard frames.
+
+ Address-and-Control-Field-Compression
+
+ Because the Address and Control field values are not constant, and
+ are modified as the frame is transported by the network switching
+ fabric, Address-and-Control-Field-Compression MUST NOT be
+ negotiated.
+
+ Protocol-Field-Compression
+
+ Note that unlike the HDLC framing, the X.25 framing does not align
+ the Information field on a 32-bit boundary. Alignment to a 16-bit
+ boundary occurs when the Protocol field is compressed to a single
+ octet. When this improves throughput, Protocol-Field-Compression
+ SHOULD be negotiated.
+
+
+
+
+
+
+
+
+
+Simpson [Page 3]
+ RFC 1598 PPP in X.25 March 1994
+
+
+4. Call Setup
+
+ When the link is configured as a Permanent Virtual Circuit (PVC),
+ support for Switched Virtual Circuit (SVC) call setup and clearing is
+ not required. Calls are Established and Terminated using PPP LCP
+ packets.
+
+ When the link is configured as a Switched Virtual Circuit (SVC), the
+ first octet in the Call User Data (CUD) Field (the first data octet
+ in the Call Request packet) is used for protocol demultiplexing, in
+ accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC
+ TR 9577 [5]. This field contains a one octet Network Layer Protocol
+ Identifier (NLPID), which identifies the encapsulation in use over
+ the X.25 virtual circuit. The CUD field MAY contain more than one
+ octet of information.
+
+ The PPP encapsulation MUST be indicated by the PPP NLPID value (CF
+ hex). Any subsequent octet in this CUD is extraneous and MUST be
+ ignored.
+
+ Multipoint networks (or multicast groups) MUST refuse calls which
+ indicate the PPP NLPID in the CUD.
+
+ The accidental connection of a link to feed a multipoint network (or
+ multicast group) SHOULD result in a misconfiguration indication.
+ This can be detected by multiple responses to the LCP Configure-
+ Request with the same Identifier, coming from different framing
+ addresses. Some implementations might be physically unable to either
+ log or report such information.
+
+ Conformance with this specification requires that the PPP NLPID (CF)
+ be supported. In addition, conformance with [4] requires that the IP
+ NLPID (CC) be supported, and does not require that other NLPID values
+ be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS (82).
+
+ When IP address negotiation and/or VJ header compression are desired,
+ the PPP call setup SHOULD be attempted first. If the PPP call setup
+ fails, the normal IP call setup MUST be used.
+
+ The PPP NLPID value SHOULD NOT be used to demultiplex circuits which
+ use the Zero NLPID in call setup, as described in [4]. When such a
+ circuit exists concurrently with PPP encapsulated circuits, only
+ network layer traffic which has not been negotiated by the associated
+ NCP is sent over the Zero NLPID circuit.
+
+ Rationale:
+
+ Using call setup to determine if PPP is supported should be
+
+
+
+Simpson [Page 4]
+ RFC 1598 PPP in X.25 March 1994
+
+
+ inexpensive, when users aren't charged for failed calls.
+
+ Using the Zero NLPID call together with PPP could be expensive,
+ when users are charged per packet or for connect time, due to the
+ probing of PPP configuration packets at each call.
+
+ PPP configuration provides a direct indication of the availability
+ of service, and on that basis is preferred over the Zero NLPID
+ technique, which can result in "black-holes".
+
+
+
+5. Configuration Details
+
+ The following Configuration Options are recommended:
+
+ Magic Number
+ Protocol Field Compression
+
+ The standard LCP configuration defaults apply to X.25 links, except
+ MRU.
+
+ To ensure interoperability with existing X.25 implementations, the
+ initial Maximum-Receive-Unit (MRU) is 1600 octets [4]. This only
+ affects the minimum required buffer space available for receiving
+ packets, not the size of packets sent.
+
+ The typical network feeding the link is likely to have a MRU of
+ either 1500, or 2048 or greater. To avoid fragmentation, the
+ Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
+ exceed 1500, unless a peer MRU of 2048 or greater is specifically
+ negotiated.
+
+ The X.25 packet size is not directly related to the MRU. Instead,
+ Protocol Data Units (PDUs) are sent as X.25 "complete packet
+ sequences". That is, PDUs begin on X.25 data packet boundaries and
+ the M bit ("more data") is used to fragment PDUs that are larger than
+ one X.25 data packet in length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 5]
+ RFC 1598 PPP in X.25 March 1994
+
+
+Security Considerations
+
+ Implementations MUST NOT consider PPP authentication on call setup
+ for one circuit between two systems to apply to concurrent call setup
+ for other circuits between those same two systems. This results in
+ possible security lapses due to over-reliance on the integrity and
+ security of switching systems and administrations. An insertion
+ attack might be undetected. An attacker which is able to spoof the
+ same calling identity might be able to avoid link authentication.
+
+
+
+References
+
+ [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
+ 1548, December 1993.
+
+ [2] CCITT Recommendation X.25, "Interface Between Data Terminal
+ Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
+ for Terminals Operating in the Packet Mode on Public Data
+ Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
+
+ [3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, December
+ 1993.
+
+ [4] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
+ Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
+ August 1992.
+
+ [5] ISO/IEC TR 9577, "Information technology - Telecommunications
+ and Information exchange between systems - Protocol
+ Identification in the network layer", 1990 (E) 1990-10-15.
+
+
+
+Acknowledgments
+
+ This design was inspired by the paper "Parameter Negotiation for the
+ Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
+ University of California, Berkeley, 1992, unpublished.
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 6]
+ RFC 1598 PPP in X.25 March 1994
+
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Advanced Computer Communications
+ 315 Bollay Drive
+ Santa Barbara, California 93117
+
+ EMail: fbaker@acc.com
+
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ 1384 Fontaine
+ Madison Heights, Michigan 48071
+
+ EMail: Bill.Simpson@um.cc.umich.edu
+ bsimpson@MorningStar.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 7]
+
+