GLOSSARY OF TERMS (Note: slightly different from normal internet terminology) datagram: A unit of data for a protocol, complete with header information duplex, full: (communications lines) which can simultaneously send and recieve data eaten: discarded; ignored; destroyed. framing: Prepending and/or appending specific extra data to a packet HDLC: 'framing' technique used for PPP encapsulations (High level Data Link Control) header: extra information specicifying details about a packet IP: Internet Protocol, layered onto PPP layering (,protocol): When one protocol is used to 'carry' another protocols datagrams. The lower layer carries higher layer protocols. packet: generally synonomous with datagram PPP: Point to point protocol (see introduction) PPP encapsulation: One PPP 'unit' of data (the data portion of a PPP packet) SLIP: Another protocol similar to PPP TCP: Transport Control Protocol, layered onto IP ----------------------------------------------------------------------------- INTRODUCTION & ENCAPSULATION PPP is a method of transferring data between two locations. Packets are delivered in the order in which they are sent. It stands for 'Point to Point Protocol', and is commonly used for internet connections along with SLIP. The purpose of PPP is to ensure that no erroneous data is recieved. It provides: -A method of encapsulating other protocol datagrams (IP or TCP datagrams for an internet connection), possibly fragmenting these. -A Link Control Protocol (LCP) to establish, configure and test the connection -Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. For the internet, the IP network-layer is used. A PPP implementation need not support all NCPs. PPP packets are themselves encapsulated in 'HDLC' frames (see below). When used with HDLC, the requirements for PPP are an 8-bit, no parity, or bit- oriented or byte oriented communications channel, which must be full duplex. This entire document is concerned only with asynchronous communications channels (byte oriented) such as those found on the PC. PPP encapsulation: Protocol, Information, Padding Protocol: 8 or 16 bits (8 bits only allowed if header compression established; LSB of preceding byte (if present) is 0, last byte LSB is 1). Protocols in the range 0xxx - 3xxx specify the network layer protocol of the packet, 8xxxx - Bxxxx specify NCP packets. 4xxx - 7xxx: protocols with 'low traffic volume', no assoc. NCPs Cxxx - Fxxx: LCP packet (but keep reading) 0021 - Internet Protocol 8021 - Internet Protocol Control Protocol (NCP for IP) C021 - Link control protocol (LCP) Information: Is the actual data (for the given protocol). By default may not exceed the MRU, which is 1500 unless negotiated otherwise by LCP. The MRU also includes padding amount. *NOTE MULTI-BYTE VALUES ARE SENT MSB FIRST* ---------------------------------------------------------------------------- PPP SESSIONS Here is the basic order of precedings in a PPP session. If an unexpected (invalid) packet is recieved during any of the stages below, it should be eaten. Connection: LCP packets are sent to configure and test the data link. - Link is dead. - Link Establishment occurs - LCP Configure Request and Ack packet is sent/recieved AND - LCP Ack is sent in response to a recieved Reqeust Peer MAY be authenticated using LCP (if specified during Link Establishment) - if an LCP Configure-Request occurs, pass back to Link Est. phase - Link quality determination may take place concurrently - using a protocol chosen in the configuration (connection) phase (quality determination not covered in this manuscript). - If authentication fails, or Termination request is made, proceed to termination phase NCP packets are sent to choose and configure one or more Network layer protocols. - if an LCP Configure-Request occurs, pass back to Link Est. phase - Each NCP type may be opened/closed at any time - LCP, NCP and network layer protocol packets may be transferred (network layer protocol packets being packets which are of a protocol opened for use using a corresponding NCP - eg IP packets) - Unsupported protocols cause a protocol-reject packet. Supported packets on unopened network protocols are eaten. - Termination requests may be made/recieved. Termination: LCP may close the connection. - LCP Terminate package sent/acknowledged (or recieved/acknowledged). Network Layer Protocols may still be open. - wait for peer to disconnect (or disconnect if peer requested). - Hardware hangup. ----------------------------------------------------------------------------- LCP packet formats link config/estab packets - always sent with 'default' transmittal options; others are sent with options established during connection phase. One LCP packet in a PPP encapsulation (in the 'Information' field). Encapsulation protocol is set to 0C021h. LCP format: Code - 1 byte Identifier - 1 byte Length - 2 bytes (of the LCP packet in excluding PPP encapsulation sections) Data ..... Code: Receipt of an unknown Code in an LCP packet must generate a Code-Reject packet. 1 - Configure-Request 2 - Configure-Ack 3 - Configure-Nack 4 - Configure-Reject 5 - Terminate-Request 6 - Terminate-Ack 7 - Code-Reject 8 - Protocol-Reject 9 - Echo-Request 10 - Echo-Reply 11 - Discard-Request Identifier: See respective packet info (below). Length: includes code, identifier, length & data fields. Data: depends on respective packet code. *NOTE* Configure-xxx packets use the following options in the data field: None can be listed more than once. Each option: BYTE type BYTE length x BYTES .... length: includes type, length and extra if exceeds information field length, eat the packet. type: 0 reserved 1 Maximum-Recieve-Unit (MRU) 2 Asynchronous-Control-Character-Map (for HDLC framing) 3 Authentification-Protocol 4 Quality-Protocol 5 Magic-Number 7 Protocol-Field-Compression 8 Address-and-Control-Field-Compression MRU: length 4; extra: WORD indicating the MRU capability at the request senders end (must be at least 1500) ACCM: Each end of the PPP connection maintains two ACCMs, one for sending and one for recieveing. The maps are usually bitmaps, with by default low 32 bits set, recieving bitmap 32 bits in size and sending bitmap 256 bits in size. The recieve map indicates which HDLC recieved characters should be discarded. The send map indicates which HDLC sent characters should be escaped, and should *also* include flag & control escape characters. length = 6, extra is four bytes containing the (lower) 32 bits of the peers send and recieve control code map. See HDLC documentation below for ref. Authentification: length >= 4; extra: WORD authent. proto. ; extradata C023: Password Authent. Proto. C223: Challenge Handshake Authent. Proto. More info not available. Quality: length >= 4; extra: WORD quality proto ; extradata C025: Link Quality report. More info not available. extradata depends on the selected protocol. Magic-Number: length = 6; extra: DWORD Magic number. The number is used in in certain LCP packet types (see descriptions below). A value of 0 is not valid must be NAK'd or rejected (eaten) if recieved. Proto. field compression: length = 2; specifies that PPP encapsulation protocol fields may be compressed to a single byte as described in the 'introduction & encapsulation' section. Address-and-Control-Field-Compression: length = 2; specifies that address and control fields in the data link layer (ie HDLC framing) may be compressed (by removing them - some compression!). LCP packets must never have either field compressed. Configure-Request: Used to open a link. An appropriate reply is expected. Identifier is set to an arbitrary value which should be changed upon either attempting to configure with different options or upon recieving an acknowledgement to a request. If a magic number is specified, and a Configure-Request with the same magic number is recieved, a Configure-Nak MUST be sent specifying a new magic number; if a Nak is then recieved with the same, a Config. Request is resent etc. until a Configure-Ack eventuates. Configure-Ack: Acknowledges a Configure-Request and opens the link. The data field returned is a copy of the data in the Configure-Request, as is the identifier field. Configure-Nak: Acknowledges a Configure-Request, specifying options with parameters that were unacceptable in the data field. Boolean options use the Configure- Reject reply instead. The options' parameters should be set to acceptable values (for options that are specified only once). Any additional options can be requested by appending them to the options. Identifier field corresponds to that of the recieved Configure-Request. Configure-Reject: Acknowledges a Configure-Request, tells that either some options were not recognizable or boolean options were not acceptable. Options field is filled with unacceptable options. Identifier field matches that of the recieved Configure-Request. Terminate-Request: Is sent to request a closing of the connection. They should be sent until a Terminate-Ack is recieved, the lower layer (hardware) indicates that it has gone down, or timeout occurs. Terminate-Ack must be sent on recieval. Data and Identifier fields are arbitrary; Identifier should be changed only if Data is changed. Terminate-Ack: Either acknowledges a Terminate-Request or indicates that the sender is in need of re-negotiation of options. Identifier field is as was recieved in Terminate-Request (or arbitrary if Terminate-Request was not recieved); Data is arbitrary. Code-Reject: Indicates that an LCP packet with unrecognized code value was recieved. Identifier must change with *every* Code-Reject sent including re-sends. Data field should contain unrecognized packet's information field onwards. (May need be truncated). Connection is expected to terminate. Protocol-Reject: Indicates a packet with unrecognized protocol was recieved. Should only be sent/recieved if a connection has been established. Data field contains (WORD) protocol and x bytes rejected information (copy of packet from information field on; may need to be truncated). Echo-Request: Requests that information be looped back to the sender for testing purposes. Should only be sent/recieved if a connection has been established. The identifier field is changed if data field changes or an acknowledgement is recieved. Data field: 4 byte magic number + extra data. Magic number must be 0 unless Magic number option has been configured. Extra data is arbitrary. Expects an Echo-Reply. Echo-Reply: Acknowledges an Echo-Request. Identifier field is copied from recieved Echo-Request. Data field as for Echo-Request. Discard-Request: Used for testing. Eaten by reciever. Data field contains 4 BYTE magic number (0 unless magic number option configured) and extra data which is arbitrary. ----------------------------------------------------------------------------- HDLC framing HDLC provides a method of framing PPP datagrams, including indicating the beginning and end of the packets, providing error checking, and providing an escape mechanism to transmit control characters (eg flow control characters). By default, Control Characters constitute all values below 32 decimal, and the values of 7D and 7E hexadecimal have special meaning within HDLC and so are escaped before sending, or interpreted accordingly when recieved - other control characters are ignored when recieved. Each end of the connection maintains two Control Code Maps (called ACCMs) which specify which characters must be escaped when sent and ignored when recieved. The maps are identical, so may really be stored as one, however the sending map may be extended to contain further values (possibly this method can be used to transmit 7D and 7E characters escaped automatically) - this is by no means mandatory. Frame format: Flag( byte = 01111110b), Address( byte = 11111111b), Control( byte = 011b ), (data area - in which the packet being framed is placed), FCS (checksum, either 16/32 bits - 16 by default). All frames are followed by another flag which *may* also indicate the beginning of a new frame. A full frame cannot always be assumed to be within any two flags. If such a situation occurs, the incomplete frame is eaten. 'Address' has a value meaning 'all stations'. As this is a single point-to-point link, 'all stations' constitutes a single recieving station. Frames with an unrecognized address are silently discarded. 'Control' also has a standard value whose meaning to the author is as yet unclear. *IF ADDRESS/CONTROL FIELD COMPRESSION HAS BEEN NEGOTITATED USING LCP, these two fields are omitted. LCP packets must have them present however. To decompress, they are examined for the correct (uncompressed) values; if these values are found, (address = 11111111b, Control = 011b) the frame is assumed to be uncompressed. No ambiguities with compressed/uncompressed frames should occur as the first byte of a PPP packet will never be 11111111b* The FCS is not actually a simple checksum (whereby all the bytes or words in the section of data are added together) but uses a specific algorithm. It encompasses the Address, Control, and Data fields. Control Characters are discarded before a reciever calculates the FCS for checking. The FCS is calculated from the actual data intended to be transmitted or recieved; escaped codes are decoded before FCS computation (by the reciever) or are encoded after FCS computation (by the sender). Control Escape character is used to flag that the next character is data and is not itself a control character (either a 'flag' or 'Control Escape' itself, or another Control Character). The value for these characters is 01111101b. The original value (after being flagged with the Control Escape) is logically XOR'd with 00100000. The FCS (Frame Check Sequence) is responsible for ensuring that the data within an HDLC frame is correct. If the data does not match the FCS, the entire frame should be eaten - this condition generally indicates an error or noise in the communications line. The FCS computation takes in every byte in the frame; a single inaccurate byte should result in a checksum error. A table with 256 entries is used in the calculation. The following pseudo- code shows how to generate the 16-bit FCS table: 8 bit b = 0; loop "b": 16 bit v = b; do this 8 times: if lowest bit of v is set: v is shifted right 1 bit and XOR'd with 0x8408 else v is shifted right 1 bit Table entry #(b) = v; increase b by 1; if b has wrapped to 0 ( = 256), break from loop b; end of loop b For the 32-bit FCS, v is 32 bits in width and is XOR'd with 0xEDB88320 instead of 0x8408. To use the table for the purpose of the checksum, note the following: - The checksum value is maintained as 16 bits (or 32 bits). - It has an initial value of 0xffff (or 0xffffffff). - If you run the complemented (xor'd with 0xffff or 0xffffffff) checksum itself through the procedure, the resulting checksum will be 0xF0B8 (or 0xDEBB20E3) if the data was good. The procedure is: Read the next byte (into b) Shift the current checksum right 8 bits xor the checksum with the table entry #((checksum XOR b) AND 0xFF) Loop back for next byte. ----------------------------------------------------------------------------- IPCP (NCP) Internet Protocol Control Protocol is the Network Control Protocol for IP over a PPP link. The IP protocol must be 'opened' using IPCP before it can be used. IPCP is very similar to PPPs own LCP (link control protocol). Exactly one IPCP packet is encapsulated in a PPP packet. Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used, other codes are not used. When establishment of the connection is made, exactly one IP packet is encoded in a PPP packet, ensuring that any correctly recieved IP packets are whole, and that starting and ending of IP packets is clearly marked. The IPCP Configuration options (used woth Configure-Request etc.) differ from the LCP options. The IPCP options are: 1 IP-addresses (outdated, not covered here) 2 IP-Compression-Protocol (not covered, default = no compression) 3 IP-address (supplants option 1) IP-address option: Determines the IP address of the sending end of the link. A process can use this option to determine its own IP address by requesting an IP (possibly of 0.0.0.0) and finding the correct IP in a returned Configure-Nak. The address of the peer can also be discovered or requested. Length is 6; option data is a 4-byte IP address. ----------------------------------------------------------------------------- References: STD2.TXT - Assigned Numbers standard (1996) STD51.TXT - (Network working group Standard 51) encompassing two RFCs. (1994) RFC1332 - Internet Protocol Control Protocol (1992) CRC - Omen Technology CRC documentation and source. (1986?)