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: