TCP / IP Suite

BGMP

http://search.ietf.org/

The Border Gateway Multicast Protocol (BGMP) maintains a group-prefix state in response to messages from BGMP peers and notifications from M-IGP components. Group-shared trees are rooted at the domain advertising the group prefixes covering those groups. When a receiver joins a specific group address, the border router towards the root domain generates a group-specific Join message, which is then forwarded Border-Router-by-Border-Router towards the root domain. BGMP Join and Prune messages are sent over TCP connections between BGMP peers, and the BGMP protocol state is refreshed by KEEP ALIVE messages periodically sent over TCP.
BGMP routers build group-specific bidirectional forwarding state as they process the BGMP Join messages. Bidirectional forwarding state means that packets received from any target are forwarded to all other targets in the target list without any RPF checks. No group-specific state or traffic exists in parts of the network where there are no members of that group.

Protocol Header Structure

The description of the protocol header is as follows:

Length
The total length of the message including the header in octets.

Type
The type code of the message. The following type codes are available:

Interested in more details about testing this protocol?

Diameter

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

The Diameter base protocol provides an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter also works in both local AAA and roaming situations. Diameter runs over reliable transport mechanisms (TCP, SCTP) as defined in [AAATRANS]. The Diameter base protocol provides the following facilities:

• Delivery of AVPs (attribute value pairs)
• Capabilities negotiation
• Error notification
• Extensibility, through addition of new commands and AVPs (required in [AAAREQ]).
• Basic services necessary for applications, such as handling of user sessions or accounting.

All data delivered by the protocol is in the form of an AVP. Some of these AVP values are used by the Diameter protocol itself, while others deliver data associated with particular applications that employ Diameter. AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs that are explicitly excluded are not included. AVPs are used by the base Diameter protocol to support the following required features:

• Transporting of user authentication information, to purpose enable the Diameter server to authenticate the user.
• Transporting of service specific authorization information, between client and servers, allowing the peers to decide whether a user's access request should be granted.
• Exchanging resource usage information, which may be used for Relaying, proxying and redirecting of Diameter messages through a server hierarchy.

The structure of the Diameter protocol header is as follows:

Version
The Diameter version, currently 1.

Message Length
The entire message length.

Command Flags
The command flag; the following flags appear: Request/Response, Proxiable/Not Proxiable, Error/No Error.

Command Code
The Command-Code field is three octets, and is used in order to communicate the command associated with the message.
The following command codes are defined:

Application ID
The identification of the application to which the message is applicable. The application can be an authentication application, an accounting application or a vendor specific application.

Hop-by-Hop Identifier
Unsigned 32-bit integer field that aids in matching requests and replies.

End-to-End Identifier
Used to detect duplicate messages.

AVPs
AVPs are a method of encapsulating information relevant to the diameter message
The following AVPs exist:

Interested in more details about testing this protocol?

DIS

Protocol Standard: IEEE Std 1278.1-1995 www.ieee.org/portad/index.asp

Distributed Interactive Simulation (DIS) is a government/industry initiative to define an infrastructure for linking simulations of various types at multiple locations to create realistic, complex, virtual worlds for the simulation of highly interactive activities. This infrastructure brings together systems built for separate purposes, technologies from different eras, products from various vendors, and platforms from various services, and permits them to interoperate. DIS exercises support a mixture of virtual entities with computer controlled behavior (computer generated forces), virtual entities with live operators (human in-the-loop simulators), live entities (operational platforms and test and evaluation systems), and constructive entities (wargames and other automated simulations). DIS draws heavily on experience derived from the Simulator Networking (SIMNET) program developed by the Advanced Research Projects Agency (ARPA), adopting many of SIMNETs basic concepts and heeding lessons learned.
The DIS protocol header is as follows:

Protocol Version
The 8-bit enumeration for the Protocol-Version field

Exercise ID
The exercise to which the PDU pertains. It is represented by an Exercise Identifier

PDU Type
The 8-bit enumeration for the PDU-Type field

Protocol Family
The 8-bit enumeration for the Protocol-Family field

Timestamp
Indicates the time at which the data contained in the PDU was generated.

Length
The number of octets from and including the first octet of the header to and including the last octet of the PDU.

Padding
Reserved to bring the record length to a desired alignment

Interested in more details about testing this protocol?

DNS

RFC1035 http://www.cis.ohio-state.edu/htbin/rfc/rfc1035.html
RFC1706 http://www.cis.ohio-state.edu/htbin/rfc/rfc1706.html

The Domain Name Service (DNS) protocol searches for resources using a database distributed among different name servers.

The DNS message header structure is shown in the following illustration:

ID
16-bit field used to correlate queries and responses.

Q
1-bit field that identifies the message as a query or response.

Query
4-bit field that describes the type of message:

A
Authoritative Answer. 1-bit field. When set to 1, identifies the response as one made by an authoritative name server.

T
Truncation. 1-bit field. When set to 1, indicates the message has been truncated.

R
1-bit field. Set to 1 by the resolve to request recursive service by the name server.

V
1-bit field. Signals the availability of recursive service by the name server.

B
3-bit field. Reserved for future use. Must be set to 0.

RCode
Response Code. 4-bit field that is set by the name server to identify the status of the query:

Question count
16-bit field that defines the number of entries in the question section.

Answer count
16-bit field that defines the number of resource records in the answer section.

Authority count
16-bit field that defines the number of name server resource records in the authority section.

Additional count
16-bit field that defines the number of resource records in the additional records section.

Enlarge	More Details

Interested in more details about testing this protocol?

ISAKMP/IKE
ftp://ftp.rfc-editor.org/in-notes/rfc2407.txt.
ftp://ftp.rfc-editor.org/in-notes/rfc2408.txt
ftp://ftp.rfc-editor.org/in-notes/rfc2409.txt


The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. It combines the security concepts of authentication, key management, and security associations to establish the required security for government, commercial, and private communications on the Internet.

Within ISAKMP, a Domain of Interpretation (DOI) is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads.
Overall, ISAKMP places the following requirements on a DOI definition to define the following:

• Naming scheme for DOI-specific protocol identifiers
• Interpretation for the Situation field
• Set of applicable security policies
• Syntax for DOI-specific SA Attributes (Phase II)
• Syntax for DOI-specific payload contents
• Additional Key Exchange types, if needed
• Additional Notification Message types, if needed

The protocol header structure is as follows:

Initiator Cookie
The Initiator Cookie: Cookie of the entity that initiated SA establishment, SA notification, or SA deletion

Responder Cookie
The Responder Cookie: Cookie of the entity that is responding to an SA establishment request, SA notification, or SA deletion.

Next Payload
The type of the next payload in the message. The following payload types are available:

Major Version
The major version of the ISAKMP protocol in use.

Minor Version
The minor version of the ISAKMP protocol in use.

Exchange Type
The type of exchange being used The following exchange types are available:

Flags
Various options that are set for the ISAKMP exchange.

Message ID
A Unique Message Identifier used to identify protocol state during Phase 2 negotiations.

Length
Length of total message (header + payloads) in octets.

ISAKMP provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. The Internet Key Exchange (IKE) is one of a series of key exchanges—called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication) which can be used in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI.

Interested in more details about testing this protocol?

iSCSI

http://search.ietf.org/

The iSCSI (Small Computer Systems Interface) protocol is a mapping of the SCSI remote procedure invocation model over the TCP protocol. SCSI commands are carried by iSCSI requests and SCSI responses and status are carried by iSCSI responses. iSCSI also uses the request response mechanism for iSCSI protocol mechanisms.
The protocol header appears as follows:

Opcode
The type of iSCSI PDU the header encapsulates.

TotalAHSLength
Total Length of all AHS header segments in four byte words including padding, if any.

Data SegmentLength
Data segment payload length in bytes excluding padding.

LUN
Some opcodes operate on a specific Logical Unit. The Logical Unit Number (LUN) field identifies which Logical Unit.

InitTaskTag
The initiator assigns a Task Tag to each iSCSI task it issues.

Interested in more details about testing this protocol?

FANP

