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.
Interested in more details about testing this protocol? click here   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? click here   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? click here   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:  
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 (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? click here   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:

8 16 32 bits
T L X X S X O P X X X X VER Length
Tunnel ID SESSION ID
Ns Nr
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).

Interested in more details about testing this protocol? click here   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? click here   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.
Interested in more details about testing this protocol? click here   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? click here   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.
Interested in more details about testing this protocol? click here   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.
Interested in more details about testing this protocol? click here   1 2 3 4 5 6 7 8 9 TCP/IP Family Protocol Information AH | ATMP | ARP/RARP | BGMP | BGP-4 | COPS | DCAP | DHCP | Diameter | DIS | DNS | DVMRP | EGP | EIGRP | ESP | FANP | Finger | FTP | HSRP | HTTP | ICMP/ICMPv6 | IGMP | IGRP | IMAP4 | IMPPpre/IMPPmes | IPDC | IP | IPv6 | IRC | ISAKMP | ISAKMP/IKE | iSCSI | ISTP | ISP | LDAP | L2F | L2TP | MARS | Mobile IP | MZAP | NARP | NetBIOS/IP | NHRP | NTP | OSPF | PIM | POP3 | PPTP | Radius | RLOGIN | RIP2 | RIPng for IPv6 | RSVP | RTSP | RUDP | SCTP | S-HTTP | SLP | SMTP | SNMP | SOCKS | TACACS+ | TALI | TCP | TELNET | TFTP | TLS | TRIP | UDP | Van Jacobson | VRRP | WCCP | X-Window | XOT
Additional Information