TCP / IP Suite

IMPPpre/IMPPmes The Instant Messaging and Presence protocols. Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. “online” or “offline”) of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. These protocols define a minimal set of requirements that IMPP must meet so various existing applications will work together. ASCII messages are Mime encoded. Interested in more details about testing this protocol? click here   IMAP4 RFC2060 RFC2061

The Internet Message Access Protocol, Version 4rev1 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called mailboxes, in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server.

IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.

Interested in more details about testing this protocol? click here

IPDC Internet Drafts: draft-draft-taylor-ipdc-00.txt, draft-calhoun-diameter-07.txt

IP Device Control (IPDC) is a family of protocols, components of which can be used individually or together to perform connection control, media control, and signalling transports. It fulfills a need for one or more protocols to control gateway devices which sit at the boundary between the circuit- switched telephone network and the internet and terminate circuit- switched trunks. Examples of such devices include network access servers and voice-over-IP gateways. The need for a control protocol separate from call signalling arises when the service control logic needed to process calls lies partly or wholly outside the gateway devices. IPDC was build on the base structure provided by the DIAMETER protocol which was specifically written for authentication, authorization, and accounting applications.

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

Radius PCC (1 byte) PKT (5 bits) Ver (3 bits) Packet Length (2 bytes)
Identifier (4 bytes)
 Sequence number Next Received (Nr) (2 bytes)
1 byte 1 byte 1 byte 1 byte
IPDC structure
Radius PCC Packet Compatibility Code (PCC) field is used for RADIUS backward compatibility. In order to easily distinguish DIAMETER/IPDC messages from RADIUS a special value has been reserved and allows an implementation to support both protocols concurrently using the first octet in the header. The RADIUS PCC field must be set to 254, DIAMETER/IPDC message.   PKT Flags Packet Flags are used to identify any options. Version Version number associated with the packet received. This field is set to 1 to indicate IPDC version 1. Packet Length Indicates the length of the message including the header fields. Identifier Aids in matching requests and replies. Next Send This field is present when the Window-Present bit is set in the header flags. The Next Send (Ns) is copied from the send sequence number state variable (Ss) at the time the message is transmitted. Next Received This field is present when the Window-Present bit is set in the header flags. Nr is copied from the receive sequence number state variable (Sr) and indicates the sequence number (Ns) +1 of the highest (modulo 2^16) in-sequence message received. Attributes IPDC Attributes carry the specific commands and parameters which must be exchanged between IPDC protocol endpoints to perform the tasks associated with Media Gateway control. Interested in more details about testing this protocol? click here   IRC

The IRC (Internet Relay Chat protocol) supports a worldwide network of servers and clients, and is stringing to cope with growth. It is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.

The IRC protocol was developed on systems using the TCP/IP network protocol, although there is no requirement that this remain the only sphere in which it operates. It is a teleconferencing system, which (through the use of the client-server model) is well-suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions. Servers and clients send each other messages which may or may not generate a reply. If the message contains a valid command, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous in nature. Each IRC message may consist of up to three main parts: the prefix (optional), the command, and the command parameters (of which there may be up to 15). The prefix, command, and all parameters are separated by one (or more) ASCII space character(s) (0x20). Messages are as follows: Server/Nick_Name The Server/Nick_Name. User The user name. Host The host name.

Interested in more details about testing this protocol? click here




The Internet Message Access Protocol, version 4rev1 (ISAKMP) defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.

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

