PPP Suite

PPP RFC1548 http://www.cis.ohio-state.edu/htbin/rfc/rfc1548.html RFC1661 http://www.cis.ohio-state.edu/htbin/rfc/rfc1661.html RFC1662 http://www.cis.ohio-state.edu/htbin/rfc/rfc1662.html

PPP (Point-to-Point Protocol) is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation and are assumed to deliver packets in order. PPP provides a common solution for the easy connection of a wide variety of hosts, bridges and routers.

The structure of the PPP header is shown in the following illustration:

Address	Control	Protocol	Information	FCS
1 byte	1 byte	2 bytes	variable	2 bytes
PPP header structure

Address HDLC broadcast address. PPP does not assign individual station addresses. The value of this field is always set to FF Hex.

Control HDLC command for Unnumbered Information (UI) with the Poll/Final bit set to zero. The value of this field is always set to 03 Hex. Frames containing any other value in this field are discarded.

Protocol Identifies the encapsulated protocol within the Information field of the frame.

Information Higher-level protocol data.

FCS Value of the frame checksum calculation. PPP verifies the contents of the FCS field upon receipt of the packet.

Interested in more details about testing this protocol?

PPP-BPDU RFC1638 http://www.cis.ohio-state.edu/htbin/rfc/rfc1638.html

There exist two basic types of bridges: those that interconnect LANs directly, called Local Bridges, and those that interconnect LANs via an intermediate WAN medium such as a leased line, called Remote Bridges. The PPP-BPDU (Bridge Protocol Data Unit) is used to connect Remote Bridges.

The format of the PPP-BPDU packet is shown in the following illustration:

			4	8	16	32 bits
F	I	Z	0	Pads	MAC type	LAN ID high word (optional)
LAN ID low word (optional)							Pad byte	Frame control
Destination MAC address
Destination MAC address							Source MAC address
Source MAC address
LLC data
PPP-BPDU packet structure

F F flag, set if the LAN FCS field is present.

I I flag, set if the LAN ID field is present.

Z Z flag, set if IEEE 802.3 pad must be zero filled to minimum size.

0 0 flag reserved, must be zero.

Pads Any PPP frame may have padding inserted in the Optional Data Link Layer Padding field. This number tells the receiving system how many pad octets to strip off.

MAC type Values of the MAC Type field.

1	Bridge-Identification
2	Line-Identification
3	MAC-Support
4	Tinygram-Compression
5	LAN-Identification
6	MAC-Address
7	Spanning-Tree-Protocol

LAN ID Optional 32-bit field that identifies the Community of LANs which may be interested in receiving this frame. If the LAN ID flag is not set, then this field is not present and the PDU is four octets shorter. Frame control On 802.4, 802.5 and FDDI LANs, there are a few octets preceding the Destination MAC Address, one of which is protected by the FCS. The MAC Type of the frame determines the contents of the Frame Control field. A pad octet is present to provide a 32-bit packet alignment. Destination MAC address As defined by the IEEE. The MAC Type field defines the bit ordering. Source MAC address As defined by the IEEE. The MAC Type field defines the bit ordering. LLC data This is the remainder of the MAC frame which is (or would be were it present) protected by the LAN FCS. Interested in more details about testing this protocol?

BAP

RFC2125 http://www.cis.ohio-state.edu/htbin/rfc/rfc2125.html

The Bandwidth Allocation Protocol (BAP) can be used to manage the number of links in a multi-link bundle. BAP defines datagrams to coordinate adding and removing individual links in a multi-link bundle, as well as specifying which peer is responsible for various decisions regarding managing bandwidth during a multi-link connection.

The format of the BAP packet is shown in the following illustration:

Type	Length	Data
1 byte	1 byte	variable
BAP packet structure

Type One-octet field which indicates the type of the BAP Datagram Option. This field is binary coded Hexadecimal. Interested in more details about testing this protocol?

CHAP RFC1334 http://www.cis.ohio-state.edu/htbin/rfc/rfc1334.html

