TCP / IP Suite

IGMP

IETF RFC 1112 1989-08http://www.cis.ohio-state.edu/htbin/rfc/rfc1112.html
RFC2236 http://www.cis.ohio-state.edu/htbin/rfc/rfc2236.html
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:

Type
The message type:

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:

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

Enlarge	More Details

Interested in more details about testing this protocol?

MARS

RFC2022 http://www.cis.ohio-state.edu/htbin/rfc/rfc2022.html

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

PIM

RFC2362 ftp://ftp.isi.edu./in-notes/rfc2362.txt

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.

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?

RIP2

RFC1058 http://www.cis.ohio-state.edu/htbin/rfc/rfc1058.html
RFC1528 http://www.cis.ohio-state.edu/htbin/rfc/rfc1528.html
RFC1723 http://www.cis.ohio-state.edu/htbin/rfc/rfc1723.html
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.

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:

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

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?

RIPng for IPv6

RFC2080 http://www.cis.ohio-state.edu/htbin/rfc/rfc2080.html

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
The purpose of the message. Possible commands are:

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?

RSVP

draft http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-rsvp-spec-16.txt
draft http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-rsvp-md5-06.txt

RFC2205 http://www.cis.ohio-state.edu/htbin/rfc/rfc2205.html
RFC2750 http://www.cis.ohio-state.edu/htbin/rfc/rfc2750.html

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:

Version
The protocol version number, this is version 1.

Flags
No flag bits are defined yet.

Message type
Possible values are:

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.

Enlarge	More Details

Interested in more details about testing this protocol?

VRRP

ftp://ftp.isi.edu/in-notes/rfc2338.txt 

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

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?

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