Initiator cookie (8 bytes)
Responder cookie (8 bytes)
Next payload (1 byte) MjVer (4 bits) MnVer (4 bits) Exchange Type (1 byte) Flags (1 byte)
Message ID (4 bytes)
Length (4 bytes)
1 byte 1 byte 1 byte 1 byte
ISAKMP structure
Initiator cookie Cookie of entity that initiated SA establishment, SA notification, or SA deletion. Responder cookie Cookie of entity is responding to an SA establishment, SA notification, or SA deletion. Next payload Indicates the type of the first payload in the message. Possible types are:
0 None
1 Security Association (SA)
2 Proposal (P)
3 Transform (T)
4 Key Exchange (KE)
5 Identification (ID)
6 Certificate (CERT)
7 Certificate Request (CR)
8 Hash (HASH)
9 Signature (SIG)
10 Nonce (NONCE)
11 Notification (N)
12 Delete (D)
13 Vendor ID (VID)
14-127 Reserved
128-255 Private use
MjVer Major Version indicates the major v ersion of the ISAKMP protocol in use. Implementations based RFC2408 must set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet- Drafts must set the Major Version to 0. Implementations should never accept packets with a major version number larger than its own. MnVer Minor Version – indicates the minor version of the ISAKMP protocol in use. Implementations based RFC2408 must set the minor version to 0. Implementations based on previous versions of ISAKMP Internet- Drafts must set the minor version to 1. Implementations should never accept packets with a minor version number larger than its own. Exchange Type The type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges. Possible values are:
0 None
1 Base
2 Identity Protection
3 Authentication Only
4 Aggressive
5 Informational
6-31 ISAKMP Future Use
32-239 DOI Specific Use
240-255 Private Use
Flags Specific options that are set for the ISAKMP exchange. E(ncryption bit) (bit 0) – specifies that all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. C(ommit bit) (bit 1) – signals key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. A(uthentication Only Bit) (bit 2) – intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption. All remaining bits are set to 0 before transmission. Message ID Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e., collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value must be set to 0. Length Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. Interested in more details about testing this protocol? click here  


10262_hsc104 06. ISP is a transport mechanism for the applications running on top of this version (version 3) of the protocol. ISP is divided into a Master Protocol TRH and various sub protocols: CM, SDM, SCM, DAM, BRM and MGM. The information set by the protocol will be used for routing of messages between two mated applications residing in the two nodes, i.e. the AXD 301 and the AXE. The header structure is as follows:
Message ID
Protocol Decode Message ID The master protocol message ID. This field splits to the appropriate message of the TRH protocol. The following TRH messages are available:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 HeartBeat HeartBeatAck PointAssocCon PointAssocConAck PointAssocDisc PointAssocDiscReq PointAssocInfo PointAssocInfoReq PrefLinkAck PrefLinkReq UserConnectAck UserConnectRej UserConnectReq UserDataTransport UserDisconnect UserDisconnectAck VersionSync VersionSyncAck UserDataTransportATOverload
Length The number of octets that the element has. Interested in more details about testing this protocol? click here   NTP

RFC1059 RFC1119 RFC1305

The Network Time Protocol (NTP) is a time synchronization system for computer clocks through the Internet network. It provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to light wave. It uses a returnable time design in which a distributed sub network of time servers, operating in a self-organizing, hierarchical master-slave configuration, synchronize logical clocks within the sub network and to national time standards via wire or radio.

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

7 bits
NTP header structure
LI Leap Indicator A 2-bit code warning of impending leap-second to be inserted at the end of the last day of the current month. Bits are coded as follows:
00 No warning.
01 +1 second (following minute has 61 seconds).
10 -1 second (following minute has 59 seconds).
11 Alarm condition (clock not synchronized).
VN Version number 3 bit code indicating the version number. Mode The mode: This field can contain the following values:
0 Reserved.
1 Symmetric active.
3 Client.
4 Server.
5 Broadcast.
6 NTP control message.
Stratum An integer identifying the stratum level of the local clock. Values are defined as follows:
0 Unspecified.
1 Primary reference (e.g. radio clock).
2…n Secondary reference (via NTP).
Poll Signed integer indicating the maximum interval between successive messages, in seconds to the nearest power of 2. Precision Signed integer indicating the precision of the local clock, in seconds to the nearest power of 2. Interested in more details about testing this protocol? click here   POP3


The Post Office Protocol version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host. It is usually used to allow a workstation to retrieve mail that the server is holding for it.

POP3 transmissions appear as data messages between stations. The messages are either command or reply messages.

Interested in more details about testing this protocol? click here


RFC2138 RFC2139

Radius is a protocol which manages dispersed serial line and modem pools for large numbers of users. (Compliant with IETF RFC2138 and RFC2139.)

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

32 bits
Authenticator (16 bytes)
Radius header structure
Code The message type. Identifier The identifier matches requests and replies. Length The message length including the header. Authenticator A field used to authenticate the reply from the radius server and in the password hiding algorithm.
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