Connected: An Internet Encyclopedia
RFC 1661 - 2. PPP Encapsulation

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1661
Prev: 1.2. Terminology
Next: 3. PPP Link Operation

### 2. PPP Encapsulation

The PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate the beginning and end of the encapsulation. Methods of providing framing are specified in companion documents.

A summary of the PPP encapsulation is shown below. The fields are transmitted from left to right.

               +----------+-------------+---------+
               | Protocol | Information | Padding |
               | 8/16 bits|      *      |    *    |
               +----------+-------------+---------+

#### Protocol Field

The Protocol field is one or two octets, and its value identifies the datagram encapsulated in the Information field of the packet. The field is transmitted and received most significant octet first.

The structure of this field is consistent with the ISO 3309 extension mechanism for address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules MUST be treated as having an unrecognized Protocol.

Protocol field values in the "0***" to "3***" range identify the network-layer protocol of specific packets, and values in the "8***" to "b***" range identify packets belonging to the associated Network Control Protocols (NCPs), if any.

Protocol field values in the "4***" to "7***" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "c***" to "f***" range identify packets as link-layer Control Protocols (such as LCP).

Up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. This specification reserves the following values:

          Value (in hex)  Protocol Name

          0001            Padding Protocol
          0003 to 001f    reserved (transparency inefficient)
          007d            reserved (Control Escape)
          00cf            reserved (PPP NLPID)
          00ff            reserved (compression inefficient)

          8001 to 801f    unused
          807d            unused
          80cf            unused
          80ff            unused

          c021            Link Control Protocol
          c023            Password Authentication Protocol
          c025            Link Quality Report
          c223            Challenge Handshake Authentication Protocol

Developers of new protocols MUST obtain a number from the Internet Assigned Numbers Authority (IANA), at IANA@isi.edu.

#### Information Field

The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field.

The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU.

#### Padding

On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information.

Next: 3. PPP Link Operation

Connected: An Internet Encyclopedia
RFC 1661 - 2. PPP Encapsulation