PPP Suite

The PPP DECnet Phase IV Control Protocol is responsible for establishing and configuring Digital’s DNA Phase IV routing protocol (DECnet Phase IV) over PPP. The protocol applies only to DNA Phase IV routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). (Compliant with IETF RFC1376, Mar 1995.)

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

Code Decimal value which indicates the type of DNCP packet.

Identifier Decimal value which aids in matching requests and replies.

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

Data A variable length field which in similar protocols contains options, DNCP packets, however, have no options.

L2F

The Layer 2 Forwarding protocol (L2F) permits the tunneling of the link layer of higher layer protocols. Using such tunnels it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided.

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

Version The major version of the L2F software creating the packet.

Protocol The protocol field specifies the protocol carried within the L2F packet.

Sequence The sequence number is present if the S bit in the L2F header is set to 1.

Multiplex ID The packet multiplex ID identifies a particular connection within a tunnel.

Client ID The client ID (CLID) assists endpoints in demultiplexing tunnels.

Length The length is the size in octets of the entire packet, including the header, all the fields and the payload.

Payload offset This field specifies the number of bytes past the L2F header at which the payload data is expected to start. This field is present if the F bit in the L2F header is set to 1.

Packet key The key field is present if the K bit is set in the L2F header. This is part of the authentication process.

Checksum The checksum of the packet. The checksum field is present if the C bit in the L2F header is set to 1.

Option Messages

When the link is initiated, the endpoints communicate to verify the presence of L2F on the remote end, and to permit any needed authentication. The protocol for such negotiation is always 1, indicating L2F management. The message itself is structured as a sequence of single octets indicating an option. When the protocol field of an L2F specifies L2F management, the body of the packet is encoded as zero or more options. An option is a single octet message type, followed by zero or more sub-options. Each sub-option is a single byte sub-option value, and followed by additional bytes as appropriate for the sub-option.

Possible option messages are:

The L2TP Protocol is used for integrating multi-protocol dial-up services into existing Internet Service Providers Point of Presence (hereafter referred to as ISP and POP, respectively). This protocol may also be used to solve the “multilink hunt-group splitting” problem. Multilink PPP, often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Because L2TP makes a PPP session appear at a location other than the physical point at which the session was physically received, it can be used to make all channels appear at a single NAS, allowing for a multilink operation even when the physical calls are spread across distinct physical NASs. (Compliant with IETF draft-ietf-pppext-l2tp-05.txt 1197.)

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

L When set, this indicates that the Length field is present, indicating the total length of the received packet. Must be set for control messages.

I & C The I and C bits are reserved and must be set to 0. These bit positions represent options no longer present in L2TP.

F If the F bit is set, both the Nr and Ns fields are present. F must be set for control messages.

K The K bit is reserved and must be set to 0.

O When set, this field indicates that the Offset Size field is present in payload messages.

Ver The value of the ver bit is always 002. This indicates a version 1 L2TP message.

Length Overall length of the message, including header, message type AVP, plus any additional AVP’s associated with a given control message type.

Tunnel ID Identifies the tunnel to which a control message applies. If an Assigned Tunnel ID has not yet been received from the peer, Tunnel ID must be set to 0. Once an Assigned Tunnel ID is received, all further packets must be sent with Tunnel ID set to the indicated value.

Call ID Identifies the user session within a tunnel to which a control message applies. If a control message does not apply to a single user session within the tunnel (for instance, a Stop-Control-Connection-Notification message), Call ID must be set to 0.

Nr Currently transmitted packet.

Ns Latest received packet.

Payload messages have two additional fields before the AVP as follows:

AVP The AVP (Attribute-Value Pair) is a uniform method used for encoding message types and bodies throughout L2TP. The format of the AVP is given below:

H The hidden bit controls the hiding of the data in the value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP.

Overall length Encodes the number of octets (including the overall length field itself) contained in this AVP. It is 10 bits, permitting a maximum of 1024 bytes of data in a single AVP.

Vendor ID The IANA assigned SMI Network Management Private Enterprise Codes value, encoded in network byte order.

Attribute The actual attribute, a 16-bit value with a unique interpretation across all AVP’s defined under a given Vendor ID.

Value The value field follows immediately after the Attribute field, and runs for the remaining octets indicated in the overall length (i.e., overall length minus six octets of header).

L2TP decode

Interested in more details about testing this protocol?

PPTP (Point to Point Tunneling Protocol) allows PPP to be channeled through an IP network. It uses a client-server architecture to decouple functions which exist in current Network Access Servers and support Virtual Private Networks. It specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN, or to initiate outbound circuit switched connections. PPTP uses a GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.

(Compliant with IETF draft-ietf-pppext-pptp-00.txt.)

The format of the header is shown in the following illustration:

Length Total length in octets of this PPTP message including the entire PPTP header.

PPTP message type The message type. Possible values are:

Magic cookie The magic cookie is always sent as the constant 0x1A2B3C4D. Its basic purpose is to allow the receiver to ensure that it is properly synchronized with the TCP data stream.

Control Message Type Values may be:

PPP Session Control

Reserved A reserved field, must be set to 0.

ECP

The Encryption Control Protocol (ECP) is responsible for configuring and enabling data encryption algorithms on both ends of the point-to-point link. ECP uses the same packet exchange mechanism as the Link Control Protocol (LCP). ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. ECP packets received before this phase is reached are silently discarded. (Compliant with IETF RFC1968.)

The format of the header is shown in the following illustration:

Code A one octet field identifying the type of ECP packet. When a packet is received with an unknown Code field, a Code Reject packet is transmitted.

Identifier Decimal value which aids in matching requests and replies.

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

OSINLCP

The OSI Network Layer Control Protocol (OSINLCP) is responsible for configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. OSINLCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. (Compliant with IETF RFC1377.)

The format of the header is shown in the following illustration:

Code A one-octet field identifying the type of OSINLCP packet. When a packet is received with an unknown Code field, a Code Reject packet is transmitted.

Identifier Decimal value which aids in matching requests and replies.

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

Data Variable length field which may contain one or more configuration options.

Interested in more details about testing this protocol?

SDCP

The PPP Serial Data Control Protocol (SDCP) is responsible for configuring, enabling and disabling the SDTP (Serial Data Transport Protocol) modules on both ends of the point-to-point link. SDCP uses the same packet exchange mechanism and state machine as the Link Control Protocol. SDCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. (Compliant with IETF RFC1963.)

The format of the header is shown in the following illustration:

Code A one octet field identifying the type of SDCP packet. When a packet is received with an unknown Code field, a Code Reject packet is transmitted.

Identifier Decimal value which aids in matching requests and replies.

Length Length of the SDCP 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 SDCP configuration options is as follows:

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.

Interested in more details about testing this protocol?

1 2 3 4 5