RFC: 2129 http://www.cis.ohio-state.edu/htbin/rfc/rfc2129.html

The Flow Attribute Notification Protocol is a protocol between neighbor modes which manages cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn’t perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node. It helps a pair of nodes manage mapping information. By using FANP, routers such as the CSR (Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. FANP has the following characteristics:

• Soft-state, cut-through path (Dedicated-VC) management
• Protocol between neighbor nodes instead of end-to-end
• Applicable to any connection-oriented, datalink platform.

FANP generally runs on ATM networks.

There are 7 FANP control messages. They are encapsulated into IP packets, apart from the PROPOSE message which uses an extended ATM ARP message format. The destination IP address in the IP packet header signifies the neighbor node’s IP address. The source IP address is the sender’s IP address. The IP protocol ID is 110.
The following message format exists for: Offer, Ready and Error messages. Propose Ack, Remove and Remove Ack messages do not have the flow ID field.

Version
The Version number. This version is version 1.

OpCode
This is the message operation code. The following OpCode values exist:
1    Propose Ack
2    Offer
3    Ready
4    Error
5    Remove
6    Remove ACK

Checksum
A 16 bit checksum for the whole message.

VCID type
The type of VCID. The current value is defined as 1. The VCID uniquely identifies the datalink connection between neighbor nodes.

Flow ID
The value of the Flow ID field determines the Flow ID field format. If the Flow ID is 0, then the flow ID field is null. If the Flow ID is 1, then the Flow ID field described below is present.

Reserved
This field is reserved. In Offer messages the Refresh Timer field appears here. In error messages, the Error code field appears here.

Refresh timer
The interval of the Refresh timer, in seconds. (Only appears in Offer messages.) The recommended value is 120.

Error code
Only appears in Error Messages. The following error codes exist:
1 Unknown VCID type
2 Unknown Flow-ID type
3 Unknown VCID
4 Resource unavailable
5 Unavailable Refresh Interval offered
6 Refuse by policy

Flow ID
The Flow ID field does not appear in propose ACK, Remove and Remove Ack messages. When there is a flow ID type value of 1, this field contains the source and destination IP addresses of the flow.

Interested in more details about testing this protocol?

NetBIOS/IP

RFC1002 http://www.cis.ohio-state.edu/htbin/rfc/rfc1002.html

NetBIOS/IP is a standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and Internet operations are supported. Various node types are defined to accommodate local and Internet topologies and to allow operation with or without the use of IP broadcast.
(Compliant with NETBIOS over IP 1992, IETF RFC1002 1987.)

NetBIOS types may be Name Service, Session or Datagram.

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

Name_trn_id
Transaction ID for the Name Service Transaction.

Opcode
Packet type code: Possible values are:

Nm_flags
Flags for operation.

Rcode
Result codes of request.

Qdcount
Unsigned 16 bit integer specifying the number of entries in the question section of a name.

Ancount
Unsigned 16 bit integer specifying the number of resource records in the answer section of a name service packet.

Nscount
Unsigned 16 bit integer specifying the number of resource records in the authority section of a name service packet.

Arcount
Unsigned 16 bit integer specifying the number of resource records in the additional records section of a name service packet.

Interested in more details about testing this protocol?

LDAP

The LDAP (Lightweight Directory Access Protocol.) provides access to X.500 directories without using the DAP (Directory Access Protocol). It is used for simple management applications and browser applications that provide simple read/write interactive access to the X.500 directory and should complement the DAP. X.500 technology has proved to be highly popular, and therefore led to efforts to reduce the high ?cost of entry? associated with it. Until now methods suggested were based on specific applications and, as such, were limited. The LDAP is also a directory protocol alternative, but it is not dependant on a particular application. As such it is intended to be simpler and less expensive than existing ones.

Main features:

• Protocol elements are carried directly over TCP or any other transport layer protocol.
• Protocol data elements are encoded in ordinary strings.
• Lightweight BER encoding is used to encode all protocol elements.

LDAP works by a client transmitting a request to a server. In the request the client specifies the operation to be performed. The server must then perform the required operation on the directory. After this, the server returns a response containing the results, or any errors.

LADP messages are PDUs mapped directly onto the TCP bytestream and use port 389.

The LDAP messages do not have their own header and are text based messages based on ASN.1

Interested in more details about testing this protocol?

MZAP
ftp://ftp.isi.edu/in-notes/rfc2776.txt.

The Multicast-Scope Zone Announcement Protocol (MZAP) is used to discover the multicast administrative scope zones that are relevant at a particular location. MZAP also provides mechanisms whereby common misconfigurations of administrative scope zones can be discovered. The use of administratively-scoped IP multicast, allows packets to be addressed to a specific range of multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for IPv4) such that the packets will not cross configured administrative boundaries, and also allows such addresses to be locally assigned and hence are not required to be unique across administrative boundaries.