Challenge Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment and may be repeated any time after the link has been established.

Exactly one CHAP packet is encapsulated in the Information field of a PPP data link layer frame where the protocol field indicates type hex c223. The structure of the CHAP packet is shown in the following illustration.

Code	Identifier	Length	Data . . .
1 byte	1 byte	2 bytes	variable
CHAP packet structure

Code Identifies the type of CHAP packet. CHAP codes are assigned as follows:

1	Challenge
2	Response
3	Success
4	Failure

Identifier Aids in matching challenges, responses and replies.

Length Length of the CHAP packet including the Code, Identifier, Length and Data fields.

Data Zero or more octets, the format of which is determined by the Code field. The format of the Challenge and Response data fields is shown in the following illustration:

Value Size	Value	Name
1 byte		1 byte
CHAP Challenge and Response data structure

Value size Indicates the length of the Value field.

Value Challenge value is a variable stream of octets which must be changed each time a challenge is sent. Response value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by the “secret” and the Challenge value.

Name Identification of the system transmitting the packet.

For Success and Failure, the data field contains a variable message field which is implementation dependent.

Interested in more details about testing this protocol?

IPHC RFC 2509 IP Header Compression (IPHC) may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. IPHC is also capable of compressing both TCP and UDP transport protocol headers. The IP/UDP/RTP header compression defined in CRTP fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets.

In order to establish compression of IP datagrams sent over a PPP link, each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be used in both NCPs to negotiate parameters for the compression scheme.

Configuration option format

Both the network control protocol for IPv4, IPCP (RFC1332) and the IPv6 NCP, IPV6CP (RFC2023) may be used to negotiate IP Header Compression parameters for their respective protocols. The format of the configuration option is the same for both IPCP and IPV6CP.

Type	Length	IP compression protocol
TCP_SPACE		NON_TCP_SPACE
TCP_SPACE		F_MAX_TIME
MAX_HEADER		Suboptions
1 byte	1 byte	2 byte
IPHC configuration option format

The following parameters are available:

Type The value of the Type field is 2. Length Indicates the length of the suboption in its entirety, including the lengths of the type and length fields. The value of this field is 14. IP compression protocol The value of this field is 0061 (hex). TCP_SPACE The TCP_SPACE field indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP. The suggested value of this field is: 15. TCP_SPACE must be at least 0 and at most 255 (The value 0 implies having one context). F_MAX_PERIOD Maximum interval between full headers. No more then F_MAX_PERIOD compressed non-TCP headers may be sent between full header headers. Suggested value: 256 F_MAX_TIME Maximum time interval between full headers. Suggested value: 5 seconds. A value of zero implies infinity. MAX_HEADER The largest header size in octets that may be compressed. Suggested value: 168 octets. The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers. Suboptions The Suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields. Interested in more details about testing this protocol?

LCP

RFC1570 http://www.cis.ohio-state.edu/htbin/rfc/rfc1570.html RFC1661 http://www.cis.ohio-state.edu/htbin/rfc/rfc1661.html

In order to be sufficiently versatile to be portable to a wide variety of environments, PPP provides the Link Control Protocol (LCP) for establishing, configuring and testing the data link connection. LCP is used to automatically agree upon the encapsulation format options, handle varying limits on sizes of packets, detect a looped-back link and other common misconfiguration errors, and terminate the link. Other optional facilities provided are authentication of the identity of its peer on the link, and determination when a link is functioning properly and when it is failing.

The format of the LCP packet is shown in the following illustration:

Code	Identifier	Length	Data
1 byte	1 byte	2 bytes	variable
LCP packet structure

Code Decimal value which indicates the type of LCP packet:

1	Configure-Request.
2	Configure-Ack.
3	Configure-Nak.
4	Configure-Reject.
5	Terminate-Request.
6	Terminate-Ack.
7	Code-Reject.
8	Protocol-Reject.
9	Echo-Request.
10	Echo-Reply.
11	Discard-Request.
12	Link-Quality Report.

