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
0
1
2
3
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
0
Length
Type
Reserved

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:
1 OPEN
2 UPDATE
3 NOTIFICATION
4 KEEPALIVE

Interested in more details about testing this protocol? click here

Diameter
http://tools.ietf.org/html/rfc6733 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]. Diameter Applications extend the base protocol by adding new commands and/or attributes. 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:
0
1
2
3
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
0
Version
Message length
4
Command Flags
Command-Code
8
Application-ID
12
Hop-by-Hop Identifier
16
End-to-End Identifier
AVPs …
Version The Diameter version, currently 1. Message Length The entire message length. Command Flags The command flag; the following flags appear: R, if set the message is a request, if cleared it is an answer. P, If set, the message MAY be proxied, relayed, or redirected. If cleared, the message MUST be locally processed. E, If set, the message contains a protocol error, and the message will not conform to the CCF described for this command. T, This flag is set after a link failover procedure, to aid the removal of duplicate requests. R, reserved. . 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:
Code Command-Name Abbrev.
265 AA-Answer AAA
265 AA-Request AAA
274 Abort-Session-Request ASR
274 Abort-Session-Answer ASA
271 Accounting-Request ACR
271 Accounting-Answer ACA
318 Authentication Information Answer AIA
318 Authentication Information Request AIR
310 Bootstrapping-Info-Answer BIA
310 Bootstrapping-Info-Request BIR
257 Capabilities-Exchange Request CER
257 Capabilities-Exchange Answer CEA
272 Credit-Control-Answer CCA
272 Credit-Control-Request CCR
280 Device-Watchdog-Request DWR
280 Device-Watchdog-Answer DWA
268 Diameter-EAP-Answer DEA
268 Diameter-EAP-Request DER
282 Disconnect-Peer-Request DPR
282 Disconnect-Peer-Answer DPA
302 Location-Info-Answer LIA
302 Location-Info-Request LIR
311 Message-Process-Answer MPA
311 Message-Process-Request MPR
303 Multimedia-Auth-Answer MAA
303 Multimedia-Auth-Request MAR
323 Notify-Answer NA
323 Notify-Request NR
307 Profile-Update-Answer PUA
307 Profile-Update-Request PUR
309 Push-Notification-Answer PNA
309 Push-Notification-Request PNR
305 Push-Profile-Answer PPA
305 Push-Profile-Request PPR
258 Re-Auth-Request RAR
258 Re-Auth-Answer RAA
304 Registration-Termination-Answer RTA
304 Registration-Termination-Request RTR
301 Server-Assignment-Answer SAA
301 Server-Assignment-Request SAR
275 Session-Termination Request STR
275 Session-Termination Answer STA
308 Subscribe-Notifications-Answer SNA
308 Subscribe-Notifications-Request SNR
316 Update-Location-Answer ULA
316 Update-Location-Request ULR
300 User-Authorization-Answer UAA
300 User-Authorization-Request UAR
306 User-Data-Answer UDA
306 User-Data-Request UDR
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:
AVPcode The AVP Code, combined with the Vendor-Id field, uniquely identifies the attribute.
AVPflags Support Required/Not Required, Vendor-ID present/not present, Need encryption/don’t need.
AVPlength The number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data.
APVvendorID The IANA assigned “SMI Network Management Private Enterprise Codes” value, encoded in network byte order.
AVPdata Contains information specific to the Attribute. The AVP Code and AVP Length fields determine the format and length of the Data field.
Interested in more details about testing this protocol? click here   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:
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Octets
Protocol Version 8-bit enumeration
Exercise ID 8-bit unsigned integer
1
2
PDU Type 8-bit enumeration
Protocol Family 8-bit enumeration
3
4
Timestamp 32-bit unsigned integer
5
6
7
8
Length 16-bit unsigned integer
9
10
Padding 16 bits unused
11
12
Protocol Version The 8-bit enumeration for the Protocol-Version field
1 2 3 4 5 6 DIS_PDU_version_1.0 IEEE_1278-1993 DIS_PDU_version_2.00_-_third_draft DIS_PDU_version_2.00_-_fourth_draft IEEE_1278.1-1995 IEEE_1278.1A-1998
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 129 130 131 132 133 134 135 Entity_State Fire Detonation Collision Service_Request Resupply_Offer Resupply_Received Resupply_Cancel Repair_Complete Repair_Response Create_Entity Remove_Entity Start/Resume Stop/Freeze Acknowledge Action_Request Action_Response Data_Query Set_Data Data Event_Report Comment Electromagnetic_Emission Designator Transmitter Signal Receiver IFF/ATC/NAVAIDS Underwater_Acoustic Su[[lemental_Emission_/_Entity_State Intercom_Signal Intercom_control Aggregate_State IsGroupOf Transfer_control IsPartOf Minefield_State Minefield_Query Minefield_Data Minefield_Response_NAK Enviromental_Process Gridded_Data Point_Object_State Linear_Object_State Areal_Object_State TSPI Appearance Articulated_Parts LE_Fire LE_Detonation Create_Entity-R Remove_Entity-R Start/Resume-R Stop/Freeze-R Acknowledge-R Action_Request-R Action_Response-R Data_Query-R Set_Data-R Data-R Event_Report-R Comment-R Record_Query-R Set_Record-R Comment-R Collision_Elastic Entity_State_Update Announce_Object Delete_Object Describe_Application Describe_Event Describe_Object Request_Event Request_Object
Protocol Family The 8-bit enumeration for the Protocol-Family field
1 2 3 4 5 6 7 8 9 10 11 12 129 Entity_Information/Interaction Warfare Logistics Radio_Communication Simulation_Management Distributed_Emission_Regeneration Entity_Management Minefield Synthetic_Environment Simulation_Management_with_Reliability Live_Entity Non-Real_Time Experimental_-_Computer_Generated_Forces
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? click here   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:

16
21
28
32 bits
ID
Q
Query
A
T
R
V
B
Rcode
Question count
Answer count
Authority count
Additional count
DNS message header structure
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:
0 Standard query (name to address).
1 Inverse query (address to name).
2 Server status request.
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:

0 No error condition.
1 Unable to interpret query due to format error.
2 Unable to process due to server failure.
3 Name in query does not exist.
4 Type of query not supported.
5 Query refused.
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.
Interested in more details about testing this protocol? click here   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:
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
0 4
Initiator Cookie
8 12
Responder Cookie
16
Next Payload
MjVer
MnVer
Exchange Type
Flags
20
Message ID
24
Length
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:
0 None
1 Security Association
2 Proposal
3 Transform
4 Key Exchange
5 Identification
6 Certificate
7 Certificate Request
8 Hash
9 Signature
10 Nonce
11 Notification
12 Delete
13 Vendor ID (VID)
14 Attribute Payload
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:
0 NONE
1 Base
2 Identity Protection
3 Authentication Only
4 Aggressive
5 Informational
6 ISAKMP Future Use
7 Doi Specific Use
32 Quick Mode
33 New Group Mode
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? click here   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:
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
I
Opcode
F
Opcode-specific fields
4
TotalAHSLength
DataSegmentLength
8
LUN or Opcode-specific fields
12
16
Initiator Task Tag
20
Opcode-specific fields
48
Opcode The type of iSCSI PDU the header encapsulates.
0x0 Nop-out
0x1 SCSI Command (encapsulates a SCSI Command Descriptor Block)
0x2 SCSI Task Management function request
0x3 Login Request
0x4 Text Request
0x5 SCSI Data-out (for WRITE operations)
0x6 Logout Request
0x10 SNACK Request
0x1C Vendor specific codes
0x1D Vendor specific codes
0x1E Vendor specific codes
0x20 NOP-In
0x21 SCSI Response
0x23 Login Response
0x24 Text Response
0x25 SCSI Data-in (for READ operations)
0x26 Logout Response
0x31 Ready To Transfer (R2T)
0x32 Asynchronous Message
0x3C Vendor specific codes
0x3D Vendor specific codes
0x3E Vendor specific codes
0x3F Reject
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? click here

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.

8 16 24 32 bits
Version OpCode Checksum
VCID type Flow ID Reserved/Refresh int./Error code
VCID
Flow ID

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

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:

16
21
28
32 bits
Name_trn_id
Opcode
Nm_flags
Rcode
Qdcount (16 bits)
Ancount (16 bits)
Nscount (16 bits)
Arcount (16 bits)
NetBIOS/IP header structure
Name_trn_id Transaction ID for the Name Service Transaction. Opcode Packet type code: Possible values are:
0 Query.
5 Registration.
6 Release.
7 WACK.
8 Refresh.
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? click here

LDAP RFC 1777.

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

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:
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
0
Version
B
PTYPE
Address Family
NameCount
4
Message Origin
8
Zone ID Address
12
Zone Start Address
16
Zone End Address
Encoded Zone Name-1 (variable length)
Encoded Zone Name-N (variable length)
Padding (if needed)

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? click here   COPS RFC 2748

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 4 bits Flags 4 bits Op Code 8 bits Client-type 16 bits
Message Length 32 bits
COPS Header structure
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 (octets) C-Num C-Type
  (Object contents)
COPS specific object formats
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-Num Object Contents
1 Handle
2 Context
3 In Interface
4 Out Interface
5 Reason code
6 Decision
7 LDP Decision
8 Error
9 Client Specific Info
10 Keep-Alive Timer
11 PEP Identification
12 Report Type
13 PDP Redirect Address
14 Last PDP Address
15 Accounting Timer
16 Message Integrity
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? click here

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:
Command Description
ABOR Abort data connection process.
ACCT <account> Account for system privileges.
ALLO <bytes> Allocate bytes for file storage on server.
APPE <filename> Append file to file of same name on server.
CDUP <dir path> Change to parent directory on server.
CWD <dir path> Change working directory on server.
DELE <filename> Delete specified file on server.
HELP <command> Return information on specified command.
LIST <name> List information if name is a file or list files if name is a directory.
MODE <mode> Transfer mode (S=stream, B=block, C=compressed).
MKD <directory> Create specified directory on server.
NLST <directory> List contents of specified directory.
NOOP Cause no action other than acknowledgement from server.
PASS <password> Password for system log-in.
PASV Request server wait for data connection.
PORT <address> IP address and two-byte system port ID.
PWD Display current working directory.
QUIT Log off from the FTP server.
REIN Reinitialize connection to log-in status.
REST <offset> Restart file transfer from given offset.
RETR <filename> Retrieve (copy) file from server.
RMD <directory> Remove specified directory on server.
RNFR <old path> Rename from old path.
RNTO <new path> Rename to new path.
SITE <params> Site specific parameters provided by server.
SMNT <pathname> Mount the specified file structure.
STAT <directory> Return information on current process or directory.
STOR <filename> Store (copy) file to server.
STOU <filename> Store file to server name.
STRU <type> Data structure (F=file, R=record, P=page).
SYST Return operating system used by server.
TYPE <data type> Data type (A=ASCII, E=EBCDIC, I=binary).
USER <username> User name for system log-in.

Messages

FTP messages are responses to FTP commands and consist of a response code followed by explanatory text. Standard FTP messages are as follows:
Response Code Explanatory Text
110 Restart marker at MARK yyyy=mmmm (new file pointers).
120 Service ready in nnn minutes.
125 Data connection open, transfer starting.
150 Open connection.
200 OK.
202 Command not implemented.
211 (System status reply).
212 (Directory status reply).
213 (File status reply).
214 (Help message reply).
215 (System type reply).
220 Service ready.
221 Log off network.
225 Data connection open.
226 Close data connection.
227 Enter passive mode (IP address, port ID).
230 Log on network.
250 File action completed.
257 Path name created.
331 Password required.
332 Account name required.
350 File action pending.
421 Service shutting down.
425 Cannot open data connection.
426 Connection closed.
450 File unavailable.
451 Local error encountered.
452 Insufficient disk space.
500 Invalid command.
501 Bad parameter.
502 Command not implemented.
503 Bad command sequence.
504 Parameter invalid for command.
530 Not logged onto network.
532 Need account for storing files.
550 File unavailable.
551 Page type unknown.
552 Storage allocation exceeded.
553 File name not allowed.
Interested in more details about testing this protocol? click here   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:
Command Description
Read Request Request to read a file.
Write Request Request to write to a file.
File Data Transfer of file data.
Data Acknowledge Acknowledgement of file data.
Error Error indication.
Parameters TFTP Read and Write Request commands use the following parameters:
Parameter Description
Filename The name of the file, expressed in quotes, where the protocol is to perform the read or write operation.
Mode Datamode. The format of the file data that the protocol is to transfer. The following formats are possible:NetASCII Standard ASCII character format. Octet Eight-bit binary data. Mail Standard ASCII character format with username in place of filename.

TFTP data and data acknowledge commands use the following parameters:

Command Description
Block Block number or sequence number of the current frame of file data.
Data First part of the file data displayed for TFTP data frames.
TFTP Errors TFTP error frames contain an error code in parentheses followed by the error message, as follows:
(0000) Unknown Error.
(0001) File not found.
(0002) Access violation.
(0003) Out of disk space.
(0004) Illegal TFTP operation.
(0005) Unknown Transfer ID.
(0006) Filename already exists.
(0007) Unknown user.
Interested in more details about testing this protocol? click here   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? click here

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
Request URI
HTTP version
HTTP request packet structure
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
Status code
Reason phrase
HTTP response packet structure
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.
Interested in more details about testing this protocol? click here  



HTTP/2

RFC7540

target=”window2″>http://http://tools.ietf.org/html/rfc7540

HTTP/2 is similar to HTTP1 and 1.1, but adds a few new

features in order to increase speed. Changes were made in the way that data is changed and transported between the client and the server. HTTP/2 allows the server to send data before a response message is received. More improvements include multiplexing of requests and responses, header compression, and prioritization of requests. Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.

HTTP/2 is composed of frames, when each frame has its own purpose.

Multiplexing is achieved by having each HTTP Request/Response associated with its own stream. Flow control and prioritization ensure that it is possible to efficiently use multiplexed streams. HTTP/2 adds a new interaction mode whereby a server can push responses to a client. Server push allows a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain. Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are compressed. The format of the frame header is shown in the following illustration: Length The length of the frame payload expressed as an unsigned 24-bit integer. The 9 octets of the frame header are not included in this value. Type The 8-bit type of the frame. Flags An 8-bit field reserved for boolean flags specific to the frame type. R A reserved 1-bit field. Stream Identifier A stream identifier expressed as an unsigned 31- bit integer. 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? 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