TCP / IP Suite

ARP/RARP

RFC826 http://www.cis.ohio-state.edu/htbin/rfc/rfc826.html
RFC1293 http://www.cis.ohio-state.edu/htbin/rfc/rfc1293.html
This RFC has been replaced by RFC 2390.
The information on this page will be updated to suit the new RFC in the near future.
RFC1390 http://www.cis.ohio-state.edu/htbin/rfc/rfc1390.html

TCP/IP uses the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP) to initialize the use of Internet addressing on an Ethernet or other network that uses its own media access control (MAC). ARP allows a host to communicate with other hosts when only the Internet address of its neighbors is known. Before using IP, the host sends a broadcast ARP request containing the Internet address of the desired destination system.

The ARP/RARP header structure is shown in the illustration below.

16		32 bits
Hardware Type		Protocol Type
HLen (8)	Plen (8)		Operation
Sender Hardware Address
Sender Protocol Address
Target Hardware Address
Target Protocol Address
ARP/RARP header structure

Hardware type
Specifies a hardware interface type for which the sender requires a response.

Protocol type
Specifies the type of high-level protocol address the sender has supplied.

HLen
Hardware address length.

PLen
Protocol address length.

Operation
The values are as follows:

1	ARP request.
2	ARP response.
3	RARP request.
4	RARP response.
5	Dynamic RARP request.
6	Dynamic RARP reply.
7	Dynamic RARP error.
8	InARP request.
9	InARP reply.

Sender hardware address
HLen bytes in length.

Sender protocol address
PLen bytes in length.

Target hardware address
HLen bytes in length.

Target protocol address
PLen bytes in length.


Enlarge	More Details

Interested in more details about testing this protocol?

DCAP

http://info.internet.isi.edu/in-notes/rfc/files/rfc2114.txt .

The (DLSw) Data Link Switching Client Access Protocol is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions.

Since the Data Link Switching Protocol, RFC 1795, was published, some software vendors have begun implementing DLSw on workstations. The implementation of DLSw on a large number of workstations raises the important issues of scalability and efficiency. Since DLSw is a switch-to-switch protocol, it is not efficient when implemented on workstations. DCAP addresses these issues. It introduces a hierarchical structure to resolve the scalability problems. All workstations are clients to the router (server) rather than peers to the router. This creates a client/server model. It also provides a more efficient protocol between the workstation (client) and the router (server).

(Application layer)

DCAP Packet Header

The DCAP packet header is used to identify the message type and length of the frame. This is a general purpose header used for each frame that is passed between the DCAP server and the clien

8	16
Protocol ID/Version Number	Message Type
Packet Length
DCAP Header Format

Protocol ID
The Protocol ID uses the first 4 bits of this field and is set to 1000.

Version number
The Version number uses the next 4 bits in this field and is set to 0001.

Message type
The message type is the DCAP message type.

The following message types exist:

DCAP Frame Name	Code	Function
CAN U REACH	0x01	Find if the station given is reachable
I CAN REACH	0x02	Positive response to CAN U REACH
I CANNOT REACH	0x03	Negative response to CAN U REACH
START DL	0x04	Setup session for given addresses
DL STARTED	0x05	Session started
START DL FAILED	0x06	Session Start failed
XID FRAME	0x07	XID frame
CONTACT STN	0x08	Contact destination to establish SABME
STN CONTACTED	0x09	Station contacted - SABME mode set
DATA FRAME	0x0A	Connectionless Data Frame for a link
INFO FRAME	0x0B	Connection oriented I-Frame
HALT DL	0x0C	Halt Data Link session
HALT DL NOACK	0x0D	Halt Data Link session without ack
DL HALTED	0x0E	Session halted
FCM FRAME	0x0F	Data Link Session Flow Control Message
DGRM FRAME	0x11	Connectionless Datagram Frame for circuit
CAP XCHANGE	0x12	Capabilities Exchange Message
CLOSE PEER REQUEST	0x13	Disconnect Peer Connection Request
CLOSE PEER RESPONSE	0x14	Disconnect Peer Connection Response
PEER TEST REQ	0x1D	Peer keepalive test request
PEER TEST RSP	0x1E	Peer keepalive response

Packet length
The total packet length is the length of the packet including the DCAP header, DCAP data and user data. The minimum size of the packet is 4, which is the length of the header.

Interested in more details about testing this protocol?

ATMP

RFC 2107 http://www.cis.ohio-state.edu/htbin/rfc/rfc2107.html

