PPP Suite

DNCPRFC1376 http://www.cis.ohio-state.edu/htbin/rfc/rfc1376.html

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

Identifier

Length

Data

1 byte

1 byte

2 bytes

variable

DNCP packet structure

Code Decimal value which indicates the type of DNCP 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 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.

Interested in more details about testing this protocol? click here  

L2F

RFC2341 http://www.cis.ohio-state.edu/htbin/rfc/rfc2341.html

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.

(Compliant with IETF draft-ietf-pppext-l2f-03 1996-12.)

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

13

16

24

32

F K P S 0 0 0 0 0 0 0 0 C

Ver

Protocol

Sequence (opt)

Multiplex ID

Client ID

Length

Payload offset

Packet key (opt.) (32 bits)

Payload

Checksum

L2F packet structure

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:

Invalid Invalid message.
L2F_CONF Request configuration.
L2F_CONF_NAME Name of peer sending L2F_CONF.
L2F_CONF_CHAL Random number peer challenges.
L2F_CONF_CLID Assigned_CLID for peer to use.
L2F_OPEN Accept configuration.
L2F_OPEN_NAME Name received from client.
L2F_OPEN_CHAL Challenge client received.
L2F_OPEN_RESP Challenge response from client.
L2F_ACK_LCP1 LCP CONFACK accepted from client.
L2F_ACK_LCP2 LCP CONFACK sent to client.
L2F_OPEN_TYPE Type of authentication used.
L2F_OPEN_ID ID associated with authentication.
L2F_REQ_LCP0 First LCP CONFREQ from client.
L2F_CLOSE Request disconnect.
L2F_CLOSE_WHY Reason code for close.
L2F_CLOSE_STR ASCII string description.
L2F_ECHO Verify presence of peer.
L2F_ECHO_RESP Respond to L2F_ECHO.
Interested in more details about testing this protocol? click here   L2TP draft http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-pppext-l2tp-11.txt

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:

8

16

32 bits

T

L

I

C

F

K

O

0

0

Ver (3 bits)

Length

Tunnel ID

Call ID

Ns

Nr

AVP (8 bytes)

L2TP packet structure
T The T bit is 1 for control messages and 0 for payload messages. For control messages, the following seven bits must be set to 1001000, making the header more compatible in encoding with the payload message.  

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:

Offset size (16 bits)

Offset pad (16 bits)

Additional fields in L2TP payload message
Offset size This field specifies the number of bytes past the L2TP header at which the payload data is expected to start. It is recommended that data thus skipped be initialized to 0s. If the offset size is 0, or the O bit is not set, the first byte following the last byte of the L2TP header is the first byte of payload data.

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:

16

32

M

H

0

0

0

0

Overall length

Vendor ID

Attribute

Value

L2TP AVP structure
M The first six bits are a bit mask, describing the general attributes of the AVP. The M bit, known as the mandatory bit, controls the behavior required of an implementation which receives an AVP which it does not recognize.  

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? click here

PPTP RFC2637 http://www.cis.ohio-state.edu/htbin/rfc/rfc2637.html

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:

16

32 bits

Length

PTPP message type

Magic cookie

Control message type

Reserved 0

PPTP header structure

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

PPTP message type The message type. Possible values are:

1 Control message
2 Management message

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:

1 Start-Control-Connection-Request.
2 Start-Control-Connection-Reply.
3 Stop-Control-Connection-Request.
4 Stop-Control-Connection-Reply.
5 Echo-Request.
6 Echo-Reply.
Call Management
7 Outgoing-Call-Request.
8 Outgoing-Call-Reply.
9 Incoming-Call-Request.
10 Incoming-Call-Reply.
11 Incoming-Call-Connected.
12 Call-Clear-Request.
13 Call-Disconnect-Notify.
Error Reporting
14 WAN-Error-Notify.

PPP Session Control

15 Set-Link-Info.

Reserved A reserved field, must be set to 0.

Interested in more details about testing this protocol? click here  

ECP

RFC1968 http://www.cis.ohio-state.edu/htbin/rfc/rfc1968.html

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

Identifier

Length

Data

1 byte

1 byte

2 bytes

variable

ECP header structure

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.

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

Identifier Decimal value which aids in matching requests and replies.

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

Interested in more details about testing this protocol? click here  

OSINLCP

RFC1377 http://www.cis.ohio-state.edu/htbin/rfc/rfc1377.html

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

Identifier

Length

Data

1 byte

1 byte

2 bytes

variable

OSINLCP header structure

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.

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 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? click here

SDCP

RFC1963 http://www.cis.ohio-state.edu/htbin/rfc/rfc1963.html

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

Identifier

Length

Data

1 byte

1 byte

2 bytes

variable

SDCP header structure

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.

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 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

Length

Data

SDCP configuration options

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

1 Packet-Format
2 Header-Type
3 Length-Field-Present
4 Multi-Port
5 Transport-Mode
6 Maximum-Frame-Size
7 Allow-Odd-Frames
8 FCS-Type
9 Flow-Expiration-Time

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? click here

1 2 3 4 5

PPP Family Protocol Information ATCP | BACP | BAP | BCP | BSD | BVCP | CCP | CHAP | DESE | DNCP | ECP | IPCP | IPHC | IPv6CP | IPXCP | L2F | L2TP | LCP | LQR | LZS | MPPC | MultiPPP | NBFCP | OSINLCP | PAP | PPP | PPP-BPDU | PPTP | SDCP | SNACP
Additional Information