diff options
Diffstat (limited to 'doc/rfc1662.txt')
| -rw-r--r-- | doc/rfc1662.txt | 1436 |
1 files changed, 0 insertions, 1436 deletions
diff --git a/doc/rfc1662.txt b/doc/rfc1662.txt deleted file mode 100644 index 5a5b214..0000000 --- a/doc/rfc1662.txt +++ /dev/null @@ -1,1436 +0,0 @@ - - - - - - - -Network Working Group W. Simpson, Editor -Request for Comments: 1662 Daydreamer -STD: 51 July 1994 -Obsoletes: 1549 -Category: Standards Track - - - PPP in HDLC-like Framing - - -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 HDLC-like framing for PPP - encapsulated packets. - - -Table of Contents - - - 1. Introduction .......................................... 1 - 1.1 Specification of Requirements ................... 2 - 1.2 Terminology ..................................... 2 - - 2. Physical Layer Requirements ........................... 3 - - 3. The Data Link Layer ................................... 4 - 3.1 Frame Format .................................... 5 - 3.2 Modification of the Basic Frame ................. 7 - - 4. Octet-stuffed framing ................................. 8 - 4.1 Flag Sequence ................................... 8 - 4.2 Transparency .................................... 8 - 4.3 Invalid Frames .................................. 9 - 4.4 Time Fill ....................................... 9 - 4.4.1 Octet-synchronous ............................... 9 - 4.4.2 Asynchronous .................................... 9 - 4.5 Transmission Considerations ..................... 10 - 4.5.1 Octet-synchronous ............................... 10 - 4.5.2 Asynchronous .................................... 10 - - -Simpson [Page i] -RFC 1662 HDLC-like Framing July 1994 - - - 5. Bit-stuffed framing ................................... 11 - 5.1 Flag Sequence ................................... 11 - 5.2 Transparency .................................... 11 - 5.3 Invalid Frames .................................. 11 - 5.4 Time Fill ....................................... 11 - 5.5 Transmission Considerations ..................... 12 - - 6. Asynchronous to Synchronous Conversion ................ 13 - - 7. Additional LCP Configuration Options .................. 14 - 7.1 Async-Control-Character-Map (ACCM) .............. 14 - - APPENDICES ................................................... 17 - A. Recommended LCP Options ............................... 17 - B. Automatic Recognition of PPP Frames ................... 17 - C. Fast Frame Check Sequence (FCS) Implementation ........ 18 - C.1 FCS table generator ............................. 18 - C.2 16-bit FCS Computation Method ................... 19 - C.3 32-bit FCS Computation Method ................... 21 - - SECURITY CONSIDERATIONS ...................................... 24 - REFERENCES ................................................... 24 - ACKNOWLEDGEMENTS ............................................. 25 - CHAIR'S ADDRESS .............................................. 25 - EDITOR'S ADDRESS ............................................. 25 - - - - -1. Introduction - - This specification provides for framing over both bit-oriented and - octet-oriented synchronous links, and asynchronous links with 8 bits - of data and no parity. These links MUST be full-duplex, but MAY be - either dedicated or circuit-switched. - - An escape mechanism is specified to allow control data such as - XON/XOFF to be transmitted transparently over the link, and to remove - spurious control data which may be injected into the link by - intervening hardware and software. - - Some protocols expect error free transmission, and either provide - error detection only on a conditional basis, or do not provide it at - all. PPP uses the HDLC Frame Check Sequence for error detection. - This is commonly available in hardware implementations, and a - software implementation is provided. - - - - - - -Simpson [Page 1] -RFC 1662 HDLC-like Framing July 1994 - - -1.1. Specification of Requirements - - In this document, several words are used to signify the requirements - of the specification. These words are often capitalized. - - MUST This word, or the adjective "required", means that the - definition is an absolute requirement of the specification. - - MUST NOT This phrase means that the definition is an absolute - prohibition of the specification. - - SHOULD This word, or the adjective "recommended", means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications must be - understood and carefully weighed before choosing a - different course. - - MAY This word, or the adjective "optional", means that this - item is one of an allowed set of alternatives. An - implementation which does not include this option MUST be - prepared to interoperate with another implementation which - does include the option. - - -1.2. Terminology - - This document frequently uses the following terms: - - datagram The unit of transmission in the network layer (such as IP). - A datagram may be encapsulated in one or more packets - passed to the data link layer. - - frame The unit of transmission at the data link layer. A frame - may include a header and/or a trailer, along with some - number of units of data. - - packet The basic unit of encapsulation, which is passed across the - interface between the network layer and the data link - layer. A packet is usually mapped to a frame; the - exceptions are when data link layer fragmentation is being - performed, or when multiple packets are incorporated into a - single frame. - - peer The other end of the point-to-point link. - - silently discard - The implementation discards the packet without further - processing. The implementation SHOULD provide the - capability of logging the error, including the contents of - the silently discarded packet, and SHOULD record the event - in a statistics counter. - - -Simpson [Page 2] -RFC 1662 HDLC-like Framing July 1994 - - -2. Physical Layer Requirements - - PPP is capable of operating across most DTE/DCE interfaces (such as, - EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute - requirement imposed by PPP is the provision of a full-duplex circuit, - either dedicated or circuit-switched, which can operate in either an - asynchronous (start/stop), bit-synchronous, or octet-synchronous - mode, transparent to PPP Data Link Layer frames. - - 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 DTE/DCE interface. - - Control Signals - - PPP does not require the use of control signals, such as Request - To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and - Data Terminal Ready (DTR). - - When available, using such signals can allow greater functionality - and performance. In particular, such signals SHOULD be used to - signal the Up and Down events in the LCP Option Negotiation - Automaton [1]. When such signals are not available, the - implementation MUST signal the Up event to LCP upon - initialization, and SHOULD NOT signal the Down event. - - Because signalling is not required, the physical layer MAY be - decoupled from the data link layer, hiding the transient details - of the physical transport. This has implications for mobility in - cellular radio networks, and other rapidly switching links. - - When moving from cell to cell within the same zone, an - implementation MAY choose to treat the entire zone as a single - link, even though transmission is switched among several - frequencies. The link is considered to be with the central - control unit for the zone, rather than the individual cell - transceivers. However, the link SHOULD re-establish its - configuration whenever the link is switched to a different - administration. - - Due to the bursty nature of data traffic, some implementations - have choosen to disconnect the physical layer during periods of - - - -Simpson [Page 3] -RFC 1662 HDLC-like Framing July 1994 - - - inactivity, and reconnect when traffic resumes, without informing - the data link layer. Robust implementations should avoid using - this trick over-zealously, since the price for decreased setup - latency is decreased security. Implementations SHOULD signal the - Down event whenever "significant time" has elapsed since the link - was disconnected. The value for "significant time" is a matter of - considerable debate, and is based on the tariffs, call setup - times, and security concerns of the installation. - - - -3. The Data Link Layer - - PPP uses the principles described in ISO 3309-1979 HDLC frame - structure, most recently the fourth edition 3309:1991 [2], which - specifies modifications to allow HDLC use in asynchronous - environments. - - The PPP control procedures use the Control field encodings described - in ISO 4335-1979 HDLC elements of procedures, most recently the - fourth edition 4335:1991 [4]. - - This should not be construed to indicate that every feature of the - above recommendations are included in PPP. Each feature included - is explicitly described in the following sections. - - To remain consistent with standard Internet practice, and avoid - confusion for people used to reading RFCs, all binary numbers in the - following descriptions are in Most Significant Bit to Least - Significant Bit order, reading from left to right, unless otherwise - indicated. Note that this is contrary to standard ISO and CCITT - practice which orders bits as transmitted (network bit order). Keep - this in mind when comparing this document with the international - standards documents. - - - - - - - - - - - - - - - - - -Simpson [Page 4] -RFC 1662 HDLC-like Framing July 1994 - - -3.1. Frame Format - - A summary of the PPP HDLC-like frame structure is shown below. This - figure does not include bits inserted for synchronization (such as - start and stop bits for asynchronous links), nor any bits or octets - inserted for transparency. The fields are transmitted from left to - right. - - +----------+----------+----------+ - | Flag | Address | Control | - | 01111110 | 11111111 | 00000011 | - +----------+----------+----------+ - +----------+-------------+---------+ - | Protocol | Information | Padding | - | 8/16 bits| * | * | - +----------+-------------+---------+ - +----------+----------+----------------- - | FCS | Flag | Inter-frame Fill - |16/32 bits| 01111110 | or next Address - +----------+----------+----------------- - - The Protocol, Information and Padding fields are described in the - Point-to-Point Protocol Encapsulation [1]. - - Flag Sequence - - Each frame begins and ends with a Flag Sequence, which is the - binary sequence 01111110 (hexadecimal 0x7e). All implementations - continuously check for this flag, which is used for frame - synchronization. - - Only one Flag Sequence is required between two frames. Two - consecutive Flag Sequences constitute an empty frame, which is - silently discarded, and not counted as a FCS error. - - Address Field - - The Address field is a single octet, which contains the binary - sequence 11111111 (hexadecimal 0xff), the All-Stations address. - Individual station addresses are not assigned. The All-Stations - address MUST always be recognized and received. - - The use of other address lengths and values may be defined at a - later time, or by prior agreement. Frames with unrecognized - Addresses SHOULD be silently discarded. - - - - - - -Simpson [Page 5] -RFC 1662 HDLC-like Framing July 1994 - - - Control Field - - The Control field is a single octet, which contains the binary - sequence 00000011 (hexadecimal 0x03), the Unnumbered Information - (UI) command with the Poll/Final (P/F) bit set to zero. - - The use of other Control field values may be defined at a later - time, or by prior agreement. Frames with unrecognized Control - field values SHOULD be silently discarded. - - Frame Check Sequence (FCS) Field - - The Frame Check Sequence field defaults to 16 bits (two octets). - The FCS is transmitted least significant octet first, which - contains the coefficient of the highest term. - - A 32-bit (four octet) FCS is also defined. Its use may be - negotiated as described in "PPP LCP Extensions" [5]. - - The use of other FCS lengths may be defined at a later time, or by - prior agreement. - - The FCS field is calculated over all bits of the Address, Control, - Protocol, Information and Padding fields, not including any start - and stop bits (asynchronous) nor any bits (synchronous) or octets - (asynchronous or synchronous) inserted for transparency. This - also does not include the Flag Sequences nor the FCS field itself. - - When octets are received which are flagged in the Async- - Control-Character-Map, they are discarded before calculating - the FCS. - - For more information on the specification of the FCS, see the - Appendices. - - The end of the Information and Padding fields is found by locating - the closing Flag Sequence and removing the Frame Check Sequence - field. - - - - - - - - - - - - - -Simpson [Page 6] -RFC 1662 HDLC-like Framing July 1994 - - -3.2. Modification of the Basic Frame - - The Link Control Protocol can negotiate modifications to the standard - HDLC-like frame structure. However, modified frames will always be - clearly distinguishable from standard frames. - - Address-and-Control-Field-Compression - - When using the standard HDLC-like framing, the Address and Control - fields contain the hexadecimal values 0xff and 0x03 respectively. - When other Address or Control field values are in use, Address- - and-Control-Field-Compression MUST NOT be negotiated. - - On transmission, compressed Address and Control fields are simply - omitted. - - On reception, the Address and Control fields are decompressed by - examining the first two octets. If they contain the values 0xff - and 0x03, they are assumed to be the Address and Control fields. - If not, it is assumed that the fields were compressed and were not - transmitted. - - By definition, the first octet of a two octet Protocol field - will never be 0xff (since it is not even). The Protocol field - value 0x00ff is not allowed (reserved) to avoid ambiguity when - Protocol-Field-Compression is enabled and the first Information - field octet is 0x03. - - - - - - - - - - - - - - - - - - - - - - - - -Simpson [Page 7] -RFC 1662 HDLC-like Framing July 1994 - - -4. Octet-stuffed framing - - This chapter summarizes the use of HDLC-like framing with 8-bit - asynchronous and octet-synchronous links. - - - -4.1. Flag Sequence - - The Flag Sequence indicates the beginning or end of a frame. The - octet stream is examined on an octet-by-octet basis for the value - 01111110 (hexadecimal 0x7e). - - - -4.2. Transparency - - An octet stuffing procedure is used. The Control Escape octet is - defined as binary 01111101 (hexadecimal 0x7d), most significant bit - first. - - As a minimum, sending implementations MUST escape the Flag Sequence - and Control Escape octets. - - After FCS computation, the transmitter examines the entire frame - between the two Flag Sequences. Each Flag Sequence, Control Escape - octet, and any octet which is flagged in the sending Async-Control- - Character-Map (ACCM), is replaced by a two octet sequence consisting - of the Control Escape octet followed by the original octet - exclusive-or'd with hexadecimal 0x20. - - This is bit 5 complemented, where the bit positions are numbered - 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE - when comparing documents). - - Receiving implementations MUST correctly process all Control Escape - sequences. - - On reception, prior to FCS computation, each octet with value less - than hexadecimal 0x20 is checked. If it is flagged in the receiving - ACCM, it is simply removed (it may have been inserted by intervening - data communications equipment). Each Control Escape octet is also - removed, and the following octet is exclusive-or'd with hexadecimal - 0x20, unless it is the Flag Sequence (which aborts a frame). - - A few examples may make this more clear. Escaped data is transmitted - on the link as follows: - - - - -Simpson [Page 8] -RFC 1662 HDLC-like Framing July 1994 - - - - 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence) - 0x7d is encoded as 0x7d, 0x5d. (Control Escape) - 0x03 is encoded as 0x7d, 0x23. (ETX) - - Some modems with software flow control may intercept outgoing DC1 and - DC3 ignoring the 8th (parity) bit. This data would be transmitted on - the link as follows: - - 0x11 is encoded as 0x7d, 0x31. (XON) - 0x13 is encoded as 0x7d, 0x33. (XOFF) - 0x91 is encoded as 0x7d, 0xb1. (XON with parity set) - 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set) - - - - -4.3. Invalid Frames - - Frames which are too short (less than 4 octets when using the 16-bit - FCS), or which end with a Control Escape octet followed immediately - by a closing Flag Sequence, or in which octet-framing is violated (by - transmitting a "0" stop bit where a "1" bit is expected), are - silently discarded, and not counted as a FCS error. - - - -4.4. Time Fill - -4.4.1. Octet-synchronous - - There is no provision for inter-octet time fill. - - The Flag Sequence MUST be transmitted during inter-frame time fill. - - -4.4.2. Asynchronous - - Inter-octet time fill MUST be accomplished by transmitting continuous - "1" bits (mark-hold state). - - Inter-frame time fill can be viewed as extended inter-octet time - fill. Doing so can save one octet for every frame, decreasing delay - and increasing bandwidth. This is possible since a Flag Sequence may - serve as both a frame end and a frame begin. After having received - any frame, an idle receiver will always be in a frame begin state. - - - - -Simpson [Page 9] -RFC 1662 HDLC-like Framing July 1994 - - - Robust transmitters should avoid using this trick over-zealously, - since the price for decreased delay is decreased reliability. Noisy - links may cause the receiver to receive garbage characters and - interpret them as part of an incoming frame. If the transmitter does - not send a new opening Flag Sequence before sending the next frame, - then that frame will be appended to the noise characters causing an - invalid frame (with high reliability). - - It is suggested that implementations will achieve the best results by - always sending an opening Flag Sequence if the new frame is not - back-to-back with the last. Transmitters SHOULD send an open Flag - Sequence whenever "appreciable time" has elapsed after the prior - closing Flag Sequence. The maximum value for "appreciable time" is - likely to be no greater than the typing rate of a slow typist, about - 1 second. - - - -4.5. Transmission Considerations - -4.5.1. Octet-synchronous - - The definition of various encodings and scrambling is the - responsibility of the DTE/DCE equipment in use, and is outside the - scope of this specification. - - -4.5.2. Asynchronous - - All octets are transmitted least significant bit first, with one - start bit, eight bits of data, and one stop bit. There is no - provision for seven bit asynchronous links. - - - - - - - - - - - - - - - - - - -Simpson [Page 10] -RFC 1662 HDLC-like Framing July 1994 - - -5. Bit-stuffed framing - - This chapter summarizes the use of HDLC-like framing with bit- - synchronous links. - - - -5.1. Flag Sequence - - The Flag Sequence indicates the beginning or end of a frame, and is - used for frame synchronization. The bit stream is examined on a - bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). - - The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be - used. When not avoidable, such an implementation MUST ensure that - the first Flag Sequence detected (the end of the frame) is promptly - communicated to the link layer. Use of the shared zero mode hinders - interoperability with bit-synchronous to asynchronous and bit- - synchronous to octet-synchronous converters. - - - -5.2. Transparency - - After FCS computation, the transmitter examines the entire frame - between the two Flag Sequences. A "0" bit is inserted after all - sequences of five contiguous "1" bits (including the last 5 bits of - the FCS) to ensure that a Flag Sequence is not simulated. - - On reception, prior to FCS computation, any "0" bit that directly - follows five contiguous "1" bits is discarded. - - - -5.3. Invalid Frames - - Frames which are too short (less than 4 octets when using the 16-bit - FCS), or which end with a sequence of more than six "1" bits, are - silently discarded, and not counted as a FCS error. - - - -5.4. Time Fill - - There is no provision for inter-octet time fill. - - The Flag Sequence SHOULD be transmitted during inter-frame time fill. - However, certain types of circuit-switched links require the use of - - - -Simpson [Page 11] -RFC 1662 HDLC-like Framing July 1994 - - - mark idle (continuous ones), particularly those that calculate - accounting based on periods of bit activity. When mark idle is used - on a bit-synchronous link, the implementation MUST ensure at least 15 - consecutive "1" bits between Flags during the idle period, and that - the Flag Sequence is always generated at the beginning of a frame - after an idle period. - - This differs from practice in ISO 3309, which allows 7 to 14 bit - mark idle. - - - -5.5. Transmission Considerations - - All octets are transmitted least significant bit first. - - The definition of various encodings and scrambling 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, lack of standards for transmission - will hinder interoperability as surely as lack of data link - standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently - most widely available, and on that basis is recommended as a default. - - When configuration of the encoding is allowed, NRZI is recommended as - an alternative, because of its relative immunity to signal inversion - configuration errors, and instances when it MAY allow connection - without an expensive DSU/CSU. Unfortunately, NRZI encoding - exacerbates the missing x1 factor of the 16-bit FCS, so that one - error in 2**15 goes undetected (instead of one in 2**16), and triple - errors are not detected. Therefore, when NRZI is in use, it is - recommended that the 32-bit FCS be negotiated, which includes the x1 - factor. - - At higher speeds of up to 45 Mbps, some implementors have chosen the - ANSI High Speed Synchronous Interface [HSSI]. While this experience - is currently limited, implementors are encouraged to cooperate in - choosing transmission encoding. - - - - - - - - - - - -Simpson [Page 12] -RFC 1662 HDLC-like Framing July 1994 - - -6. Asynchronous to Synchronous Conversion - - There may be some use of asynchronous-to-synchronous converters (some - built into modems and cellular interfaces), resulting in an - asynchronous PPP implementation on one end of a link and a - synchronous implementation on the other. It is the responsibility of - the converter to do all stuffing conversions during operation. - - To enable this functionality, synchronous PPP implementations MUST - always respond to the Async-Control-Character-Map Configuration - Option with the LCP Configure-Ack. However, acceptance of the - Configuration Option does not imply that the synchronous - implementation will do any ACCM mapping. Instead, all such octet - mapping will be performed by the asynchronous-to-synchronous - converter. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Simpson [Page 13] -RFC 1662 HDLC-like Framing July 1994 - - -7. Additional LCP Configuration Options - - The Configuration Option format and basic options are already defined - for LCP [1]. - - Up-to-date values of the LCP Option Type field are specified in the - most recent "Assigned Numbers" RFC [10]. This document concerns the - following values: - - 2 Async-Control-Character-Map - - - - -7.1. Async-Control-Character-Map (ACCM) - - Description - - This Configuration Option provides a method to negotiate the use - of control character transparency on asynchronous links. - - Each end of the asynchronous link maintains two Async-Control- - Character-Maps. The receiving ACCM is 32 bits, but the sending - ACCM may be up to 256 bits. This results in four distinct ACCMs, - two in each direction of the link. - - For asynchronous links, the default receiving ACCM is 0xffffffff. - The default sending ACCM is 0xffffffff, plus the Control Escape - and Flag Sequence characters themselves, plus whatever other - outgoing characters are flagged (by prior configuration) as likely - to be intercepted. - - For other types of links, the default value is 0, since there is - no need for mapping. - - The default inclusion of all octets less than hexadecimal 0x20 - allows all ASCII control characters [6] excluding DEL (Delete) - to be transparently communicated through all known data - communications equipment. - - The transmitter MAY also send octets with values in the range 0x40 - through 0xff (except 0x5e) in Control Escape format. Since these - octet values are not negotiable, this does not solve the problem - of receivers which cannot handle all non-control characters. - Also, since the technique does not affect the 8th bit, this does - not solve problems for communications links that can send only 7- - bit characters. - - - - -Simpson [Page 14] -RFC 1662 HDLC-like Framing July 1994 - - - Note that this specification differs in detail from later - amendments, such as 3309:1991/Amendment 2 [3]. However, such - "extended transparency" is applied only by "prior agreement". - Use of the transparency methods in this specification - constitute a prior agreement with respect to PPP. - - For compatibility with 3309:1991/Amendment 2, the transmitter - MAY escape DEL and ACCM equivalents with the 8th (most - significant) bit set. No change is required in the receiving - algorithm. - - Following ACCM negotiation, the transmitter SHOULD cease - escaping DEL. - - However, it is rarely necessary to map all control characters, and - often it is unnecessary to map any control characters. The - Configuration Option is used to inform the peer which control - characters MUST remain mapped when the peer sends them. - - The peer MAY still send any other octets in mapped format, if it - is necessary because of constraints known to the peer. The peer - SHOULD Configure-Nak with the logical union of the sets of mapped - octets, so that when such octets are spuriously introduced they - can be ignored on receipt. - - A summary of the Async-Control-Character-Map Configuration Option - format is shown below. 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | ACCM - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ACCM (cont) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Type - - 2 - - Length - - 6 - - - - - - -Simpson [Page 15] -RFC 1662 HDLC-like Framing July 1994 - - - ACCM - - The ACCM field is four octets, and indicates the set of control - characters to be mapped. The map is sent most significant octet - first. - - Each numbered bit corresponds to the octet of the same value. If - the bit is cleared to zero, then that octet need not be mapped. - If the bit is set to one, then that octet MUST remain mapped. For - example, if bit 19 is set to zero, then the ASCII control - character 19 (DC3, Control-S) MAY be sent in the clear. - - Note: The least significant bit of the least significant octet - (the final octet transmitted) is numbered bit 0, and would map - to the ASCII control character NUL. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Simpson [Page 16] -RFC 1662 HDLC-like Framing July 1994 - - -A. Recommended LCP Options - - The following Configurations Options are recommended: - - High Speed links - - Magic Number - Link Quality Monitoring - No Address and Control Field Compression - No Protocol Field Compression - - - Low Speed or Asynchronous links - - Async Control Character Map - Magic Number - Address and Control Field Compression - Protocol Field Compression - - - -B. Automatic Recognition of PPP Frames - - It is sometimes desirable to detect PPP frames, for example during a - login sequence. The following octet sequences all begin valid PPP - LCP frames: - - 7e ff 03 c0 21 - 7e ff 7d 23 c0 21 - 7e 7d df 7d 23 c0 21 - - Note that the first two forms are not a valid username for Unix. - However, only the third form generates a correctly checksummed PPP - frame, whenever 03 and ff are taken as the control characters ETX and - DEL without regard to parity (they are correct for an even parity - link) and discarded. - - Many implementations deal with this by putting the interface into - packet mode when one of the above username patterns are detected - during login, without examining the initial PPP checksum. The - initial incoming PPP frame is discarded, but a Configure-Request is - sent immediately. - - - - - - - - - -Simpson [Page 17] -RFC 1662 HDLC-like Framing July 1994 - - -C. Fast Frame Check Sequence (FCS) Implementation - - The FCS was originally designed with hardware implementations in - mind. A serial bit stream is transmitted on the wire, the FCS is - calculated over the serial data as it goes out, and the complement of - the resulting FCS is appended to the serial stream, followed by the - Flag Sequence. - - The receiver has no way of determining that it has finished - calculating the received FCS until it detects the Flag Sequence. - Therefore, the FCS was designed so that a particular pattern results - when the FCS operation passes over the complemented FCS. A good - frame is indicated by this "good FCS" value. - - - -C.1. FCS table generator - - The following code creates the lookup table used to calculate the - FCS-16. - - /* - * Generate a FCS-16 table. - * - * Drew D. Perkins at Carnegie Mellon University. - * - * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. - */ - - /* - * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16. - */ - #define P 0x8408 - - - main() - { - register unsigned int b, v; - register int i; - - printf("typedef unsigned short u16;\n"); - printf("static u16 fcstab[256] = {"); - for (b = 0; ; ) { - if (b % 8 == 0) - printf("\n"); - - v = b; - for (i = 8; i--; ) - - - -Simpson [Page 18] -RFC 1662 HDLC-like Framing July 1994 - - - v = v & 1 ? (v >> 1) ^ P : v >> 1; - - printf("\t0x%04x", v & 0xFFFF); - if (++b == 256) - break; - printf(","); - } - printf("\n};\n"); - } - - - -C.2. 16-bit FCS Computation Method - - The following code provides a table lookup computation for - calculating the Frame Check Sequence as data arrives at the - interface. This implementation is based on [7], [8], and [9]. - - /* - * u16 represents an unsigned 16-bit number. Adjust the typedef for - * your hardware. - */ - typedef unsigned short u16; - - /* - * FCS lookup table as calculated by the table generator. - */ - static u16 fcstab[256] = { - 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, - 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, - 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, - 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, - 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, - 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, - 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, - 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, - 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, - 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, - 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, - 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, - 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, - 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, - 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, - 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, - 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, - 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, - 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, - 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, - - - -Simpson [Page 19] -RFC 1662 HDLC-like Framing July 1994 - - - 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, - 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, - 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, - 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, - 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, - 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, - 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, - 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, - 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, - 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, - 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, - 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 - }; - - #define PPPINITFCS16 0xffff /* Initial FCS value */ - #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */ - - /* - * Calculate a new fcs given the current fcs and the new data. - */ - u16 pppfcs16(fcs, cp, len) - register u16 fcs; - register unsigned char *cp; - register int len; - { - ASSERT(sizeof (u16) == 2); - ASSERT(((u16) -1) > 0); - while (len--) - fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; - - return (fcs); - } - - /* - * How to use the fcs - */ - tryfcs16(cp, len) - register unsigned char *cp; - register int len; - { - u16 trialfcs; - - /* add on output */ - trialfcs = pppfcs16( PPPINITFCS16, cp, len ); - trialfcs ^= 0xffff; /* complement */ - cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ - cp[len+1] = ((trialfcs >> 8) & 0x00ff); - - - - -Simpson [Page 20] -RFC 1662 HDLC-like Framing July 1994 - - - /* check on input */ - trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); - if ( trialfcs == PPPGOODFCS16 ) - printf("Good FCS\n"); - } - - - -C.3. 32-bit FCS Computation Method - - The following code provides a table lookup computation for - calculating the 32-bit Frame Check Sequence as data arrives at the - interface. - - /* - * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5 - * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16 - * + x**22 + x**23 + x**26 + x**32. - */ - - /* - * u32 represents an unsigned 32-bit number. Adjust the typedef for - * your hardware. - */ - typedef unsigned long u32; - - static u32 fcstab_32[256] = - { - 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, - 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, - 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, - 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, - 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, - 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, - 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, - 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, - 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, - 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, - 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, - 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, - 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, - 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, - 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, - 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, - 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, - 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, - 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, - 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, - - - -Simpson [Page 21] -RFC 1662 HDLC-like Framing July 1994 - - - 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, - 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, - 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, - 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, - 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, - 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, - 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, - 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, - 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, - 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, - 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, - 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, - 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, - 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, - 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, - 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, - 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, - 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, - 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, - 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, - 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, - 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, - 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, - 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, - 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, - 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, - 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, - 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, - 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, - 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, - 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, - 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, - 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, - 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, - 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, - 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, - 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, - 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, - 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, - 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, - 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, - 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, - 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, - 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d - }; - - #define PPPINITFCS32 0xffffffff /* Initial FCS value */ - #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */ - - - -Simpson [Page 22] -RFC 1662 HDLC-like Framing July 1994 - - - /* - * Calculate a new FCS given the current FCS and the new data. - */ - u32 pppfcs32(fcs, cp, len) - register u32 fcs; - register unsigned char *cp; - register int len; - { - ASSERT(sizeof (u32) == 4); - ASSERT(((u32) -1) > 0); - while (len--) - fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); - - return (fcs); - } - - /* - * How to use the fcs - */ - tryfcs32(cp, len) - register unsigned char *cp; - register int len; - { - u32 trialfcs; - - /* add on output */ - trialfcs = pppfcs32( PPPINITFCS32, cp, len ); - trialfcs ^= 0xffffffff; /* complement */ - cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ - cp[len+1] = ((trialfcs >>= 8) & 0x00ff); - cp[len+2] = ((trialfcs >>= 8) & 0x00ff); - cp[len+3] = ((trialfcs >> 8) & 0x00ff); - - /* check on input */ - trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); - if ( trialfcs == PPPGOODFCS32 ) - printf("Good FCS\n"); - } - - - - - - - - - - - - - -Simpson [Page 23] -RFC 1662 HDLC-like Framing July 1994 - - -Security Considerations - - As noted in the Physical Layer Requirements section, the link layer - might not be informed when the connected state of the physical layer - has changed. 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)", - STD 50, RFC 1661, Daydreamer, July 1994. - - [2] ISO/IEC 3309:1991(E), "Information Technology - - Telecommunications and information exchange between systems - - High-level data link control (HDLC) procedures - Frame - structure", International Organization For Standardization, - Fourth edition 1991-06-01. - - [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology - - Telecommunications and information exchange between systems - - High-level data link control (HDLC) procedures - Frame - structure - Amendment 2: Extended transparency options for - start/stop transmission", International Organization For - Standardization, 1992-01-15. - - [4] ISO/IEC 4335:1991(E), "Information Technology - - Telecommunications and information exchange between systems - - High-level data link control (HDLC) procedures - Elements of - procedures", International Organization For Standardization, - Fourth edition 1991-09-15. - - [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, - Daydreamer, January 1994. - - [6] ANSI X3.4-1977, "American National Standard Code for - Information Interchange", American National Standards - Institute, 1977. - - [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. - - [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, - September 1986. - - - - -Simpson [Page 24] -RFC 1662 HDLC-like Framing July 1994 - - - [9] LeVan, J., "A Fast CRC", Byte, November 1987. - - [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC - 1340, USC/Information Sciences Institute, July 1992. - - - -Acknowledgements - - 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. - - This specification is based on previous RFCs, where many - contributions have been acknowleged. - - The 32-bit FCS example code was provided by Karl Fox (Morning Star - Technologies). - - Special thanks to Morning Star Technologies for providing computing - resources and network access support for writing this specification. - - - -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 - - fbaker@acc.com - - -Editor'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 - - Bill.Simpson@um.cc.umich.edu - bsimpson@MorningStar.com - - -Simpson [Page 25] |