The Ascend Tunnel Management Protocol (ATMP) is a protocol currently being used in Ascend Communication products to allow dial-in client software to obtain virtual presence on a user's home network from remote locations. A user calls into a remote NAS but instead of using an address belonging to a network directly supported by the NAS, the client software uses an address belonging to the user's "Home Network". This address can be either provided by the client software or assigned from a pool of addresses from the Home Network address space. In either case, this address belongs to the Home Network and therefore special routing considerations are required in order to route packets to and from these clients. A tunnel between the NAS and a special “Home Agent” (HA) located on the Home Network is used to carry data to and from the client.
The format of the ATMP header is shown in the following illustration:

Version	Message type	Identifier
ATMP packet structure

Version
The ATMP protocol version must be 1.

Message type
ATMP defines a set of request and reply messages sent with UDP. There are 7 different ATMP message types represented by the following values.

MessageType	Type Code
Registration Request Challenge Request Challenge Reply Registration Reply Deregister Request Deregister Reply Error Notification	1 2 3 4 5 6 7

Identifier
A 16 bit number used to match replies with requests. A new value should be provided in each new request. Retransmissions of the same request should use the same identifier.

Interested in more details about testing this protocol?

L2F

RFC 2341 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.
The format of the packet is shown in the following illustration:

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 (optional)

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

IETF draft
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-pppext-l2tp-11.txt
RFC 2661

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.

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

32 bits

VER

Length

Tunnel ID

SESSION ID

AVP (bytes +)

L2TP packet structure

T
The T bit indicates the type of message. It is set to 0 for data messages and 1 for control messages.

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.

X
The X bits are reserved for future extensions. All reserved bits are set to 0 on outgoing messages and are ignored on incoming messages.

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

O
When set, this field indicates that the Offset Size field is present in payload messages. This bit is set to 0 for control messages.

P
If the Priority (P) bit is 1, this data message receives preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, are generally sent with this bit set to 1. Without it, a temporary interval of local congestion could result in interference with keepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit has a value of 0 for all control 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
The sequence number expected in the next control message to be receivec.

Ns
The sequence number for this data or control message.

Data 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 bits
M	H	O	O	O	O	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).


Enlarge	More Details

Interested in more details about testing this protocol?

PPTP

IETF draft
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-pppext-pptp-04.txt

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.
The format of the header is shown in the following illustration:

16	32 bits
Length	PPTP 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?

DHCP

RFC1531http://www.cis.ohio-state.edu/htbin/rfc/rfc1531.html
This RFC has been replaced by RFC 2131.
The information on this page will be updated to suit the new RFC in the near future.

The Dynamic Host Configuration Protocol (DHCP) provides Internet hosts with configuration parameters. DHCP is an extension of BOOTP. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.
(Compliant with IETF RFC1531.)

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

8	16	24	32 bits
Op (1)	Htype (1)	Hlen (1)	Hops (1)
Xid (4 bytes)
Secs (2 bytes)		Flags (2 bytes)
Ciaddr (4 bytes)
Yiaddr (4 bytes)
Siaddr (4 bytes)
Giaddr (4 bytes)
Chaddr (16 bytes)
DHCP header structure

Op
The message operation code. Messages can be either BOOTREQUEST or BOOTREPLY.

Htype
The hardware address type.

Hlen
The hardware address length.

Xid
The transaction ID.

Secs
The seconds elapsed since the client began the address acquisition or renewal process.

Flags
The flags.

Ciaddr
The client IP address.

Yiaddr
The "Your" (client) IP address.

Siaddr
The IP address of the next server to use in bootstrap.

Giaddr
The relay agent IP address used in booting via a relay agent.

Chaddr
The client hardware address.


Enlarge	More Details

Interested in more details about testing this protocol?

DVMRP

RFC 1075: http://www.cis.ohio-state.edu/htbin/rfc/rfc1075.html
IETF draft:
http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-08.txt

Distance Vector Multicast Routing Protocol (DVMRP) is an Internet routing protocol that provides an efficient mechanism for connectionless datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP multicast delivery trees using a technique called Reverse Path Multicasting
DVMRP combines many of the features of RIP with the Truncated Reverse Path Broadcasting (TRPB) algorithm. DVMRP is developed based upon RIP because an implementation was available and distance vector algorithms are simple, as compared to link-state algorithms. In addition, to allow experiments to traverse networks that do not support multicasting, a mechanism called tunneling was developed.
DVMRP differs from RIP in one very important way. RIP routes and forwards datagrams to a particular destination. The purpose of DVMRP is to keep track of the return paths to the source of multicast datagrams. To make the explanation of DVMRP more consistent with RIP, the term destination is used instead of the more proper term source, however, datagrams are not forwarded to these destinations, but rather, originate from them.
DVMRP packets are encapsulated in IP datagrams, with an IP protocol number of 2 (IGMP). All fields are transmitted in Network Byte Order. DVMRP packets use a common protocol header that specifies the IGMP Packet Type as DVMRP. DVMRP protocol packets should be sent with the Precedence field in the IP header set to Internetwork Control (hexadecimal 0xc0 for the Type of Service Octet). The common protocol header is as shown in the following illustration:

