idnits 2.17.1 draft-ietf-pppext-x25-ds-01.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-04-26) 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. == Mismatching filename: the document gives the document name as 'draft-ietf-pppext-x25-ds-00', but the file name used is 'draft-ietf-pppext-x25-ds-01' == 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 (August 1998) is 9386 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 1, but not defined == Unused Reference: 'RFC-ffff' is defined on line 316, 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 (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson [DayDreamer] 2 Internet Draft 3 expires in six months August 1998 5 PPP in X.25 6 draft-ietf-pppext-x25-ds-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Northern Europe) 27 ftp.nis.garr.it (Southern Europe) 28 ftp.ietf.org (Eastern USA) 29 ftp.isi.edu (Western USA) 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) William Allen Simpson (1993-1994, 1996-1998). All 37 Rights Reserved. 39 Abstract 41 The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard 42 method for transporting multi-protocol datagrams over point-to-point 43 links. This document describes the use of X.25 for framing PPP 44 encapsulated packets. 46 Applicability 48 This specification is intended for those implementations that desire 49 to use facilities which are defined for PPP, such as the Link Control 50 Protocol, Network-layer Control Protocols, authentication, and com- 51 pression. These capabilities require a point-to-point relationship 52 between peers, and are not designed for multi-point or multi-access 53 environments. 55 Use of X.25 as a secondary framing mechanism (for example, with asyn- 56 chronous HDLC-like frames tunnelled through X.3) is outside the scope 57 of this specification. 59 1. Introduction 61 CCITT recommendation X.25 [X.25] describes a network layer protocol 62 providing error-free, sequenced, flow controlled, virtual circuits. 63 X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 64 and 6256. 66 At one time, it had been hoped that "PPP in HDLC-like Framing" 67 [RFC-1662] would co-exist with other X.25 transmissions on the same 68 links. Equipment could gradually be converted to PPP. Subsequently, 69 it has been learned that some switches actually remove the X.25 70 header, transport packets to another switch using a different proto- 71 col such as Frame Relay, and reconstruct the X.25 header at the final 72 hop. Co-existance and gradual migration are precluded. 74 When X.25 is configured as a point-to-point circuit, PPP can use X.25 75 as a framing mechanism, ignoring its other features. This is equiva- 76 lent to the technique used to carry SNAP headers over X.25 77 [RFC-1356]. 79 1.1. Terminology 81 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 82 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 83 described in [RFC-2119]. 85 To remain consistent with standard Internet practice, and avoid con- 86 fusion for people used to reading RFCs, all binary numbers in the 87 following descriptions are in Most Significant Bit to Least Signifi- 88 cant Bit order, from Most Significant Byte to Least Significant Byte, 89 reading from left to right, unless otherwise indicated. Note that 90 this is contrary to ISO and ITU practice, which orders bits as trans- 91 mitted (network bit order). Keep this in mind when comparing this 92 document with the other documents. 94 2. Physical Layer Requirements 96 PPP is capable of operating across most X.25 interfaces. The only 97 absolute requirement imposed by PPP is the provision of a bi- 98 directional full-duplex circuit, either dedicated (permanent) or cir- 99 cuit-switched, that can operate in a bit-synchronous mode, transpar- 100 ent to PPP Data Link Layer frames. 102 Interface Format 104 PPP presents an octet interface to the physical layer. There is 105 no provision for sub-octets to be supplied or accepted. 107 Transmission Rate 109 PPP does not impose any restrictions regarding transmission rate, 110 other than that of the particular X.25 interface. 112 Control Signals 114 Implementation of X.25 requires the provision of control signals, 115 that indicate when the link has become connected or disconnected. 116 These in turn provide the Up and Down events to the PPP LCP state 117 machine. 119 Because PPP does not normally require the use of control signals, 120 the failure of such signals MUST NOT affect correct operation of 121 PPP. Implications are discussed in [RFC-1662]. 123 2.1. Transmission Considerations 125 The definition of various encodings is the responsibility of the 126 DTE/DCE equipment in use, and is outside the scope of this specifica- 127 tion. 129 While PPP will operate without regard to the underlying representa- 130 tion of the bit stream, bit-synchronous X.25 requires NRZ encoding. 132 3. The Data Link Layer 134 This specification uses the principles, terminology, and frame struc- 135 ture described in [RFC-1356]. 137 The purpose of this specification is not to document what is already 138 standardized in [RFC-1356]. Instead, this document attempts to give 139 a concise summary and point out specific options and features used by 140 PPP. 142 3.1. Frame Header 144 Since both "PPP in HDLC-like Framing" [RFC-1662] and X.25 use ISO 145 3309 as a basis for framing, the X.25 header is easily substituted 146 for the smaller HDLC header. These fields are transmitted from left 147 to right. 149 +-+-+-+-+-+-+-+-+ 150 | Flag (0x7e) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+?+?+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Address | Control |0|0| SVC# (hi) | SVC# (lo) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |p(r) |M|p(s) |0| PPP Protocol | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 The PPP Protocol field and the following Information and Padding 158 fields are described in the Point-to-Point Protocol Encapsulation 159 [RFC-1661]. 161 3.2. Modification of the Basic Frame 163 The Link Control Protocol can negotiate modifications to the basic 164 frame structure. This is not compatible with X.25. 166 Address-and-Control-Field-Compression 168 Since the X.25 Address and Control field values are not constant, 169 and are modified as the frame is transported by the network 170 switching fabric, Address-and-Control-Field-Compression cannot 171 affect the frame format. 173 FCS-Alternatives 175 Since X.25 requires a 16-bit FCS, which is modified as the frame 176 is transported by the network switching fabric, FCS-Alternatives 177 cannot affect the frame format. 179 In general, framing-related LCP Configuration Options are not recog- 180 nizable, and are not acceptable for negotiation. The implementation 181 MUST NOT send ineffectual options in a Configure-Request, and SHOULD 182 respond to such requested options with a Configure-Reject. See [RFC- 183 ffff] for details. 185 3.3. Modification of the Basic Packet 187 The Link Control Protocol can negotiate modifications to the basic 188 packet structure. These are transparent to X.25. 190 Protocol-Field-Compression 192 The X.25 framing does not align the PPP Information field on a 193 32-bit boundary. Alignment to a 16-bit boundary occurs when the 194 Protocol field is compressed to a single octet. When this 195 improves throughput, Protocol-Field-Compression SHOULD be negoti- 196 ated. 198 4. Call Setup 200 When the link is configured as a Permanent Virtual Circuit (PVC), 201 support for Switched Virtual Circuit (SVC) call setup and clearing is 202 not required. Calls are Established and Terminated using PPP LCP 203 packets. 205 When the link is configured as a Switched Virtual Circuit (SVC), the 206 first octet in the Call User Data (CUD) Field (the first data octet 207 in the Call Request packet) is used for protocol demultiplexing, in 208 accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC 209 TR 9577 [TR 9577]. This field contains a one octet Network Layer 210 Protocol Identifier (NLPID), which identifies the encapsulation in 211 use over the X.25 virtual circuit. The CUD field MAY contain more 212 than one octet of information. 214 The PPP encapsulation MUST be indicated by the PPP NLPID value (CF 215 hex). Any subsequent octet in this CUD is extraneous and MUST be 216 ignored. 218 Multipoint networks (or multicast groups) MUST refuse calls which 219 indicate the PPP NLPID in the CUD. 221 The accidental connection of a link to feed a multipoint network (or 222 multicast group) SHOULD result in a misconfiguration indication. 223 This can be detected by multiple responses to the LCP Configure- 224 Request with the same Identifier, coming from different framing 225 addresses. Some implementations might be physically unable to either 226 log or report such information. 228 Conformance with this specification requires that the PPP NLPID (CF) 229 be supported. In addition, conformance with [RFC-1356] requires that 230 the IP NLPID (CC) be supported, and does not require that other NLPID 231 values be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS 232 (82). 234 When IP address negotiation and/or VJ header compression are desired, 235 the PPP call setup SHOULD be attempted first. If the PPP call setup 236 fails, the normal IP call setup MUST be used. 238 The PPP NLPID value SHOULD NOT be used to demultiplex circuits that 239 use the Zero NLPID in call setup, as described in [RFC-1356]. When 240 such a circuit exists concurrently with PPP encapsulated circuits, 241 only network layer traffic which has not been negotiated by the asso- 242 ciated NCP is sent over the Zero NLPID circuit. 244 Rationale: 246 Using call setup to determine if PPP is supported should be inex- 247 pensive, when users aren't charged for failed calls. 249 Using the Zero NLPID call together with PPP could be expensive, 250 when users are charged per packet or for connect time, due to the 251 probing of PPP configuration packets at each call. 253 PPP configuration provides a direct indication of the availability 254 of service, and on that basis is preferred over the Zero NLPID 255 technique, which can result in "black-holes". 257 5. Configuration Details 259 The following Configuration Options are recommended: 261 Magic Number 262 Protocol Field Compression 264 The standard LCP configuration defaults apply to X.25 links, except 265 Maximum-Receive-Unit (MRU). 267 To ensure interoperability with existing X.25 implementations, the 268 initial MRU is 1600 octets [RFC-1356]. This only affects the minimum 269 required buffer space available for receiving packets, not the size 270 of packets sent. 272 The typical network feeding the link is likely to have a MRU of 273 either 1500, or 2048 or greater. To avoid fragmentation, the Maxi- 274 mum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed 275 1500, unless a peer MRU of 2048 or greater is specifically negoti- 276 ated. 278 The X.25 packet size is not directly related to the MRU. Instead, 279 Protocol Data Units (PDUs) are sent as X.25 "complete packet 280 sequences". That is, PDUs begin on X.25 data packet boundaries and 281 the M bit ("more data") is used to fragment PDUs that are larger than 282 one X.25 data packet in length. 284 Security Considerations 286 Implementations MUST NOT consider PPP authentication on call setup 287 for one circuit between two systems to apply to concurrent call setup 288 for other circuits between those same two systems. This results in 289 possible security lapses due to over-reliance on the integrity and 290 security of switching systems and administrations. An insertion 291 attack might be undetected. An attacker which is able to spoof the 292 same calling identity might be able to avoid link authentication. 294 Acknowledgements 296 This design was inspired by the paper "Parameter Negotiation for the 297 Multiprotocol Interconnect", Keith Sklower and Clifford Frost, Uni- 298 versity of California, Berkeley, 1992, unpublished. 300 References 302 [RFC-1356] Malis, A., Robinson, D., Ullman R., "Multiprotocol Inter- 303 connect on X.25 and ISDN in the Packet Mode", August 304 1992. 306 [RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 307 STD-51, DayDreamer, July 1994. 309 [RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51, 310 DayDreamer, July 1994. 312 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP-14, Harvard University, March 314 1997. 316 [RFC-ffff] Simpson, W., "PPP with Framing Conversion", work in 317 progress. 319 [TR 9577] ISO/IEC TR 9577:1990(E), "Information technology - 320 Telecommunications and Information exchange between sys- 321 tems - Protocol Identification in the network layer", 322 1990-10-15. 324 [X.25] CCITT Recommendation X.25, "Interface Between Data Termi- 325 nal Equipment (DTE) and Data Circuit Terminating Equip- 326 ment (DCE) for Terminals Operating in the Packet Mode on 327 Public Data Networks", International Telecommunication 328 Union, CCITT Red Book, Volume VIII, Fascicle VIII.2, Rec. 329 X.25, October 1984. 331 Contacts 333 Comments about this document should be discussed on the ietf- 334 ppp@merit.edu mailing list. 336 This document was reviewed by the Point-to-Point Protocol Working 337 Group of the Internet Engineering Task Force (IETF). The working 338 group can be contacted via the current chair: 340 Karl Fox 341 Ascend Communications 342 655 Metro Place South, Suite 370 343 Dublin, Ohio 43017 345 karl@Ascend.com 347 Questions about this document can also be directed to: 349 William Allen Simpson 350 DayDreamer 351 Computer Systems Consulting Services 352 1384 Fontaine 353 Madison Heights, Michigan 48071 355 wsimpson@UMich.edu 356 wsimpson@GreenDragon.com (preferred) 358 Full Copyright Statement 360 Copyright (C) William Allen Simpson (1993-1994, 1996-1998). All 361 Rights Reserved. 363 This document and translations of it may be copied and furnished to 364 others, and derivative works that comment on or otherwise explain it 365 or assist in its implementation may be prepared, copied, published 366 and distributed, in whole or in part, without restriction of any 367 kind, provided that the above copyright notice and this paragraph are 368 included on all such copies and derivative works. However, this doc- 369 ument itself may not be modified in any way, except as required to 370 translate it into languages other than English. 372 This document and the information contained herein is provided on an 373 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 374 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.