File: rfc1598.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (445 lines) | stat: -rw-r--r-- 13,835 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
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]