idnits 2.17.1 draft-ietf-pppext-x25-ds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-1661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9630 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Unused Reference: 'RFC-ffff' is defined on line 313, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ffff' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR 9577' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months November 1997 6 PPP in X.25 7 draft-ietf-pppext-x25-ds-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Europe) 28 ds.internic.net (US East Coast) 29 ftp.isi.edu (US West Coast) 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Abstract 36 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 37 method for transporting multi-protocol datagrams over point-to-point 38 links. This document describes the use of X.25 for framing PPP 39 encapsulated packets. 41 Applicability 43 This specification is intended for those implementations that desire 44 to use facilities which are defined for PPP, such as the Link Control 45 Protocol, Network-layer Control Protocols, authentication, and com- 46 pression. These capabilities require a point-to-point relationship 47 between peers, and are not designed for multi-point or multi-access 48 environments. 50 Use of X.25 as a secondary framing mechanism (for example, with asyn- 51 chronous HDLC-like frames tunnelled through X.3) is outside the scope 52 of this specification. 54 1. Introduction 56 CCITT recommendation X.25 [X.25] describes a network layer protocol 57 providing error-free, sequenced, flow controlled, virtual circuits. 58 X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 59 and 6256. 61 At one time, it had been hoped that "PPP in HDLC-like Framing" 62 [RFC-1662] would co-exist with other X.25 transmissions on the same 63 links. Equipment could gradually be converted to PPP. Subsequently, 64 it has been learned that some switches actually remove the X.25 65 header, transport packets to another switch using a different proto- 66 col such as Frame Relay, and reconstruct the X.25 header at the final 67 hop. Co-existance and gradual migration are precluded. 69 When X.25 is configured as a point-to-point circuit, PPP can use X.25 70 as a framing mechanism, ignoring its other features. This is equiva- 71 lent to the technique used to carry SNAP headers over X.25 72 [RFC-1356]. 74 1.1. Terminology 76 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 77 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 78 described in [RFC-2119]. 80 To remain consistent with standard Internet practice, and avoid con- 81 fusion for people used to reading RFCs, all binary numbers in the 82 following descriptions are in Most Significant Bit to Least Signifi- 83 cant Bit order, from Most Significant Byte to Least Significant Byte, 84 reading from left to right, unless otherwise indicated. Note that 85 this is contrary to ISO and ITU practice, which orders bits as trans- 86 mitted (network bit order). Keep this in mind when comparing this 87 document with the other documents. 89 2. Physical Layer Requirements 91 PPP is capable of operating across most X.25 interfaces. The only 92 absolute requirement imposed by PPP is the provision of a bi- 93 directional full-duplex circuit, either dedicated (permanent) or cir- 94 cuit-switched, that can operate in a bit-synchronous mode, transpar- 95 ent to PPP Data Link Layer frames. 97 Interface Format 99 PPP presents an octet interface to the physical layer. There is 100 no provision for sub-octets to be supplied or accepted. 102 Transmission Rate 104 PPP does not impose any restrictions regarding transmission rate, 105 other than that of the particular X.25 interface. 107 Control Signals 109 Implementation of X.25 requires the provision of control signals, 110 that indicate when the link has become connected or disconnected. 111 These in turn provide the Up and Down events to the PPP LCP state 112 machine. 114 Because PPP does not normally require the use of control signals, 115 the failure of such signals MUST NOT affect correct operation of 116 PPP. Implications are discussed in [RFC-1662]. 118 2.1. Transmission Considerations 120 The definition of various encodings is the responsibility of the 121 DTE/DCE equipment in use, and is outside the scope of this specifica- 122 tion. 124 While PPP will operate without regard to the underlying representa- 125 tion of the bit stream, bit-synchronous X.25 requires NRZ encoding. 127 3. The Data Link Layer 129 This specification uses the principles, terminology, and frame struc- 130 ture described in [RFC-1356]. 132 The purpose of this specification is not to document what is already 133 standardized in [RFC-1356]. Instead, this document attempts to give 134 a concise summary and point out specific options and features used by 135 PPP. 137 3.1. Frame Header 139 Since both "PPP in HDLC-like Framing" [RFC-1662] and X.25 use ISO 140 3309 as a basis for framing, the X.25 header is easily substituted 141 for the smaller HDLC header. These fields are transmitted from left 142 to right. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+ 147 | Flag (0x7e) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+?+?+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Address | Control |0|0| SVC# (hi) | SVC# (lo) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |p(r) |M|p(s) |0| PPP Protocol | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 The PPP Protocol field and the following Information and Padding 155 fields are described in the Point-to-Point Protocol Encapsulation 156 [RFC-1661]. 158 3.2. Modification of the Basic Frame 160 The Link Control Protocol can negotiate modifications to the basic 161 frame structure. This is not compatible with X.25. 163 Address-and-Control-Field-Compression 165 Since the X.25 Address and Control field values are not constant, 166 and are modified as the frame is transported by the network 167 switching fabric, Address-and-Control-Field-Compression cannot 168 affect the frame format. 170 FCS-Alternatives 172 Since X.25 requires a 16-bit FCS, which is modified as the frame 173 is transported by the network switching fabric, FCS-Alternatives 174 cannot affect the frame format. 176 In general, framing-related LCP Configuration Options are not recog- 177 nizable, and are not acceptable for negotiation. The implementation 178 MUST NOT send ineffectual options in a Configure-Request, and SHOULD 179 respond to such requested options with a Configure-Reject. See [RFC- 180 ffff] for details. 182 3.3. Modification of the Basic Packet 184 The Link Control Protocol can negotiate modifications to the basic 185 packet structure. These are transparent to X.25. 187 Protocol-Field-Compression 189 The X.25 framing does not align the PPP Information field on a 190 32-bit boundary. Alignment to a 16-bit boundary occurs when the 191 Protocol field is compressed to a single octet. When this 192 improves throughput, Protocol-Field-Compression SHOULD be negoti- 193 ated. 195 4. Call Setup 197 When the link is configured as a Permanent Virtual Circuit (PVC), 198 support for Switched Virtual Circuit (SVC) call setup and clearing is 199 not required. Calls are Established and Terminated using PPP LCP 200 packets. 202 When the link is configured as a Switched Virtual Circuit (SVC), the 203 first octet in the Call User Data (CUD) Field (the first data octet 204 in the Call Request packet) is used for protocol demultiplexing, in 205 accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC 206 TR 9577 [TR 9577]. This field contains a one octet Network Layer 207 Protocol Identifier (NLPID), which identifies the encapsulation in 208 use over the X.25 virtual circuit. The CUD field MAY contain more 209 than one octet of information. 211 The PPP encapsulation MUST be indicated by the PPP NLPID value (CF 212 hex). Any subsequent octet in this CUD is extraneous and MUST be 213 ignored. 215 Multipoint networks (or multicast groups) MUST refuse calls which 216 indicate the PPP NLPID in the CUD. 218 The accidental connection of a link to feed a multipoint network (or 219 multicast group) SHOULD result in a misconfiguration indication. 220 This can be detected by multiple responses to the LCP Configure- 221 Request with the same Identifier, coming from different framing 222 addresses. Some implementations might be physically unable to either 223 log or report such information. 225 Conformance with this specification requires that the PPP NLPID (CF) 226 be supported. In addition, conformance with [RFC-1356] requires that 227 the IP NLPID (CC) be supported, and does not require that other NLPID 228 values be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS 229 (82). 231 When IP address negotiation and/or VJ header compression are desired, 232 the PPP call setup SHOULD be attempted first. If the PPP call setup 233 fails, the normal IP call setup MUST be used. 235 The PPP NLPID value SHOULD NOT be used to demultiplex circuits that 236 use the Zero NLPID in call setup, as described in [RFC-1356]. When 237 such a circuit exists concurrently with PPP encapsulated circuits, 238 only network layer traffic which has not been negotiated by the asso- 239 ciated NCP is sent over the Zero NLPID circuit. 241 Rationale: 243 Using call setup to determine if PPP is supported should be inex- 244 pensive, when users aren't charged for failed calls. 246 Using the Zero NLPID call together with PPP could be expensive, 247 when users are charged per packet or for connect time, due to the 248 probing of PPP configuration packets at each call. 250 PPP configuration provides a direct indication of the availability 251 of service, and on that basis is preferred over the Zero NLPID 252 technique, which can result in "black-holes". 254 5. Configuration Details 256 The following Configuration Options are recommended: 258 Magic Number 259 Protocol Field Compression 261 The standard LCP configuration defaults apply to X.25 links, except 262 Maximum-Receive-Unit (MRU). 264 To ensure interoperability with existing X.25 implementations, the 265 initial MRU is 1600 octets [RFC-1356]. This only affects the minimum 266 required buffer space available for receiving packets, not the size 267 of packets sent. 269 The typical network feeding the link is likely to have a MRU of 270 either 1500, or 2048 or greater. To avoid fragmentation, the Maxi- 271 mum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed 272 1500, unless a peer MRU of 2048 or greater is specifically negoti- 273 ated. 275 The X.25 packet size is not directly related to the MRU. Instead, 276 Protocol Data Units (PDUs) are sent as X.25 "complete packet 277 sequences". That is, PDUs begin on X.25 data packet boundaries and 278 the M bit ("more data") is used to fragment PDUs that are larger than 279 one X.25 data packet in length. 281 Security Considerations 283 Implementations MUST NOT consider PPP authentication on call setup 284 for one circuit between two systems to apply to concurrent call setup 285 for other circuits between those same two systems. This results in 286 possible security lapses due to over-reliance on the integrity and 287 security of switching systems and administrations. An insertion 288 attack might be undetected. An attacker which is able to spoof the 289 same calling identity might be able to avoid link authentication. 291 Acknowledgements 293 This design was inspired by the paper "Parameter Negotiation for the 294 Multiprotocol Interconnect", Keith Sklower and Clifford Frost, Uni- 295 versity of California, Berkeley, 1992, unpublished. 297 References 299 [RFC-1356] Malis, A., Robinson, D., Ullman R., "Multiprotocol Inter- 300 connect on X.25 and ISDN in the Packet Mode", August 301 1992. 303 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 304 STD-51, DayDreamer, July 1994. 306 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 307 DayDreamer, July 1994. 309 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, Harvard University, March 311 1997. 313 [RFC-ffff] Simpson, W., "PPP with Framing Conversion", work in 314 progress. 316 [TR 9577] ISO/IEC TR 9577:1990(E), "Information technology - 317 Telecommunications and Information exchange between sys- 318 tems - Protocol Identification in the network layer", 319 1990-10-15. 321 [X.25] CCITT Recommendation X.25, "Interface Between Data Termi- 322 nal Equipment (DTE) and Data Circuit Terminating Equip- 323 ment (DCE) for Terminals Operating in the Packet Mode on 324 Public Data Networks", International Telecommunication 325 Union, CCITT Red Book, Volume VIII, Fascicle VIII.2, Rec. 326 X.25, October 1984. 328 Contacts 330 Comments about this document should be discussed on the ietf- 331 ppp@merit.edu mailing list. 333 This document was reviewed by the Point-to-Point Protocol Working 334 Group of the Internet Engineering Task Force (IETF). The working 335 group can be contacted via the current chair: 337 Karl Fox 338 Ascend Communications 339 655 Metro Place South, Suite 370 340 Dublin, Ohio 43017 342 karl@Ascend.com 344 Questions about this document can also be directed to: 346 William Allen Simpson 347 DayDreamer 348 Computer Systems Consulting Services 349 1384 Fontaine 350 Madison Heights, Michigan 48071 352 wsimpson@UMich.edu 353 wsimpson@GreenDragon.com (preferred)