+(e.g., DECnet, OSI, Appletalk). RFCs are available by anonymous FTP
+from several sites including nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
+ftp.nisc.sri.com, and munnari.oz.au.
+
+@node PPP packet format, LCP negotiation, PPP Concepts, Introduction
+@section PPP packet format
+
+PPP transmits packets over the serial link using a simple encapsulation
+scheme. First, a two-byte PPP Protocol field is inserted before the
+data to be sent. The value in this field identifies
+which higher-level protocol (either a network protocol such as IP or a
+PPP control protocol such as LCP) should receive the data in the packet.
+By default, a one-byte Address field with the value 0xFF, and a one-byte
+Control field with the value 0x03, are inserted before the PPP Protocol
+field (apparently this is supposed to provide compatibility with HDLC,
+in case there is a synchronous to asynchronous converter in the serial
+link).
+
+On slow serial links, these fields can be compressed down to one byte in
+most cases. The PPP Address and Control fields are compressed by simply
+omitting them (``address/control compression''). The PPP Protocol field
+values are chosen so that bit 0 (the least-significant bit) of the first
+(most significant) byte is always 0, and bit 0 of the second byte is
+always 1. The PPP Protocol field can be compressed by omitting the
+first byte, provided that it is 0 (``protocol compression''). The
+values for this field are assigned so that the first byte is zero for
+all of the commonly-used network protocols. For example, the PPP
+Protocol field value for IP is 0x21.
+
+For asynchronous serial links, which do not provide any packet framing
+or transparency, a further encapsulation is used as follows. First a
+16-bit Frame Check Sequence (FCS) is computed over the packet to be
+sent, and appended as two bytes to the end of the packet.
+
+Then each byte of the packet is examined, and if it contains one of the
+characters which are to be escaped, it is replaced by a two byte
+sequence: the 0x7d character '}', followed by the character with bit 5
+inverted. For example, the control-C character (0x03) could be replaced
+by the two-byte sequence 0x7d, 0x23 ('}#'). The 0x7d and 0x7e ('~')
+characters are always escaped, and the 0x5e ('^') character may not be
+escaped.
+
+Finally, a ``flag'' character (0x7e, '~') is inserted at the beginning
+and end of the packet to mark the packet boundaries. The initial flag
+may be omitted if this packet immediately follows another packet, as the
+ending flag for the previous packet can serve as the beginning flag of
+this packet.
+
+@node LCP negotiation, IPCP negotiation, PPP packet format, Introduction
+@section LCP negotiation
+
+The LCP negotiation process actually involves two sets of negotiations,
+one for each direction of the PPP connection. Thus A will send B
+packets (``Configure-Requests'') describing what characteristics A would
+like to have apply to the B -> A direction of the link, that is, to the
+packets that A will receive. Similarly B will send A packets describing
+the characteristics it would like to have apply to the packets it will
+be receiving. These characteristics need not necessarily be the same in
+both directions.
+
+The parameters which are negotiated for each direction of the connection
+using LCP are:
+
+@itemize @bullet
+@item
+Maximum Receive Unit (MRU): indicates the maximum packet size which we
+are prepared to receive (specifically the maximum size of the
+data portion of the packet). The default value is 1500, but on
+slow serial links, smaller values give better response. The choice of
+MRU is discussed below (see xxx).
+
+@item
+Async Control Character Map (ACCM): indicates the set of control
+characters (characters with ASCII values in the range 0 - 31) which we
+wish to receive in escaped form. The default is that the sender should
+escape all characters in the range 0 - 31.
+
+@item
+Authentication Protocol: indicates which protocol we would like the peer
+to use to authenticate itself. Common choices are the Password
+Authentication Protocol (PAP) and the Cryptographic Handshake
+Authentication Protocol (CHAP).
+
+@item
+Quality Protocol: indicates which protocol which we would like the peer
+to use to send us link quality reports. The ppp-2.x package does not
+currently support link quality reports.
+
+@item
+Magic Number: a randomly-chosen number, different from the peer's magic
+number. If we persistently receive our own magic number in the peer's
+configure-request packets, then we can conclude that the serial link is
+looped back.
+
+@item
+Protocol Field Compression: indicates that we wish the peer to compress
+the PPP Protocol field to one byte, where possible, in the packets it
+sends.
+
+@item
+Address/Control Field Compression: indicates that we wish the peer to
+compress the PPP Address/Control fields (by simply omitting them) in the
+packets it sends.
+@end itemize
+
+@node IPCP negotiation, , LCP negotiation, Introduction
+@section IPCP negotiation
+
+The IPCP negotiation process is very similar to the LCP negotiation
+process, except that of course different parameters are negotiated.
+The parameters which are negotiated using IPCP are:
+
+@itemize @bullet
+@item
+IP Address: the IP address (32-bit host IP number) which we plan to use
+as the local address for our end of the link.
+
+@item
+TCP header compression: indicates (a) that we wish the peer to compress
+the TCP/IP headers of TCP/IP packets that it sends, using the Van
+Jacobson algorithm as described in RFC1144; (b) the maximum slot ID that
+we wish the peer to use, and (c) whether we are prepared to accept
+packets with the slot ID field compressed (omitted).
+
+With Van Jacobson (VJ) compression, the receiver and transmitter (for
+one direction of the connection) both keep a table, with a certain
+number of ``slots'', where each slot holds the TCP/IP header of the most
+recently transmitted packet for one TCP connection. If a packet is to
+be transmitted for a TCP connection which does not have a slot currently
+allocated, the VJ scheme will allocate one of the slots and send the
+entire TCP/IP header, together with the slot number. For many packets,
+there will be a slot already allocated for the TCP connection, and the
+VJ scheme will then often be able to replace the entire TCP/IP header
+with a much smaller compressed header (typically only 3 - 7 bytes)
+describing which fields of the TCP/IP header have changed, and by how
+much. If there are many more active connections than slots, the
+efficiency of the VJ scheme will drop, because it will not be able to
+send compressed headers as often.
+
+Usually the compressed header includes a one-byte slot index, indicating
+which TCP connection the packet is for. It is possible to reduce the
+header size by omitting the slot index when the packet has the same slot
+index as the previous packet. However, this introduces a danger if the
+lower levels of the PPP software can sometimes drop damaged packets
+without informing the VJ decompressor, as it may then assume the wrong
+slot index for packets which have the slot index field omitted. With
+the ppp-2.x software, however, the probability of this happening is
+generally very small (see xxx).
+
+@end itemize