| blob | 5a5b214cc1115f867dc30cbcac9f97a8f280a189 |
8 Network Working Group W. Simpson, Editor
9 Request for Comments: 1662 Daydreamer
10 STD: 51 July 1994
11 Obsoletes: 1549
12 Category: Standards Track
15 PPP in HDLC-like Framing
18 Status of this Memo
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
27 Abstract
29 The Point-to-Point Protocol (PPP) [1] provides a standard method for
30 transporting multi-protocol datagrams over point-to-point links.
32 This document describes the use of HDLC-like framing for PPP
33 encapsulated packets.
36 Table of Contents
39 1. Introduction .......................................... 1
40 1.1 Specification of Requirements ................... 2
41 1.2 Terminology ..................................... 2
43 2. Physical Layer Requirements ........................... 3
45 3. The Data Link Layer ................................... 4
46 3.1 Frame Format .................................... 5
47 3.2 Modification of the Basic Frame ................. 7
49 4. Octet-stuffed framing ................................. 8
50 4.1 Flag Sequence ................................... 8
51 4.2 Transparency .................................... 8
52 4.3 Invalid Frames .................................. 9
53 4.4 Time Fill ....................................... 9
54 4.4.1 Octet-synchronous ............................... 9
55 4.4.2 Asynchronous .................................... 9
56 4.5 Transmission Considerations ..................... 10
57 4.5.1 Octet-synchronous ............................... 10
58 4.5.2 Asynchronous .................................... 10
61 Simpson [Page i]
62 RFC 1662 HDLC-like Framing July 1994
65 5. Bit-stuffed framing ................................... 11
66 5.1 Flag Sequence ................................... 11
67 5.2 Transparency .................................... 11
68 5.3 Invalid Frames .................................. 11
69 5.4 Time Fill ....................................... 11
70 5.5 Transmission Considerations ..................... 12
72 6. Asynchronous to Synchronous Conversion ................ 13
74 7. Additional LCP Configuration Options .................. 14
75 7.1 Async-Control-Character-Map (ACCM) .............. 14
77 APPENDICES ................................................... 17
78 A. Recommended LCP Options ............................... 17
79 B. Automatic Recognition of PPP Frames ................... 17
80 C. Fast Frame Check Sequence (FCS) Implementation ........ 18
81 C.1 FCS table generator ............................. 18
82 C.2 16-bit FCS Computation Method ................... 19
83 C.3 32-bit FCS Computation Method ................... 21
85 SECURITY CONSIDERATIONS ...................................... 24
86 REFERENCES ................................................... 24
87 ACKNOWLEDGEMENTS ............................................. 25
88 CHAIR'S ADDRESS .............................................. 25
89 EDITOR'S ADDRESS ............................................. 25
94 1. Introduction
96 This specification provides for framing over both bit-oriented and
97 octet-oriented synchronous links, and asynchronous links with 8 bits
98 of data and no parity. These links MUST be full-duplex, but MAY be
99 either dedicated or circuit-switched.
101 An escape mechanism is specified to allow control data such as
102 XON/XOFF to be transmitted transparently over the link, and to remove
103 spurious control data which may be injected into the link by
104 intervening hardware and software.
106 Some protocols expect error free transmission, and either provide
107 error detection only on a conditional basis, or do not provide it at
108 all. PPP uses the HDLC Frame Check Sequence for error detection.
109 This is commonly available in hardware implementations, and a
110 software implementation is provided.
117 Simpson [Page 1]
118 RFC 1662 HDLC-like Framing July 1994
121 1.1. Specification of Requirements
123 In this document, several words are used to signify the requirements
124 of the specification. These words are often capitalized.
126 MUST This word, or the adjective "required", means that the
127 definition is an absolute requirement of the specification.
129 MUST NOT This phrase means that the definition is an absolute
130 prohibition of the specification.
132 SHOULD This word, or the adjective "recommended", means that there
133 may exist valid reasons in particular circumstances to
134 ignore this item, but the full implications must be
135 understood and carefully weighed before choosing a
136 different course.
138 MAY This word, or the adjective "optional", means that this
139 item is one of an allowed set of alternatives. An
140 implementation which does not include this option MUST be
141 prepared to interoperate with another implementation which
142 does include the option.
145 1.2. Terminology
147 This document frequently uses the following terms:
149 datagram The unit of transmission in the network layer (such as IP).
150 A datagram may be encapsulated in one or more packets
151 passed to the data link layer.
153 frame The unit of transmission at the data link layer. A frame
154 may include a header and/or a trailer, along with some
155 number of units of data.
157 packet The basic unit of encapsulation, which is passed across the
158 interface between the network layer and the data link
159 layer. A packet is usually mapped to a frame; the
160 exceptions are when data link layer fragmentation is being
161 performed, or when multiple packets are incorporated into a
162 single frame.
164 peer The other end of the point-to-point link.
166 silently discard
167 The implementation discards the packet without further
168 processing. The implementation SHOULD provide the
169 capability of logging the error, including the contents of
170 the silently discarded packet, and SHOULD record the event
171 in a statistics counter.
174 Simpson [Page 2]
175 RFC 1662 HDLC-like Framing July 1994
178 2. Physical Layer Requirements
180 PPP is capable of operating across most DTE/DCE interfaces (such as,
181 EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute
182 requirement imposed by PPP is the provision of a full-duplex circuit,
183 either dedicated or circuit-switched, which can operate in either an
184 asynchronous (start/stop), bit-synchronous, or octet-synchronous
185 mode, transparent to PPP Data Link Layer frames.
187 Interface Format
189 PPP presents an octet interface to the physical layer. There is
190 no provision for sub-octets to be supplied or accepted.
192 Transmission Rate
194 PPP does not impose any restrictions regarding transmission rate,
195 other than that of the particular DTE/DCE interface.
197 Control Signals
199 PPP does not require the use of control signals, such as Request
200 To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
201 Data Terminal Ready (DTR).
203 When available, using such signals can allow greater functionality
204 and performance. In particular, such signals SHOULD be used to
205 signal the Up and Down events in the LCP Option Negotiation
206 Automaton [1]. When such signals are not available, the
207 implementation MUST signal the Up event to LCP upon
208 initialization, and SHOULD NOT signal the Down event.
210 Because signalling is not required, the physical layer MAY be
211 decoupled from the data link layer, hiding the transient details
212 of the physical transport. This has implications for mobility in
213 cellular radio networks, and other rapidly switching links.
215 When moving from cell to cell within the same zone, an
216 implementation MAY choose to treat the entire zone as a single
217 link, even though transmission is switched among several
218 frequencies. The link is considered to be with the central
219 control unit for the zone, rather than the individual cell
220 transceivers. However, the link SHOULD re-establish its
221 configuration whenever the link is switched to a different
222 administration.
224 Due to the bursty nature of data traffic, some implementations
225 have choosen to disconnect the physical layer during periods of
229 Simpson [Page 3]
230 RFC 1662 HDLC-like Framing July 1994
233 inactivity, and reconnect when traffic resumes, without informing
234 the data link layer. Robust implementations should avoid using
235 this trick over-zealously, since the price for decreased setup
236 latency is decreased security. Implementations SHOULD signal the
237 Down event whenever "significant time" has elapsed since the link
238 was disconnected. The value for "significant time" is a matter of
239 considerable debate, and is based on the tariffs, call setup
240 times, and security concerns of the installation.
244 3. The Data Link Layer
246 PPP uses the principles described in ISO 3309-1979 HDLC frame
247 structure, most recently the fourth edition 3309:1991 [2], which
248 specifies modifications to allow HDLC use in asynchronous
249 environments.
251 The PPP control procedures use the Control field encodings described
252 in ISO 4335-1979 HDLC elements of procedures, most recently the
253 fourth edition 4335:1991 [4].
255 This should not be construed to indicate that every feature of the
256 above recommendations are included in PPP. Each feature included
257 is explicitly described in the following sections.
259 To remain consistent with standard Internet practice, and avoid
260 confusion for people used to reading RFCs, all binary numbers in the
261 following descriptions are in Most Significant Bit to Least
262 Significant Bit order, reading from left to right, unless otherwise
263 indicated. Note that this is contrary to standard ISO and CCITT
264 practice which orders bits as transmitted (network bit order). Keep
265 this in mind when comparing this document with the international
266 standards documents.
284 Simpson [Page 4]
285 RFC 1662 HDLC-like Framing July 1994
288 3.1. Frame Format
290 A summary of the PPP HDLC-like frame structure is shown below. This
291 figure does not include bits inserted for synchronization (such as
292 start and stop bits for asynchronous links), nor any bits or octets
293 inserted for transparency. The fields are transmitted from left to
294 right.
296 +----------+----------+----------+
297 | Flag | Address | Control |
298 | 01111110 | 11111111 | 00000011 |
299 +----------+----------+----------+
300 +----------+-------------+---------+
301 | Protocol | Information | Padding |
302 | 8/16 bits| * | * |
303 +----------+-------------+---------+
304 +----------+----------+-----------------
305 | FCS | Flag | Inter-frame Fill
306 |16/32 bits| 01111110 | or next Address
307 +----------+----------+-----------------
309 The Protocol, Information and Padding fields are described in the
310 Point-to-Point Protocol Encapsulation [1].
312 Flag Sequence
314 Each frame begins and ends with a Flag Sequence, which is the
315 binary sequence 01111110 (hexadecimal 0x7e). All implementations
316 continuously check for this flag, which is used for frame
317 synchronization.
319 Only one Flag Sequence is required between two frames. Two
320 consecutive Flag Sequences constitute an empty frame, which is
321 silently discarded, and not counted as a FCS error.
323 Address Field
325 The Address field is a single octet, which contains the binary
326 sequence 11111111 (hexadecimal 0xff), the All-Stations address.
327 Individual station addresses are not assigned. The All-Stations
328 address MUST always be recognized and received.
330 The use of other address lengths and values may be defined at a
331 later time, or by prior agreement. Frames with unrecognized
332 Addresses SHOULD be silently discarded.
339 Simpson [Page 5]
340 RFC 1662 HDLC-like Framing July 1994
343 Control Field
345 The Control field is a single octet, which contains the binary
346 sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
347 (UI) command with the Poll/Final (P/F) bit set to zero.
349 The use of other Control field values may be defined at a later
350 time, or by prior agreement. Frames with unrecognized Control
351 field values SHOULD be silently discarded.
353 Frame Check Sequence (FCS) Field
355 The Frame Check Sequence field defaults to 16 bits (two octets).
356 The FCS is transmitted least significant octet first, which
357 contains the coefficient of the highest term.
359 A 32-bit (four octet) FCS is also defined. Its use may be
360 negotiated as described in "PPP LCP Extensions" [5].
362 The use of other FCS lengths may be defined at a later time, or by
363 prior agreement.
365 The FCS field is calculated over all bits of the Address, Control,
366 Protocol, Information and Padding fields, not including any start
367 and stop bits (asynchronous) nor any bits (synchronous) or octets
368 (asynchronous or synchronous) inserted for transparency. This
369 also does not include the Flag Sequences nor the FCS field itself.
371 When octets are received which are flagged in the Async-
372 Control-Character-Map, they are discarded before calculating
373 the FCS.
375 For more information on the specification of the FCS, see the
376 Appendices.
378 The end of the Information and Padding fields is found by locating
379 the closing Flag Sequence and removing the Frame Check Sequence
380 field.
394 Simpson [Page 6]
395 RFC 1662 HDLC-like Framing July 1994
398 3.2. Modification of the Basic Frame
400 The Link Control Protocol can negotiate modifications to the standard
401 HDLC-like frame structure. However, modified frames will always be
402 clearly distinguishable from standard frames.
404 Address-and-Control-Field-Compression
406 When using the standard HDLC-like framing, the Address and Control
407 fields contain the hexadecimal values 0xff and 0x03 respectively.
408 When other Address or Control field values are in use, Address-
409 and-Control-Field-Compression MUST NOT be negotiated.
411 On transmission, compressed Address and Control fields are simply
412 omitted.
414 On reception, the Address and Control fields are decompressed by
415 examining the first two octets. If they contain the values 0xff
416 and 0x03, they are assumed to be the Address and Control fields.
417 If not, it is assumed that the fields were compressed and were not
418 transmitted.
420 By definition, the first octet of a two octet Protocol field
421 will never be 0xff (since it is not even). The Protocol field
422 value 0x00ff is not allowed (reserved) to avoid ambiguity when
423 Protocol-Field-Compression is enabled and the first Information
424 field octet is 0x03.
449 Simpson [Page 7]
450 RFC 1662 HDLC-like Framing July 1994
453 4. Octet-stuffed framing
455 This chapter summarizes the use of HDLC-like framing with 8-bit
456 asynchronous and octet-synchronous links.
460 4.1. Flag Sequence
462 The Flag Sequence indicates the beginning or end of a frame. The
463 octet stream is examined on an octet-by-octet basis for the value
464 01111110 (hexadecimal 0x7e).
468 4.2. Transparency
470 An octet stuffing procedure is used. The Control Escape octet is
471 defined as binary 01111101 (hexadecimal 0x7d), most significant bit
472 first.
474 As a minimum, sending implementations MUST escape the Flag Sequence
475 and Control Escape octets.
477 After FCS computation, the transmitter examines the entire frame
478 between the two Flag Sequences. Each Flag Sequence, Control Escape
479 octet, and any octet which is flagged in the sending Async-Control-
480 Character-Map (ACCM), is replaced by a two octet sequence consisting
481 of the Control Escape octet followed by the original octet
482 exclusive-or'd with hexadecimal 0x20.
484 This is bit 5 complemented, where the bit positions are numbered
485 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE
486 when comparing documents).
488 Receiving implementations MUST correctly process all Control Escape
489 sequences.
491 On reception, prior to FCS computation, each octet with value less
492 than hexadecimal 0x20 is checked. If it is flagged in the receiving
493 ACCM, it is simply removed (it may have been inserted by intervening
494 data communications equipment). Each Control Escape octet is also
495 removed, and the following octet is exclusive-or'd with hexadecimal
496 0x20, unless it is the Flag Sequence (which aborts a frame).
498 A few examples may make this more clear. Escaped data is transmitted
499 on the link as follows:
504 Simpson [Page 8]
505 RFC 1662 HDLC-like Framing July 1994
509 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence)
510 0x7d is encoded as 0x7d, 0x5d. (Control Escape)
511 0x03 is encoded as 0x7d, 0x23. (ETX)
513 Some modems with software flow control may intercept outgoing DC1 and
514 DC3 ignoring the 8th (parity) bit. This data would be transmitted on
515 the link as follows:
517 0x11 is encoded as 0x7d, 0x31. (XON)
518 0x13 is encoded as 0x7d, 0x33. (XOFF)
519 0x91 is encoded as 0x7d, 0xb1. (XON with parity set)
520 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set)
525 4.3. Invalid Frames
527 Frames which are too short (less than 4 octets when using the 16-bit
528 FCS), or which end with a Control Escape octet followed immediately
529 by a closing Flag Sequence, or in which octet-framing is violated (by
530 transmitting a "0" stop bit where a "1" bit is expected), are
531 silently discarded, and not counted as a FCS error.
535 4.4. Time Fill
537 4.4.1. Octet-synchronous
539 There is no provision for inter-octet time fill.
541 The Flag Sequence MUST be transmitted during inter-frame time fill.
544 4.4.2. Asynchronous
546 Inter-octet time fill MUST be accomplished by transmitting continuous
547 "1" bits (mark-hold state).
549 Inter-frame time fill can be viewed as extended inter-octet time
550 fill. Doing so can save one octet for every frame, decreasing delay
551 and increasing bandwidth. This is possible since a Flag Sequence may
552 serve as both a frame end and a frame begin. After having received
553 any frame, an idle receiver will always be in a frame begin state.
558 Simpson [Page 9]
559 RFC 1662 HDLC-like Framing July 1994
562 Robust transmitters should avoid using this trick over-zealously,
563 since the price for decreased delay is decreased reliability. Noisy
564 links may cause the receiver to receive garbage characters and
565 interpret them as part of an incoming frame. If the transmitter does
566 not send a new opening Flag Sequence before sending the next frame,
567 then that frame will be appended to the noise characters causing an
568 invalid frame (with high reliability).
570 It is suggested that implementations will achieve the best results by
571 always sending an opening Flag Sequence if the new frame is not
572 back-to-back with the last. Transmitters SHOULD send an open Flag
573 Sequence whenever "appreciable time" has elapsed after the prior
574 closing Flag Sequence. The maximum value for "appreciable time" is
575 likely to be no greater than the typing rate of a slow typist, about
576 1 second.
580 4.5. Transmission Considerations
582 4.5.1. Octet-synchronous
584 The definition of various encodings and scrambling is the
585 responsibility of the DTE/DCE equipment in use, and is outside the
586 scope of this specification.
589 4.5.2. Asynchronous
591 All octets are transmitted least significant bit first, with one
592 start bit, eight bits of data, and one stop bit. There is no
593 provision for seven bit asynchronous links.
612 Simpson [Page 10]
613 RFC 1662 HDLC-like Framing July 1994
616 5. Bit-stuffed framing
618 This chapter summarizes the use of HDLC-like framing with bit-
619 synchronous links.
623 5.1. Flag Sequence
625 The Flag Sequence indicates the beginning or end of a frame, and is
626 used for frame synchronization. The bit stream is examined on a
627 bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e).
629 The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be
630 used. When not avoidable, such an implementation MUST ensure that
631 the first Flag Sequence detected (the end of the frame) is promptly
632 communicated to the link layer. Use of the shared zero mode hinders
633 interoperability with bit-synchronous to asynchronous and bit-
634 synchronous to octet-synchronous converters.
638 5.2. Transparency
640 After FCS computation, the transmitter examines the entire frame
641 between the two Flag Sequences. A "0" bit is inserted after all
642 sequences of five contiguous "1" bits (including the last 5 bits of
643 the FCS) to ensure that a Flag Sequence is not simulated.
645 On reception, prior to FCS computation, any "0" bit that directly
646 follows five contiguous "1" bits is discarded.
650 5.3. Invalid Frames
652 Frames which are too short (less than 4 octets when using the 16-bit
653 FCS), or which end with a sequence of more than six "1" bits, are
654 silently discarded, and not counted as a FCS error.
658 5.4. Time Fill
660 There is no provision for inter-octet time fill.
662 The Flag Sequence SHOULD be transmitted during inter-frame time fill.
663 However, certain types of circuit-switched links require the use of
667 Simpson [Page 11]
668 RFC 1662 HDLC-like Framing July 1994
671 mark idle (continuous ones), particularly those that calculate
672 accounting based on periods of bit activity. When mark idle is used
673 on a bit-synchronous link, the implementation MUST ensure at least 15
674 consecutive "1" bits between Flags during the idle period, and that
675 the Flag Sequence is always generated at the beginning of a frame
676 after an idle period.
678 This differs from practice in ISO 3309, which allows 7 to 14 bit
679 mark idle.
683 5.5. Transmission Considerations
685 All octets are transmitted least significant bit first.
687 The definition of various encodings and scrambling is the
688 responsibility of the DTE/DCE equipment in use, and is outside the
689 scope of this specification.
691 While PPP will operate without regard to the underlying
692 representation of the bit stream, lack of standards for transmission
693 will hinder interoperability as surely as lack of data link
694 standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently
695 most widely available, and on that basis is recommended as a default.
697 When configuration of the encoding is allowed, NRZI is recommended as
698 an alternative, because of its relative immunity to signal inversion
699 configuration errors, and instances when it MAY allow connection
700 without an expensive DSU/CSU. Unfortunately, NRZI encoding
701 exacerbates the missing x1 factor of the 16-bit FCS, so that one
702 error in 2**15 goes undetected (instead of one in 2**16), and triple
703 errors are not detected. Therefore, when NRZI is in use, it is
704 recommended that the 32-bit FCS be negotiated, which includes the x1
705 factor.
707 At higher speeds of up to 45 Mbps, some implementors have chosen the
708 ANSI High Speed Synchronous Interface [HSSI]. While this experience
709 is currently limited, implementors are encouraged to cooperate in
710 choosing transmission encoding.
722 Simpson [Page 12]
723 RFC 1662 HDLC-like Framing July 1994
726 6. Asynchronous to Synchronous Conversion
728 There may be some use of asynchronous-to-synchronous converters (some
729 built into modems and cellular interfaces), resulting in an
730 asynchronous PPP implementation on one end of a link and a
731 synchronous implementation on the other. It is the responsibility of
732 the converter to do all stuffing conversions during operation.
734 To enable this functionality, synchronous PPP implementations MUST
735 always respond to the Async-Control-Character-Map Configuration
736 Option with the LCP Configure-Ack. However, acceptance of the
737 Configuration Option does not imply that the synchronous
738 implementation will do any ACCM mapping. Instead, all such octet
739 mapping will be performed by the asynchronous-to-synchronous
740 converter.
777 Simpson [Page 13]
778 RFC 1662 HDLC-like Framing July 1994
781 7. Additional LCP Configuration Options
783 The Configuration Option format and basic options are already defined
784 for LCP [1].
786 Up-to-date values of the LCP Option Type field are specified in the
787 most recent "Assigned Numbers" RFC [10]. This document concerns the
788 following values:
790 2 Async-Control-Character-Map
795 7.1. Async-Control-Character-Map (ACCM)
797 Description
799 This Configuration Option provides a method to negotiate the use
800 of control character transparency on asynchronous links.
802 Each end of the asynchronous link maintains two Async-Control-
803 Character-Maps. The receiving ACCM is 32 bits, but the sending
804 ACCM may be up to 256 bits. This results in four distinct ACCMs,
805 two in each direction of the link.
807 For asynchronous links, the default receiving ACCM is 0xffffffff.
808 The default sending ACCM is 0xffffffff, plus the Control Escape
809 and Flag Sequence characters themselves, plus whatever other
810 outgoing characters are flagged (by prior configuration) as likely
811 to be intercepted.
813 For other types of links, the default value is 0, since there is
814 no need for mapping.
816 The default inclusion of all octets less than hexadecimal 0x20
817 allows all ASCII control characters [6] excluding DEL (Delete)
818 to be transparently communicated through all known data
819 communications equipment.
821 The transmitter MAY also send octets with values in the range 0x40
822 through 0xff (except 0x5e) in Control Escape format. Since these
823 octet values are not negotiable, this does not solve the problem
824 of receivers which cannot handle all non-control characters.
825 Also, since the technique does not affect the 8th bit, this does
826 not solve problems for communications links that can send only 7-
827 bit characters.
832 Simpson [Page 14]
833 RFC 1662 HDLC-like Framing July 1994
836 Note that this specification differs in detail from later
837 amendments, such as 3309:1991/Amendment 2 [3]. However, such
838 "extended transparency" is applied only by "prior agreement".
839 Use of the transparency methods in this specification
840 constitute a prior agreement with respect to PPP.
842 For compatibility with 3309:1991/Amendment 2, the transmitter
843 MAY escape DEL and ACCM equivalents with the 8th (most
844 significant) bit set. No change is required in the receiving
845 algorithm.
847 Following ACCM negotiation, the transmitter SHOULD cease
848 escaping DEL.
850 However, it is rarely necessary to map all control characters, and
851 often it is unnecessary to map any control characters. The
852 Configuration Option is used to inform the peer which control
853 characters MUST remain mapped when the peer sends them.
855 The peer MAY still send any other octets in mapped format, if it
856 is necessary because of constraints known to the peer. The peer
857 SHOULD Configure-Nak with the logical union of the sets of mapped
858 octets, so that when such octets are spuriously introduced they
859 can be ignored on receipt.
861 A summary of the Async-Control-Character-Map Configuration Option
862 format is shown below. The fields are transmitted from left to
863 right.
865 0 1 2 3
866 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
867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
868 | Type | Length | ACCM
869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
870 ACCM (cont) |
871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
874 Type
876 2
878 Length
880 6
887 Simpson [Page 15]
888 RFC 1662 HDLC-like Framing July 1994
891 ACCM
893 The ACCM field is four octets, and indicates the set of control
894 characters to be mapped. The map is sent most significant octet
895 first.
897 Each numbered bit corresponds to the octet of the same value. If
898 the bit is cleared to zero, then that octet need not be mapped.
899 If the bit is set to one, then that octet MUST remain mapped. For
900 example, if bit 19 is set to zero, then the ASCII control
901 character 19 (DC3, Control-S) MAY be sent in the clear.
903 Note: The least significant bit of the least significant octet
904 (the final octet transmitted) is numbered bit 0, and would map
905 to the ASCII control character NUL.
942 Simpson [Page 16]
943 RFC 1662 HDLC-like Framing July 1994
946 A. Recommended LCP Options
948 The following Configurations Options are recommended:
950 High Speed links
952 Magic Number
953 Link Quality Monitoring
954 No Address and Control Field Compression
955 No Protocol Field Compression
958 Low Speed or Asynchronous links
960 Async Control Character Map
961 Magic Number
962 Address and Control Field Compression
963 Protocol Field Compression
967 B. Automatic Recognition of PPP Frames
969 It is sometimes desirable to detect PPP frames, for example during a
970 login sequence. The following octet sequences all begin valid PPP
971 LCP frames:
973 7e ff 03 c0 21
974 7e ff 7d 23 c0 21
975 7e 7d df 7d 23 c0 21
977 Note that the first two forms are not a valid username for Unix.
978 However, only the third form generates a correctly checksummed PPP
979 frame, whenever 03 and ff are taken as the control characters ETX and
980 DEL without regard to parity (they are correct for an even parity
981 link) and discarded.
983 Many implementations deal with this by putting the interface into
984 packet mode when one of the above username patterns are detected
985 during login, without examining the initial PPP checksum. The
986 initial incoming PPP frame is discarded, but a Configure-Request is
987 sent immediately.
997 Simpson [Page 17]
998 RFC 1662 HDLC-like Framing July 1994
1001 C. Fast Frame Check Sequence (FCS) Implementation
1003 The FCS was originally designed with hardware implementations in
1004 mind. A serial bit stream is transmitted on the wire, the FCS is
1005 calculated over the serial data as it goes out, and the complement of
1006 the resulting FCS is appended to the serial stream, followed by the
1007 Flag Sequence.
1009 The receiver has no way of determining that it has finished
1010 calculating the received FCS until it detects the Flag Sequence.
1011 Therefore, the FCS was designed so that a particular pattern results
1012 when the FCS operation passes over the complemented FCS. A good
1013 frame is indicated by this "good FCS" value.
1017 C.1. FCS table generator
1019 The following code creates the lookup table used to calculate the
1020 FCS-16.
1022 /*
1023 * Generate a FCS-16 table.
1024 *
1025 * Drew D. Perkins at Carnegie Mellon University.
1026 *
1027 * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
1028 */
1030 /*
1031 * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16.
1032 */
1033 #define P 0x8408
1036 main()
1037 {
1038 register unsigned int b, v;
1039 register int i;
1041 printf("typedef unsigned short u16;\n");
1042 printf("static u16 fcstab[256] = {");
1043 for (b = 0; ; ) {
1044 if (b % 8 == 0)
1045 printf("\n");
1047 v = b;
1048 for (i = 8; i--; )
1052 Simpson [Page 18]
1053 RFC 1662 HDLC-like Framing July 1994
1056 v = v & 1 ? (v >> 1) ^ P : v >> 1;
1058 printf("\t0x%04x", v & 0xFFFF);
1059 if (++b == 256)
1060 break;
1061 printf(",");
1062 }
1063 printf("\n};\n");
1064 }
1068 C.2. 16-bit FCS Computation Method
1070 The following code provides a table lookup computation for
1071 calculating the Frame Check Sequence as data arrives at the
1072 interface. This implementation is based on [7], [8], and [9].
1074 /*
1075 * u16 represents an unsigned 16-bit number. Adjust the typedef for
1076 * your hardware.
1077 */
1078 typedef unsigned short u16;
1080 /*
1081 * FCS lookup table as calculated by the table generator.
1082 */
1083 static u16 fcstab[256] = {
1084 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
1085 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
1086 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
1087 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
1088 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
1089 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
1090 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
1091 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
1092 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
1093 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
1094 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
1095 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
1096 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
1097 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
1098 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
1099 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
1100 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
1101 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
1102 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
1103 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
1107 Simpson [Page 19]
1108 RFC 1662 HDLC-like Framing July 1994
1111 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
1112 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
1113 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
1114 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
1115 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
1116 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
1117 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
1118 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
1119 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
1120 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
1121 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
1122 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
1123 };
1125 #define PPPINITFCS16 0xffff /* Initial FCS value */
1126 #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */
1128 /*
1129 * Calculate a new fcs given the current fcs and the new data.
1130 */
1131 u16 pppfcs16(fcs, cp, len)
1132 register u16 fcs;
1133 register unsigned char *cp;
1134 register int len;
1135 {
1136 ASSERT(sizeof (u16) == 2);
1137 ASSERT(((u16) -1) > 0);
1138 while (len--)
1139 fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
1141 return (fcs);
1142 }
1144 /*
1145 * How to use the fcs
1146 */
1147 tryfcs16(cp, len)
1148 register unsigned char *cp;
1149 register int len;
1150 {
1151 u16 trialfcs;
1153 /* add on output */
1154 trialfcs = pppfcs16( PPPINITFCS16, cp, len );
1155 trialfcs ^= 0xffff; /* complement */
1156 cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
1157 cp[len+1] = ((trialfcs >> 8) & 0x00ff);
1162 Simpson [Page 20]
1163 RFC 1662 HDLC-like Framing July 1994
1166 /* check on input */
1167 trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 );
1168 if ( trialfcs == PPPGOODFCS16 )
1169 printf("Good FCS\n");
1170 }
1174 C.3. 32-bit FCS Computation Method
1176 The following code provides a table lookup computation for
1177 calculating the 32-bit Frame Check Sequence as data arrives at the
1178 interface.
1180 /*
1181 * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5
1182 * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16
1183 * + x**22 + x**23 + x**26 + x**32.
1184 */
1186 /*
1187 * u32 represents an unsigned 32-bit number. Adjust the typedef for
1188 * your hardware.
1189 */
1190 typedef unsigned long u32;
1192 static u32 fcstab_32[256] =
1193 {
1194 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
1195 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
1196 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
1197 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
1198 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
1199 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
1200 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
1201 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
1202 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
1203 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
1204 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
1205 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
1206 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
1207 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
1208 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
1209 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
1210 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
1211 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
1212 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
1213 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
1217 Simpson [Page 21]
1218 RFC 1662 HDLC-like Framing July 1994
1221 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
1222 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
1223 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
1224 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
1225 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
1226 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
1227 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
1228 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
1229 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
1230 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
1231 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
1232 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
1233 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
1234 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
1235 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
1236 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
1237 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
1238 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
1239 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
1240 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
1241 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
1242 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
1243 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
1244 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
1245 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
1246 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
1247 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
1248 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
1249 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
1250 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
1251 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
1252 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
1253 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
1254 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
1255 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
1256 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
1257 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
1258 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
1259 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
1260 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
1261 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
1262 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
1263 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
1264 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
1265 };
1267 #define PPPINITFCS32 0xffffffff /* Initial FCS value */
1268 #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */
1272 Simpson [Page 22]
1273 RFC 1662 HDLC-like Framing July 1994
1276 /*
1277 * Calculate a new FCS given the current FCS and the new data.
1278 */
1279 u32 pppfcs32(fcs, cp, len)
1280 register u32 fcs;
1281 register unsigned char *cp;
1282 register int len;
1283 {
1284 ASSERT(sizeof (u32) == 4);
1285 ASSERT(((u32) -1) > 0);
1286 while (len--)
1287 fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
1289 return (fcs);
1290 }
1292 /*
1293 * How to use the fcs
1294 */
1295 tryfcs32(cp, len)
1296 register unsigned char *cp;
1297 register int len;
1298 {
1299 u32 trialfcs;
1301 /* add on output */
1302 trialfcs = pppfcs32( PPPINITFCS32, cp, len );
1303 trialfcs ^= 0xffffffff; /* complement */
1304 cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
1305 cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
1306 cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
1307 cp[len+3] = ((trialfcs >> 8) & 0x00ff);
1309 /* check on input */
1310 trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
1311 if ( trialfcs == PPPGOODFCS32 )
1312 printf("Good FCS\n");
1313 }
1327 Simpson [Page 23]
1328 RFC 1662 HDLC-like Framing July 1994
1331 Security Considerations
1333 As noted in the Physical Layer Requirements section, the link layer
1334 might not be informed when the connected state of the physical layer
1335 has changed. This results in possible security lapses due to over-
1336 reliance on the integrity and security of switching systems and
1337 administrations. An insertion attack might be undetected. An
1338 attacker which is able to spoof the same calling identity might be
1339 able to avoid link authentication.
1343 References
1345 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
1346 STD 50, RFC 1661, Daydreamer, July 1994.
1348 [2] ISO/IEC 3309:1991(E), "Information Technology -
1349 Telecommunications and information exchange between systems -
1350 High-level data link control (HDLC) procedures - Frame
1351 structure", International Organization For Standardization,
1352 Fourth edition 1991-06-01.
1354 [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology -
1355 Telecommunications and information exchange between systems -
1356 High-level data link control (HDLC) procedures - Frame
1357 structure - Amendment 2: Extended transparency options for
1358 start/stop transmission", International Organization For
1359 Standardization, 1992-01-15.
1361 [4] ISO/IEC 4335:1991(E), "Information Technology -
1362 Telecommunications and information exchange between systems -
1363 High-level data link control (HDLC) procedures - Elements of
1364 procedures", International Organization For Standardization,
1365 Fourth edition 1991-09-15.
1367 [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
1368 Daydreamer, January 1994.
1370 [6] ANSI X3.4-1977, "American National Standard Code for
1371 Information Interchange", American National Standards
1372 Institute, 1977.
1374 [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983.
1376 [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
1377 September 1986.
1382 Simpson [Page 24]
1383 RFC 1662 HDLC-like Framing July 1994
1386 [9] LeVan, J., "A Fast CRC", Byte, November 1987.
1388 [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1389 1340, USC/Information Sciences Institute, July 1992.
1393 Acknowledgements
1395 This document is the product of the Point-to-Point Protocol Working
1396 Group of the Internet Engineering Task Force (IETF). Comments should
1397 be submitted to the ietf-ppp@merit.edu mailing list.
1399 This specification is based on previous RFCs, where many
1400 contributions have been acknowleged.
1402 The 32-bit FCS example code was provided by Karl Fox (Morning Star
1403 Technologies).
1405 Special thanks to Morning Star Technologies for providing computing
1406 resources and network access support for writing this specification.
1410 Chair's Address
1412 The working group can be contacted via the current chair:
1414 Fred Baker
1415 Advanced Computer Communications
1416 315 Bollay Drive
1417 Santa Barbara, California 93117
1419 fbaker@acc.com
1422 Editor's Address
1424 Questions about this memo can also be directed to:
1426 William Allen Simpson
1427 Daydreamer
1428 Computer Systems Consulting Services
1429 1384 Fontaine
1430 Madison Heights, Michigan 48071
1432 Bill.Simpson@um.cc.umich.edu
1433 bsimpson@MorningStar.com
1436 Simpson [Page 25]