This property of logical naming both allows for address reuse, aswell as providing the capability for infrastructure services such asaddress allocation, session advertisement, and service location to use well-known addresses which are guaranteed to have local significance within every organization.

The range of administratively-scoped addresses can be subdivided by administrators so that multiple levels of administrative boundaries can be simultaneously supported. As a result, a "multicast scope" is defined as a particular range of addresses which has been given some topological meaning.

To support such usage, a router at an administrative boundary is configured with one or more per-interface filters, or "multicast scope boundaries". Having such a boundary on an interface means that it will not forward packets matching a configured range of multicast addresses in either direction on the interface.

All MZAP messages are sent over UDP, with a destination port of [MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
The protocol header of MZAP messages is as follows:

Version
The version number; currently defined as 0.

B
Big Scope bit
0-Indicates that the addresses in the scoped range are not subdividable, and that address allocators may utilize the entire range.
1- Address allocators should not use the entire range, but should learn an appropriate sub- range via another mechanism.

Packet Type
The packet types defined are:

0: Zone Announcement Message (ZAM)
1: Zone Limit Exceeded (ZLE)
2: Zone Convexity Message (ZCM)
3: Not-Inside Message (NIM)

Address Family
Identifies the address family for all addresses in the packet. The families defined for IP are:

1: IPv4
2: IPv6

Name Count
The number of encoded zone name blocks in this packet. The count may be zero.

Message Origin
The IP address of the interface that originated the message.

Zone Start Address
The start address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,then Zone Start Address is 239.1.0.0.

Zone End Address
The ending address for the scope zone boundary. For example, if the zone is a boundary for 239.1.0.0 to 239.1.0.255,then Zone End Address is 239.1.0.255.

Zone ID Address
The lowest IP address of a boundary router that has been observed in the zone originating the message. Together with Zone Start Address and Zone End Address, it forms a unique ID for the zone. Note that this ID is usually different from the ID of the Local Scope zone in which the origin resides.

Encoded Zone Name
Combined from the next fields: D, LangLen, Language Tag, NameLen, Zone Name.

Interested in more details about testing this protocol?

COPS

The COPS (Common Open Policy Service) protocol describes a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). It is designed to be extensible so that other kinds of policy clients may be supported in the future. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. Each message consists of the COPS header followed by a number of typed objects.

The structure of the COPS header is:

Version
The version field specifies the COPS version number. The current version is 1.

Flags
The defined flag values is 1 a Solicited Message Flag Bit. This flag is set when the message is solicited by another COPS message.(all other flags MUST be set to 0).

Op Code
Code identifying the COPS operations:
1          Request (REQ)
2          Decision (DEC)
3          Report State (RPT)
4          Delete Request State (DRQ)
5          Synchronize State Req (SSQ)
6          Client-Open (OPN)
7          Client-Accept (CAT)
8          Client-Close (CC)
9          Keep-Alive (KA)
10        Synchronize Complete (SSC)

Client-type
The Client-type identifies the policy client. Interpretation of all encapsulated objects is relative to the client-type.

Message length
Size of message in octets, which includes the standard COPS header and all encapsulated objects. Messages MUST be aligned on 4 octet intervals.

COPS Specific Object formats
After the COPS header comes all encapsulated objects that follow the same object format.

Each object consists of one or more 32-bit words with a four-octet header, using the following format:

