TCP / IP Suite

IMPPpre/IMPPmes

ftp://ftp.rfc-editor.org/in-notes/rfc2779.txt
ftp://ftp.rfc-editor.org/in-notes/rfc2426.txt

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?

IMAP4

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?

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:

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?

IRC

ftp://ftp.rfc-editor.org/in-notes/rfc1459.txt

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?

ISAKMP

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

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:

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?

ISP

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:

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:

Length
The number of octets that the element has.
Interested in more details about testing this protocol?

NTP

RFC1059 http://www.cis.ohio-state.edu/htbin/rfc/rfc1059.html
RFC1119 http://www.cis.ohio-state.edu/htbin/rfc/rfc1119.html
RFC1305 http://www.cis.ohio-state.edu/htbin/rfc/rfc1305.html

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:

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:

VN
Version number 3 bit code indicating the version number.

Mode
The mode: This field can contain the following values:

Stratum
An integer identifying the stratum level of the local clock. Values are defined as follows:

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?

POP3

RFC1939 http://www.cis.ohio-state.edu/htbin/rfc/rfc1939.html

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?

Radius

RFC2138 http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html
RFC2139 http://www.cis.ohio-state.edu/htbin/rfc/rfc2139.html

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:

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.

Enlarge	More Details

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