Identifier Decimal value which aids in matching requests and replies.

Length Length of the LCP packet, including the Code, Identifier, Length and Data fields.

Data Variable length field which may contain one or more configuration options. The format of the LCP configuration options is as follows:

Type	Length	Data
LCP configuration options

Type One-byte indication of the type of the configuration option. Length Length of the configuration option including the Type, Length and Data fields. Data Value of the Data field.

LCP decode

Interested in more details about testing this protocol?

LQR RFC1333 http://www.cis.ohio-state.edu/htbin/rfc/rfc1333.html

The Link Quality Report (LQR) protocol specifies the mechanism for link quality monitoring within PPP. Packets are sometimes dropped or corrupted due to line noise, equipment failure, buffer overruns, etc. and it is often desirable to determine when and how often the link drops data. Routers may temporarily allow another route to take precedence, or an implementation may have the option of disconnecting and switching to an alternate link. For these reasons, such a quality monitoring mechanism is necessary.

One LQR packet is encapsulated in the information field of PPP data link layer frames where the protocol field indicates type hex c025. The structure of the LQR packet is shown in the following illustration:

4 bytes

Magic number

Last out LQRs

Last out packets

Last out octets

Peer in LQRs

Peer in packets

Peer in discards

Peer in errors

Peer in octets

Peer out LQRs

Peer out packets

Peer out octets

Save in LQRs

Save in packets

Save in discards

Save in errors

Save in octets

LQR packet structure

Magic number Aids in detecting links which are in the looped-back condition.

Last out LQRs Copied from the most recently received Peer Out LQRs on transmission.

Last out packets Copied from the most recently received Peer Out Packets on transmission.

Last out octets Copied from the most recently received Peer Out Octets on transmission.

Peer in LQRs Copied from the most recently received Save In LQRs on transmission. Whenever the Peer In LQRs field is zero, the Last Out fields are indeterminate and the Peer In fields contain the initial values for the peer.

Peer in packets Copied from the most recently received Save In Packets on transmission.

Peer in discards Copied from the most recently received Save In Discards on transmission.

Peer in errors Copied from the most recently received Save In Errors on transmission.

Peer in octets Copied from the most recently received Save In Octets on transmission.

Peer out LQRs Copied from the Out LQRs on transmission. This number must include this LQR.

Peer out packets Copied from the current MIB ifOutUniPackets and ifOutNUniPackets on transmission. This number must include this LQR.

Peer out octets Copied from the current MIB ifOutOctets on transmission. This number must include this LQR.

The following fields are not actually transmitted over the inbound link. Rather, they are logically appended to the packet by the Rx process.

Save in LQRs Copied from In LQRs on reception. This number must include this LQR.

Save in packets Copied from the current MIB ifInUniPackets and ifInNUniPackets on reception. This number must include this LQR.

Save in discards Copied from the current MIB ifInDiscards on reception. This number must include this LQR.

Save in errors Copied from the current MIB ifInErrors on reception. This number must include this LQR.

Save in octets Copied from the current InGoodOctets on reception. This number must include this LQR.

Interested in more details about testing this protocol?

MPPC RFC 2118 http://www.cis.ohio-state.edu/htbin/rfc/rfc2118.html

The Point-to-Point Protocol provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. The Microsoft Point to Point Compression protocol (also referred to as MPPC) compresses PPP encapsulated packets. The Microsoft Point to Point Compression scheme is a means of representing arbitrary Point-to-Point Protocol (PPP) packets in a compressed form. The MPPC algorithm is designed to optimize processor utilization and bandwidth utilization in order to support large number of simultaneous connections. The MPPC algorithm is also optimized to work efficiently in typical PPP scenarios (1500 byte MTU, etc.). The CCP configuration Option negotiates the use of MPPC on the link. Before any MPPC packets may be transmitted, PPP must reach the Network-Layer protocol phase and the CCP Control Protocol must reach the opened state. One MPPC datagram is encapsulated in the PPP information field. Only packets with PPP protocol numbers in the range 0021 to 00FA are compressed.

