TCP / IP Suite


IETF RFC 1112 1989-08 RFC2236 Internet Draft

The Internet Group Management Protocol (IGMP) is used by IP hosts to report their host group memberships to any immediately neighboring multicast routers. IGMP is a integral part of IP. It must be implemented by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2.Version 3 of IGMP adds support for source filtering. This indicates the ability for a system to report interest in receiving packets;only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address.

The format of the IGMP packet is shown in the following illustration:
32 bits
Max response time
Group address
IGMP packet structure

Version The protocol version.

  Type The message type:
0x11 Membership query. There are 2 sub-types of membership queries, general query and group-specific query.
0x16 Version 2 membership report.
0x17 Leave group.
0x12 Version 1 membership report. Provides compatibility with IGMPv1.
0x22 Version 3 membership report.
Max Response Time Used only in Membership query messages. Specifies the maximum time allowed before sending a responding report in units of 1/10 second. In all other messages, it is set to 0 by the sender and ignored by the receiver. Checksum The checksum.

Group Address In a Membership query message, The Group address is set to 0 when sending a general query. It is set to the group address being queried, when sending a group specific query or group-and-source-specific query. In a membership report of a leave group message, it holds the IP multicast group address of the group being reported or left.

IGMP Version Membership Report Messages IGMP Version Membership Report messages have the following format:

8 16 32 bits
Type Reserved Checksum
Reserved Number of group record
Group record
Group record
Group record
Group record

Type The Type field has a value of 21.

Reserved. Set to zero on transmission, and ignored on reception.

Checksum The Checksum is the 16-bit one’s complement of the one’s complement sum of the whole IGMP message.

Number of Group Records (M) The number of Group records present in this report.

Group Record A block of fields containing information about the sender’s membership in a single multicast group, on the interface from which the report is sent.

Group Record Type There are a number of different types of Group Records that may be included in a Report message:

Current-State Record, which has the following record types:
1. Include mode 2. Exclude mode Filter-Mode-Change Record, which has the following two record types: 3. Change to Include Mode 4. Change to Exclude Mode Source-List-Change Record, which has the following two record types: 5. Allow New Sources 6. Block Old Sources

Interested in more details about testing this protocol? click here



Multicasting is the process whereby a source host or protocol entity sends a packet to multiple destinations simultaneously using a single, local ‘transmit’ operation. ATM is being utilized as a new link layer technology to support a variety of protocols, including IP. The MARS protocol has two broad goals: to define a group address registration and membership distribution mechanism that allows UNI 3.0/3.1 based networks to support the multicast service of protocols such as IP and to define specific endpoint behaviors for managing point to multipoint VCs to achieve multicasting of layer 3 packets. The Multicast Address Resolution Server (MARS) is an extended analog of the ATM ARP Server. It acts as a registry, associating layer 3 multicast group identifiers with the ATM interfaces representing the group’s members. MARS messages support the distribution of multicast group membership information between MARS and endpoints (hosts or routers). Endpoint address resolution entities query the MARS when a layer 3 address needs to be resolved to the set of ATM endpoints making up the group at any one time. Endpoints keep the MARS informed when they need to join or leave particular layer 3 groups. To provide for asynchronous notification of group membership changes, the MARS manages a point to multipoint VC out to all endpoints desiring multicast support. Each MARS manages a cluster of ATM-attached endpoints. (Compliant with IETF RFC2022.)

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

Address family (2 bytes)
Protocol identification (7 bytes)  
Reserved (3 bytes)
Checksum (2 bytes)
Extensions offset (2 bytes)
Operation code (2 bytes)
Type and length of source ATM number (1 byte)
Type and length of source ATM subaddress (1 byte)
MARS header structure
Address family Defines the type of link layer addresses being carried. Protocol ID Contains 2 subfields: 16 bits, protocol type 40 bits Optional SNAP extension to protocol type. Reserved This reserved field may be subdivided and assigned specific meanings for other control protocols indicated by the version number. Checksum This field carries a standard IP checksum calculated across the entire message. Extension offset This field identifies the existence and location of an optional supplementary parameters list. Operation code This field is divided into 2 sub fields: version and type. Version indicates the operation being performed, within the context of the control protocol version indicated by mar$op.version. Type and length of ATM source number Information regarding the source hardware address. Type and length of ATM source subaddress Information regarding the source hardware subaddress. Interested in more details about testing this protocol? click here   PIM


Protocol Independent Multicast-Sparse Mode (PIM-SM) is a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. The protocol is not dependent on any particular unicast routing protocol, and is designed to support sparse groups.

PIM version Type Reserved Checksum
PIM header structure

Address length in new standard appears as reserved.

Parameters PIM frames have the following parameters: PIM version Current PIM version is 2. Type Types for specific PIM messages.

0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft (used in PIM-DM only) 7 = Graft-Ack (used in PIM-DM only) 8 = Candidate-RP-Advertisement

Address length Address length in bytes. The length of the address field throughout, in the specific message. Reserved (the value of this field is set to 0, ignore on receipt) Checksum The 16-bit one’s complement, of the one’s complement sum of the entire PIM message (excluding the data portion in the register message). For computing the checksum, the checksum field is zeroed. Interested in more details about testing this protocol? click here   RIP2

RFC1058 RFC1528 RFC1723 This RFC has been replaced by RFC 2453. The information on this page will be updated to suit the new RFC in the near future.

RIP2 (Routing Information Protocol) is used by Berkeley 4BSD UNIX systems to exchange routing information. Implemented by a UNIX program, RIP2 derives from an earlier protocol of the same name developed by Xerox.

RIP2 is an extension of the Routing Information Protocol (RIP) intended to expand the amount of useful information carried in the RIP2 messages and to add a measure of security.