8	16	24	32 bits
Type	Code	Checksum
Reserved		Min version	Maj version
DVMRP structure

Type
Packet type. 0x13 indicates a DVMRP packet.

Code
Determines the type of DVMRP packet. Currently, there are codes for DVMRP protocol message types as well as protocol analysis and troubleshooting packets. The protocol message codes may be as follows:
Probe Neighbor discovery.
Report Route exchange.
Prune Pruning multicast delivery trees.
Graft Grafting multicast delivery trees.
Graft ack Acknowledging graft messages.

Checksum
16-bit one's complement of the one's complement sum of the DVMRP message. The checksum must be calculated upon transmission and must be validated on reception of a packet. The checksum of the DVMRP message should be calculated with the checksum field set to zero.

Reserved
Reserved for later use.

Min version
Minor version. Value must be 0xFF for this version of DVMRP.

Maj version
Major version. Value must be 3 for this version of DVMRP.

Interested in more details about testing this protocol?

ICMP

RFC792 http://www.cis.ohio-state.edu/htbin/rfc/rfc792.html
RFC950 http://www.cis.ohio-state.edu/htbin/rfc/rfc950.html

IETF RFC792 defines the Internet Control Message Protocol (ICMP). ICMP messages generally contain information about routing difficulties with IP datagrams or simple exchanges such as time-stamp or echo transactions.

The ICMP header structure is shown as follows:

8	16	32 bits
Type	Code	Checksum
Identifier		Sequence number
Address mask
ICMP header structure

Type	Code	Description
0		Echo reply.
3		Destination unreachable.
3	0	Net unreachable.
3	1	Host unreachable.
3	2	Protocol unreachable.
3	3	Port unreachable.
3	4	Fragmentation needed and DF set.
3	5	Source route failed.
4		Source quench.
5		Redirect.
5	0	Redirect datagrams for the network.
5	1	Redirect datagrams for the host.
5	2	Redirect datagrams for the type of service and network.
5	3	Redirect datagrams for the type of service and host.
8		Echo.
11		Time exceeded.
11	0	Time to live exceeded in transit.
11	1	Fragment reassemble time exceeded.
12		Parameter problem.
13		Timestamp.
14		Timestamp reply.
15		Information request.
16		Information reply.

Checksum
The 16-bit one’s complement of the one’s complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero.

Identifier
An identifier to aid in matching requests/replies; may be zero.

Sequence number
Sequence number to aid in matching requests/replies; may be zero.

Address mask
A 32-bit mask.


Enlarge	More Details

Interested in more details about testing this protocol?

ICMPv6

RFC1885 http://www.cis.ohio-state.edu/htbin/rfc/rfc1885.html
This RFC has been replaced by RFC 2463.
The information on this page will be updated to suit the new RFC in the near future.

RFC1970 http://www.cis.ohio-state.edu/htbin/rfc/rfc1970.html
This RFC has been replaced by RFC 2461.
The information on this page will be updated to suit the new RFC in the near future.

The Internet Control Message Protocol (ICMP) was revised during the definition of IPv6. In addition, the multicast control functions of the IPv4 Group Membership Protocol (IGMP) are now incorporated with the ICMPv6.

The structure of the ICMPv6 header is shown in the following illustration.

8	16	32 bits
Type	Code	Checksum
ICMPv6 header structure

Type
The type of the message. Messages can be error or informational messages. Error messages can be Destination unreachable, Packet too big, Time exceed, Parameter problem. The possible informational messages are, Echo Request, Echo Reply, Group Membership Query, Group Membership Report, Group Membership Reduction.

Code
For each type of message several different codes are defined.
An example of this is the Destination Unreachable message, where possible messages are: no route to destination, communication with destination administratively prohibited, not a neighbor, address unreachable, port unreachable. For further details, refer to the standard.

Checksum
Used to check data corruption in the ICMPv6 message and parts of the IPv6 header.


Enlarge	More Details

Interested in more details about testing this protocol?

1 2 3 4 5 6 7 8 9

Additional Information