The format of the MPPC packet is shown in the following illustration:

1 byte		1 byte
PPP Protocol	A B C D	Coherency Count
Compressed Data…

……

…..

MPPC packet structure

PPP Protocol Identifies the encapsulated protocol within the information field of the frame.

Bit A This bit indicates that the history buffer has just been initialized before the packet was generated. It is sent to inform the peer that the sender has initialized its history buffer before compressing the packet and that the receiving peer must initialize its history buffer before decompressing the packet. This bit is referred to as the flushed bit.

Bit B This bit indicates that the packet was moved to the front end of the history buffer.

Bit C This bit is set to indicate that the packet is compressed.

Bit D This bit must be set to 0.

Coherency Count This is used to assure that the packets are sent in the correct order and that no packet has been dropped.

Compressed Data The compressed data begins with the protocol field; for example in an IP packet (0021 followed by an IIP header) the compressor will try to compress the 0021 field first and then the IP header itself.

Interested in more details about testing this protocol?

PAP RFC1334 http://www.cis.ohio-state.edu/htbin/rfc/rfc1334.html

Password Authentication Protocol (PAP) provides a simple method for the peer to establish its identity using a 2-way handshake. This is done only upon initial link establishment.

The PAP packet is encapsulated in the Information field of a PPP data link layer frame where the protocol field indicates type hex c023. The structure of the PAP packet is shown in the following illustration:

Code	Identifier	Length	Data . . .
1 byte	1 byte	2 bytes
PAP packet structure

Code One-octet field which identifies the type of PAP packet. PAP codes are assigned as follows:

1	Authenticate-Request
2	Authenticate-Ack
3	Authenticate-Nak

Identifier Aids in matching requests and replies.

Length Indicates the length of the PAP packet including the Code, Identifier, Length and Data fields.

Data Zero or more octets, the format of which is determined by the Code field. The format of the data field for Authenticate-Request packets is shown below:

Peer-ID length	Peer-ID	Password length	Password
1 byte	variable	1 byte	variable
Data structure for Authenticate-Request packet

Peer-ID length Length of the Peer-ID field.

Peer-ID Indicates the name of the peer to be authenticated.

Password length Length of the Password field.

Password Indicates the password to be used for authentication.

The format of the data field for Authenticate-Ack and Authenticate-Nak packets is shown below:

Message Length	Message
1 byte	variable
Data structure for Authenticate-Ack and Authenticate-Nak packets

Message length Length of the Message field.

Message The contents of the Message field are implementation dependent.

Interested in more details about testing this protocol?

ATCP

RFC1378 http://www.cis.ohio-state.edu/htbin/rfc/rfc1378.html

The AppleTalk Control Protocol (ATCP) is responsible for configuring, the AppleTalk parameters on both ends of the point-to-point link. ATCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). ATCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. ATCP packets received before this phase is reached are discarded.

The format of the ATCP packet is shown in the following illustration:

Code	Identifier	Length	Data
1 byte	1 byte	2 bytes	variable
ATCP packet structure

Code Decimal value which indicates the type of ATCP packet.

1	Configure-Request
2	Configure-Ack
3	Configure-Nak
4	Configure-Reject
5	Terminate-Request
6	Terminate-Ack
7	Code-Reject

Identifier Decimal value which aids in matching requests and replies.

Length Length of the ATCP packet, including the Code, Identifier, Length and Data fields.

Data Variable length field which may contain one or more configuration options. The format of the ATCP configuration options is as follows:

Type	Length	Data
Format of ATCP configuration options

Type One-byte indication of the type of the configuration option.

1	AppleTalk-Address
2	Routing-Protocol
3	Suppress-Broadcasts
4	AT-Compression Protocol
6	Server-Information
7	Zone-Information
8	Default Router-Address

Length Length of the configuration option including the Type, Length and Data fields.

Data Value of the Data field.

Interested in more details about testing this protocol?

1 2 3 4 5

Additional Information

ProtocolNetwork Service Assurance