Network Working Group D. Perkins Request for Comments: 1172 CMU R. Hobby UC Davis July 1990 The Point-to-Point Protocol (PPP) Initial Configuration Options Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of 1) a method for encapsulating datagrams over serial links, 2) an extensible Link Control Protocol (LCP), and 3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol (PPP) [1]. This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme. Perkins & Hobby [Page i] RFC 1172 PPP Initial Options July 1990 Table of Contents 1. Introduction .......................................... 1 2. Link Control Protocol (LCP) Configuration Options ..... 1 2.1 Maximum-Receive-Unit ............................ 2 2.2 Async-Control-Character-Map ..................... 3 2.3 Authentication-Type ............................. 5 2.4 Magic-Number .................................... 7 2.5 Link-Quality-Monitoring ......................... 10 2.6 Protocol-Field-Compression ...................... 11 2.7 Address-and-Control-Field-Compression ........... 13 3. Link Quality Monitoring ............................... 15 3.1 Design Motivation ............................... 15 3.2 Design Overview ................................. 15 3.3 Processes ....................................... 16 3.4 Counters ........................................ 18 3.5 Measurements, Calculations, State Variables ..... 19 3.6 Link-Quality-Report Packet Format ............... 21 3.7 Policy Suggestions .............................. 25 3.8 Example ......................................... 25 4. Password Authentication Protocol ...................... 27 4.1 Packet Format ................................... 27 4.2 Authenticate .................................... 29 4.3 Authenticate-Ack ................................ 31 4.4 Authenticate-Nak ................................ 32 5. IP Control Protocol (IPCP) Configuration Options ...... 33 5.1 IP-Addresses .................................... 34 5.2 Compression-Type ................................ 36 REFERENCES ................................................... 37 SECURITY CONSIDERATIONS ...................................... 37 AUTHOR'S ADDRESS ............................................. 37 Perkins & Hobby [Page ii] RFC 1172 PPP Initial Options July 1990 1. Introduction The Point-to-Point Protocol (PPP) [1] proposes a standard method of encapsulating IP datagrams, and other Network Layer protocol information, over point-to-point links. PPP also proposes an extensible Option Negotiation Protocol. [1] specifies only the protocol itself; the initial set of Configuration Options are described in this document. These Configuration Options allow MTUs to be changed, IP addresses to be dynamically assigned, header compression to be enabled, and much more. This memo is divided into several sections. Section 2 describes Configuration Options for the Link Control Protocol. Section 3 specifies the use of the Link Quality Monitoring option. Section 4 defines a simple Password Authentication Protocol. Finally, Section 5 specifies Configuration Options for the IP Control Protocol. 2. Link Control Protocol (LCP) Configuration Options As described in [1], LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications proposed in this document include such things as the maximum receive unit, async control character mapping, the link authentication method, etc. The initial proposed values for the LCP Configuration Option Type field (see [1]) are assigned as follows: 1 Maximum-Receive-Unit 2 Async-Control-Character-Map 3 Authentication-Type 4 NOT ASSIGNED 5 Magic-Number 6 Link-Quality-Monitoring 7 Protocol-Field-Compression 8 Address-and-Control-Field-Compression Perkins & Hobby [Page 1] RFC 1172 PPP Initial Options July 1990 2.1. Maximum-Receive-Unit Description This Configuration Option provides a way to negotiate the maximum packet size used across one direction of a link. By default, all implementations must be able to receive frames with 1500 octets of Information. This Configuration Option may be sent to inform the remote end that you can receive larger frames, or to request that the remote end send you smaller frames. If smaller frames are requested, an implementation MUST still be able to receive 1500 octet frames in case link synchronization is lost. A summary of the Maximum-Receive-Unit 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 | Maximum-Receive-Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4 Maximum-Receive-Unit The Maximum-Receive-Unit field is two octets and indicates the new maximum receive unit. The Maximum-Receive-Unit covers only the Data Link Layer Information field but not the header, trailer or any transparency bits or bytes. Default 1500 Perkins & Hobby [Page 2] RFC 1172 PPP Initial Options July 1990 2.2. Async-Control-Character-Map Description This Configuration Option provides a way to negotiate the use of control character mapping on asynchronous links. By default, PPP maps all control characters into an appropriate two character sequence. However, it is rarely necessary to map all control characters and often times it is unnecessary to map any characters. A PPP implementation may use this Configuration Option to inform the remote end which control characters must remain mapped and which control characters need not remain mapped when the remote end sends them. The remote end may still send these control characters in mapped format if it is necessary because of constraints at its (the remote) end. This option does not solve problems for communications links that can send only 7- bit characters or that can not send all non-control characters. There may be some use of synchronous-to-asynchronous converters (some built into modems) in Point-to-point links resulting in a synchronous PPP implementation on one end of a link and an asynchronous implemention on the other. It is the responsibility of the converter to do all mapping conversions during operation. To enable this functionality, synchronous PPP implementations MUST always accept a Async-Control-Character-Map Configuration Option (it MUST always respond to an LCP Configure-Request specifying this Configuration Option with an LCP Configure-Ack). However, acceptance of this Configuration Option does not imply that the synchronous implementation will do any character mapping, since synchronous PPP uses bit-stuffing rather than character-stuffing. Instead, all such character mapping will be performed by the asynchronous-to-synchronous converter. 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 | Async-Control-Character-Map +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Perkins & Hobby [Page 3] RFC 1172 PPP Initial Options July 1990 Length 6 Async-Control-Character-Map The Async-Control-Character-Map field is four octets and indicates the new async control character map. The map is encoded in big- endian fashion where each numbered bit corresponds to the ASCII control character of the same value. If the bit is cleared to zero, then that ASCII control character need not be mapped. If the bit is set to one, then that ASCII control character must remain mapped. E.g., if bit 19 is set to zero, then the ASCII control character 19 (DC3, Control-S) may be sent in the clear. Default All ones (0xffffffff). Perkins & Hobby [Page 4] RFC 1172 PPP Initial Options July 1990 2.3. Authentication-Type Description On some links it may be desirable to require a peer to authenticate itself before allowing Network Layer protocol data to be exchanged. This Configuration Option provides a way to negotiate the use of a specific authentication protocol. By default, authentication is not necessary. If an implementation requires that the remote end authenticate with some specific authentication protocol, then it should negotiate the use of that authentication protocol with this Configuration Option. Successful negotiation of the Authentication-Type option adds an additional Authentication phase to the Link Control Protocol. This phase is after the Link Quality Determination phase, and before the Network Layer Protocol Configuration Negotiation phase. Advancement from the Authentication phase to the Network Layer Protocol Configuration Negotiation phase may not occur until the peer is successfully authenticated using the negotiated authentication protocol. An implementation may allow the remote end to pick from more than one authentication protocol. To achieve this, it may include multiple Authentication-Type Configuration Options in its Configure-Request packets. An implementation receiving a Configure-Request specifying multiple Authentication-Types may accept at most one of the negotiable authentication protocols and should send a Configure-Reject specifying all of the other specified authentication protocols. It is recommended that each PPP implementation support configuration of authentication parameters at least on a per- interface basis, if not a per peer entity basis. The parameters should specify which authetication techniques are minimally required as a prerequisite to establishment of a PPP connection, either for the specified interface or for the specified peer entity. Such configuration facilities are necessary to prevent an attacker from negotiating a reduced security authentication protocol, or no authentication at all, in an attempt to circumvent this authentication facility. If an implementation sends a Configure-Ack with this Configuration Option, then it is agreeing to authenticate with the specified protocol. An implementation receiving a Configure-Ack with this Configuration Option should expect the remote end to authenticate with the acknowledged protocol. Perkins & Hobby [Page 5] RFC 1172 PPP Initial Options July 1990 There is no requirement that authentication be full duplex or that the same authentication protocol be used in both directions. It is perfectly acceptable for different authentication protocols to be used in each direction. This will, of course, depend on the specific authentication protocols negotiated. This document defines a simple Password Authentication Protocol in Section 4. Development of other more secure protocols is encouraged. A summary of the Authentication-Type 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 | Authentication-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 3 Length >= 4 Authentication-Type The Authentication-Type field is two octets and indicates the type of authentication protocol desired. Values for the Authentication-Type are always the same as the PPP Data Link Layer Protocol field values for that same authentication protocol. The most up-to-date values of the Authentication-Type field are specified in "Assigned Numbers" [2]. Initial values are assigned as follows: Value (in hex) Protocol c023 Password Authentication Protocol Data The Data field is zero or more octets and contains additional data as determined by the particular authentication protocol. Perkins & Hobby [Page 6] RFC 1172 PPP Initial Options July 1990 Default No authentication protocol necessary. 2.4. Magic-Number Description This Configuration Option provides a way to detect looped-back links and other Data Link Layer anomalies. This Configuration Option may be required by some other Configuration Options such as the Link-Quality-Monitoring Configuration Option. Before this Configuration Option is requested, an implementation must choose its Magic-Number. It is recommended that the Magic- Number be chosen in the most random manner possible in order to guarantee with v