Length
The length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding MUST be added to the end of the object so that it is aligned to the next 32- bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary.

C-Num
Identifies the class of information contained in the object.

The possible values for the C-number are

C-type
Identifies the subtype or version of the information contained in the object.

Object contents
The value appearing in the C-Num fields, defines the type of object contents. See the list above for possible object contents.

Interested in more details about testing this protocol?

FTP

RFC959 http://www.cis.ohio-state.edu/htbin/rfc/rfc959.html
RFC2228 http://www.cis.ohio-state.edu/htbin/rfc/rfc2228.html
RFC2640 http://www.cis.ohio-state.edu/htbin/rfc/rfc2640.html

The File Transfer Protocol (FTP) provides the basic elements of file sharing between hosts. FTP uses TCP to create a virtual connection for control information and then creates a separate TCP connection for data transfers. The control connection uses an image of the TELNET protocol to exchange commands and messages between hosts.

Commands

FTP control frames are TELNET exchanges and can contain TELNET commands and option negotiation. However, most FTP control frames are simple ASCII text and can be classified as FTP commands or FTP messages. The standard FTP commands are as follows:

Messages

FTP messages are responses to FTP commands and consist of a response code followed by explanatory text. Standard FTP messages are as follows:

Interested in more details about testing this protocol?

TFTP

RFC783 http://www.cis.ohio-state.edu/htbin/rfc/rfc783.html
RFC1350 http://www.cis.ohio-state.edu/htbin/rfc/rfc1350.html

The Trivial File Transfer Protocol (TFTP) uses UDP. TFTP supports file writing and reading; it does not support directory service of user authorization.

Commands

The following are TFTP commands:

Parameters
TFTP Read and Write Request commands use the following parameters:

TFTP data and data acknowledge commands use the following parameters:

Interested in more details about testing this protocol?

Finger

RFC1288 http://www.cis.ohio-state.edu/htbin/rfc/rfc1288.html

The Finger user information protocol is a simple protocol which provides an interface to a remote user information program. It is a protocol for the exchange of user information. based on the Transmission Control Protocol, using TCP port 79 decimal (117 octal). The local host opens a TCP connection to a remote host on the Finger port. An RUIP becomes available on the remote end of the connection to process the request. The local host sends the RUIP a one line query based upon the Finger query specification, and waits for the RUIP to respond. The RUIP receives and processes the query, returns an answer, then initiates the close of the connection. The local host receives the answer and the close signal, then proceeds closing its end of the connection.

This protocol displays data. Any data transferred must be in ASCII format, with no parity, and with lines ending in CRLF (ASCII 13 followed by ASCII 10). This excludes other character formats such as EBCDIC, etc. This also means that any characters between ASCII 128 and ASCII 255 should truly be international data, not 7-bit ASCII with the parity bit set. Note: if ASCII 13 followed by ASCII 10 transferred the character won’t display (because the only meaning is to end the line).

Interested in more details about testing this protocol?

HTTP

RFC1945 http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. Messages are passed in a format similar to that used by Internet Mail and the Multipurpose Internet Mail Extensions (MIME). (Compliant with IETF RFC1945 May, 1996.)

Request Packet

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

Method
The method to be performed on the resource.

Request-URI
The Uniform Resource Identifier, the resource upon which to apply the request, i.e. the network resource.

HTTP version
The HTTP version being used.

Response Packet

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

HTTP version
The HTTP version being used.

Status-code
A 3 digit integer result code of the attempt to understand and satisfy the request.

Reason-phrase
A textual description of the status code.

Enlarge	More Details

Interested in more details about testing this protocol?

 S-HTTP

RFC2660 http://www.cis.ohio-state.edu/htbin/rfc/rfc2660.html

Secure HTTP (S-HTTP) provides secure communication mechanisms between an HTTP client-server pair in order to enable spontaneous commercial transactions for a wide range of applications. S-HTTP provides a flexible protocol that supports multiple orthogonal operation modes, key management mechanisms, trust models, cryptographic algorithms and encapsulation formats through option negotiation between parties for each transaction. Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically cryptographically enhanced.

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