RIP2 is a UDP-based protocol. Each host that uses RIP2 has a routing process that sends and receives datagrams on UDP port number 520. The packet format of RIP2 is shown in the illustration below.

32 bits
Address family identifier
Route tag (only for RIP2; 0 for RIP)
IP address
Subnet mask (only for RIP2; 0 for RIP)
Next hop (only for RIP2; 0 for RIP)
RIP2 packet structure

The portion of the datagram from Address Family Identifier through Metric may appear up to 25 times.

Command The command field is used to specify the purpose of this datagram:

1. Request: A request for the responding system to send all or part of its routing table.
2. Response: A message containing all or part of the sender’s routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.
3. Traceon: Obsolete. Messages containing this command are to be ignored.
4. Traceoff: Obsolete. Messages containing this command are to be ignored.
5. Reserved: Used by Sun Microsystems for its own purposes.

Version The RIP version number. Datagrams are processed according to version number, as follows:

0 Datagrams whose version number is zero are to be ignored.
1 Datagrams whose version number is one are processed. All fields that are to be 0, are to be checked. If any such field contains a non-zero value, the entire message is ignored.
2 Specifies RIP messages which use authentication or carry information in any of the newly defined fields.
>2 Datagrams whose version numbers are greater than 1 are processed. All fields that are 0 are ignored.

Address family identifier Indicates what type of address is specified in this particular entry. This is used because RIP2 may carry routing information for several different protocols. The address family identifier for IP is 2.

When authentication is in use, the Address Family Identifier field will be set to 0xFFFF, the Route Tag field contains the authentication type and the remainder of the message contains the password.

Route tag Attribute assigned to a route which must be preserved and readvertised with a route. The route tag provides a method of separating internal RIP routes (routes for networks within the RIP routing domain) from external RIP routes, which may have been imported from an EGP or another IGP.

IP address The IP address of the destination.

Subnet mask Value applied to the IP address to yield the non-host portion of the address. If zero, then no subnet mask has been included for this entry.

Next hop Immediate next hop IP address to which packets to the destination specified by this route entry should be forwarded.

Metric Represents the total cost of getting a datagram from the host to that destination. This metric is the sum of the costs associated with the networks that would be traversed in getting to the destination.

Interested in more details about testing this protocol? click here

RIPng for IPv6


RIPng for IPv6 is a routing protocol for the IPv6 Internet. It is based on protocols and algorithms used extensively in the IPv4 Internet. (Compliant with IETF RFC2080 1997-01.)

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

Command (1)
Version (1 byte)
0 (2 bytes)
Route table entry 1 (20 bytes)
. . .
Route table entry N (20 bytes)
RIPng for IPv6 header structure
Command The purpose of the message. Possible commands are:
Request: A request for the responding system to send all or part of its routing table
Response: A message containing all or part of the sender’s routing table.

Version The version of the protocol. The current version is version 1.

Route table entry Each route table entry contains a destination prefix, the number of significant bits in the prefix and the cost of reaching that destination.

Interested in more details about testing this protocol? click here


draft draft

RFC2205 RFC2750

RSVP is a Resource ReSerVation setup Protocol designed for an integrated services Internet. It is used by a host on behalf of an application data stream to request a specific quality of service from the network for particular data streams or flows. It is also used by routers to deliver QoS control requests to all nodes. (Compliant with IETF draft-ietf-rsvp-spec-13.txt 08-1996 and IETF draft-ietf-rsvp-md5-02.txt 06-199.)

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

32 bits
Message type
RSVP checksum
Send TTL
RSVP length
RSVP header structure
Version The protocol version number, this is version 1.

Flags No flag bits are defined yet.

Message type Possible values are:

1 Path.
2 Resv.
3 PathErr.
4 ResvErr.
5 PathTear.
6 ResvTear.
7 ResvConf.

RSVP checksum The checksum.

Send TTL The IP TTL value with which the message was sent.

RSVP length The total length of the RSVP message in bytes, including the common header and the variable length objects that follow.

Interested in more details about testing this protocol? click here


(VRRP) specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. This protocol is intended for use with IPv4 routers only. VRRP packets are sent encapsulated in IP packets.

The structure of the VRRP packet is:

0 7 15 23
Version Type Virtual Rtr ID Priority Count IP Addrs
Auth Type Advet Int Checksum
IP Address (1)
IP Address (n)
Authentication Data (1)
Authentication Data (2)

Version The version field specifies the VRRP protocol version of this packet. This version is version 2.

Type The type field specifies the type of this VRRP packet. The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT. A packet with an unknown type must be discarded.

Virtual Rtr ID The Virtual Router Identifier (VRID) field identifies the virtual router this packet is reporting status for.

Priority Specifies the sending VRRP router’s priority for the virtual router. VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal).

Count IP Addresses The number of IP addresses contained in this VRRP advertisement.

Auth Type Identifies the authentication method being utilized.

Authentication Methods

0          No Authentication 1          Simple Text Password 2          IP Authentication Header

Advertisement Interval Indicates the time interval (in seconds) between advertisements.

Checksum Used to detect data corruption in the VRRP message. The checksum is the 16-bit one’s complement of the one’s complement sum of the entire VRRP message starting with the version field. For computing the checksum, the checksum field is set to zero.

IP Address(es) One or more IP addresses that are associated with the virtual router. The number of addresses included is specified in the “Count IP Addrs” field. These fields are used for troubleshooting misconfigured routers.

Authentication Data The authentication string is currently only utilized for simple text authentication, similar to the simple text authentication found in the Open Shortest Path First routing protocol (OSPF). It is up to 8 characters of plain text.

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