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

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
PPP Session Control
Reserved
A reserved field, must be set to 0.
Interested in more details about testing
this protocol?
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?
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?

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?

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
|