The Defense Advance Research Projects Agency (DARPA) originally developed Transmission Control Protocol/Internet Protocol (TCP/IP) to interconnect various defense department computer networks. The Internet, an international Wide Area Network, uses TCP/IP to connect government and educational institutions across the world. TCP/IP is also in widespread use on commercial and private networks. The TCP/IP suite includes the following protocols
Data Link Layer
ARP/RARP Address Resolution Protocol/Reverse Address
DCAP Data Link Switching Client Access Protocol
Network Layer
DHCP Dynamic Host Configuration Protocol
DVMRP Distance Vector Multicast Routing Protocol
ICMP/ICMPv6 Internet Control Message Protocol
IGMP Internet Group Management Protocol
IP Internet Protocol version 4
IPv6 Internet Protocol version 6
MARS Multicast Address Resolution Server
PIM Protocol Independent Multicast-Sparse Mode (PIM-SM)
RIP2 Routing Information Protocol
RIPng for IPv6 Routing Information Protocol for IPv6
RSVP Resource ReSerVation setup Protocol
VRRP Virtual Router Redundancy Protocol
Transport Layer
ISTP
Mobile IP Mobile IP Protocol
RUDP Reliable UDP
TALI Transport Adapter Layer Interface
TCP Transmission Control Protocol
UDP User Datagram Protocol
Van Jacobson compressed TCP
XOT X.25 over TCP
Session Layer
BGMP Border Gateway Multicast Protocol
Diameter
DIS Distributed Interactive Simulation
DNS Domain Name Service
ISAKMP/IKE Internet Security Association and Key Management Protocol and Internet Key Exchange Protocol
iSCSI Small Computer Systems Interface
LDAP Lightweight Directory Access Protocol
MZAP Multicast-Scope Zone Announcement Protocol
NetBIOS/IP NetBIOS/IP for TCP/IP Environment
Application Layer
COPS Common Open Policy Service
FANP Flow Attribute Notification Protocol
Finger User Information Protocol
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
IMAP4 Internet Message Access Protocol rev 4
IMPPpre/IMPPmes Instant Messaging and Presence Protocols
IPDC IP Device Control
IRC ·Internet Relay Chat Protocol
ISAKMP Internet Message Access Protocol version 4rev1
ISP
NTP Network Time Protocol
POP3 Post Office Protocol version 3
Radius Remote Authentication Dial In User Service
RLOGIN Remote Login
RTSP Real-time Streaming Protocol
SCTP Stream Control Transmision Protocol
S-HTTP Secure Hypertext Transfer Protocol
SLP Service Location Protocol
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SOCKS Socket Secure (Server)
TACACS+ Terminal Access Controller Access Control System
TELNET TCP/IP Terminal Emulation Protocol
TFTP Trivial File Transfer Protocol
WCCP Web Cache Coordination Protocol
X-Window X Window
Routing
BGP-4 Border Gateway Protocol
EGP Exterior Gateway Protocol
EIGRP Enhanced Interior Gateway Routing Protocol
HSRP Cisco Hot Standby Router Protocol
IGRP Interior Gateway Routing
NARP NBMA Address Resolution Protocol
NHRP Next Hop Resolution Protocol
OSPF Open Shortest Path First
TRIP Telephony Routing over IP
Tunneling
ATMP Ascend Tunnel Management Protocol
L2F The Layer 2 Forwarding Protocol
L2TP Layer 2 Tunneling Protocol
PPTP Point to Point Tunneling Protocol
Security
AH Authentication Header
ESP Encapsulating Security Payload
TLS Transport Layer Security Protocol
The TCP/IP suite is illustrated here in relation to the OSI model:
Click the protocols on the map to see more details.
TCP / IP Suite
IP
The Internet Protocol (IP), defined by IETF RFC791, is the routing layer datagram service of the TCP/IP suite. All other protocols within the TCP/IP suite, except ARP and RARP, use IP to route frames from host to host. The IP frame header contains routing information and control information associated with datagram delivery.
The IP header structure is as follows:
4
8
16
32 bits
Ver.
IHL
Type of service
Total length
Identification
Flags
Fragment offset
Time to live
Protocol
Header checksum
Source address
Destination address
Option + Padding
Data
IP header structure
Version
Version field indicates the format of the Internet header.
IHL
Internet header length is the length of the Internet header in 32-bit words. Points to the beginning of the data. The minimum value for a correct header is 5.
Type of service
Indicates the quality of service desired. Networks may offer service precedence, meaning that they accept traffic only above a certain precedence at times of high load. There is a three-way trade-off between low delay, high reliability and high throughput.
Bits 0-2: Precedence
111 Network control.
110 Internetwork control.
101 CRITIC/ECP.
100 Flash override.
011 Flash.
010 Immediate.
001 Priority.
000 Routine.
Bit 3: Delay
0 Normal delay.
1 Low delay.
Bit 4: Throughput
0 Normal throughput.
1 High throughput.
Bit 5: Reliability
0 Normal reliability.
1 High reliability.
Bits 6-7: Reserved for future use.
Total length
Length of the datagram measured in bytes, including the Internet header and data. This field allows the length of a datagram to be up to 65,535 bytes, although such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 bytes, regardless of whether they arrive whole or in fragments. It is recommended that hosts send datagrams larger than 576 bytes only if the destination is prepared to accept the larger datagrams.
Identification
Identifying value assigned by the sender to aid in assembling the fragments of a datagram.
Flags
3 bits. Control flags:
Bit 0 is reserved and must be zero
Bit 1: Don’t fragment bit:
0 May fragment.
1 Don’t fragment.
Bit 2: More fragments bit:
0 Last fragment.
1 More fragments.
Fragment offset
13 bits. Indicates where this fragment belongs in the datagram. The fragment offset is measured in units of 8 bytes (64 bits). The first fragment has offset zero.
Time to live
Indicates the maximum time the datagram is allowed to remain in the Internet system. If this field contains the value zero, the datagram must be destroyed. This field is modified in Internet header processing. The time is measured in units of seconds. However, since every module that processes a datagram must decrease the TTL by at least one (even if it processes the datagram in less than 1 second), the TTL must be thought of only as an upper limit on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded and to bound the maximum datagram lifetime.
Protocol
Indicates the next level protocol used in the data portion of the Internet datagram.
Header checksum
A checksum on the header only. Since some header fields change, e.g., Time To Live, this is recomputed and verified at each point that the Internet header is processed.
Source address / destination address
32 bits each. A distinction is made between names, addresses and routes. A name indicates an object to be sought. An address indicates the location of the object. A route indicates how to arrive at the object. The Internet protocol deals primarily with addresses. It is the task of higher level protocols (such as host-to-host or application) to make the mapping from names to addresses. The Internet module maps Internet addresses to local net addresses. It is the task of lower level procedures (such as local net or gateways) to make the mapping from local net addresses to routes.
Options
Options may or may not appear in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation. In some environments, the security option may be required in all datagrams.
The option field is variable in length. There may be zero or more options. There are two possible formats for an option:
* A single octet of option type.
* An option type octet, an option length octet and the actual option data octets.
The length octet includes the option type octet and the actual option data octets.
The option type octet has 3 fields:
1 bit: Copied flag. Indicates that this option is copied into all fragments during fragmentation:
0 Copied.
1 Not copied.
2 bits: Option class
0 Control.
1 Reserved for future use.
2 Debugging and measurement.
3 Reserved for future use.
5 bits: Option number.
Data
IP data or higher layer protocol header.
Enlarge
More Details
Interested in more details about testing this protocol? click here
IPv6
IP version 6 (IPv6) is a new version of the Internet Protocol based on IPv4. IPv4 and IPv6 are demultiplexed at the media layer. For example, IPv6 packets are carried over Ethernet with the content type 86DD (hexadecimal) instead of IPv4’s 0800.
IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes and simpler auto-configuration of addresses. Scalability of multicast addresses is introduced. A new type of address called an anycast address is also defined, to send a packet to any one of a group of nodes.
Improved support for extensions and options - IPv6 options are placed in separate headers that are located between the IPv6 header and the transport layer header. Changes in the way IP header options are encoded allow more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. The extension headers are: Hop-by-Hop Option, Routing (Type 0), Fragment, Destination Option, Authentication, Encapsulation Payload.
Flow labeling capability - A new capability has been added to enable the labeling of packets belonging to particular traffic flows for which the sender requests special handling, such as non-default Quality of Service or real-time service.
The IPv6 header structure is as follows:
4
4
16
24
32 bits
Ver.
Priority
Flow label
Payload length
Next header
Hop limit
Source address
(128 Bits)
Destination address
(128 bits)
IPv6 header structure
Version
Internet Protocol Version number (IPv6 is 6).
Priority
Enables a source to identify the desired delivery priority of the packets. Priority values are divided into ranges: traffic where the source provides congestion control and non-congestion control traffic.
Flow label
Used by a source to label those products for which it requests special handling by the IPv6 router. The flow is uniquely identified by the combination of a source address and a non-zero flow label.
Payload length
Length of payload (in octets).
Next header
Identifies the type of header immediately following the IPv6 header.
Hop limit
8-bit integer that is decremented by one by each node that forwards the packet. The packet is discarded if the Hop Limit is decremented to zero.
Source address
128-bit address of the originator of the packet.
Destination address
128-bit address of the intended recipient of the packet.
Enlarge
More Details
Interested in more details about testing this protocol? click here
TCP
RFC793 http://www.cis.ohio-state.edu/htbin/rfc/rfc793.html
RFC1146 http://www.cis.ohio-state.edu/htbin/rfc/rfc1146.html
RFC1072 http://www.cis.ohio-state.edu/htbin/rfc/rfc1072.html
This RFC has been replaced by RFC 1323.
The information on this page will be updated to suit the new RFC in the near future.
RFC1693 http://www.cis.ohio-state.edu/htbin/rfc/rfc1693.html
IETF RFC793 defines the Transmission Control Protocol (TCP). TCP provides a reliable stream delivery and virtual connection service to applications through the use of sequenced acknowledgment with retransmission of packets when necessary.
The TCP header structure is as follows:
16
32 bits
Source port
Destination port
Sequence number
Acknowledgement number
Offset
Resrvd
U
A
P
R
S
F
Window
Checksum
Urgent pointer
Option + Padding
Data
TCP header structure
Source port
Source port number.
Destination port
Destination port number.
Sequence number
The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1.
Acknowledgment number
If the ACK control bit is set, this field contains the value of the next sequence number which the sender of the segment is expecting to receive. Once a connection is established, this value is always sent.
Data offset
4 bits. The number of 32-bit words in the TCP header, which indicates where the data begins. The TCP header (even one including options) has a length which is an integral number of 32 bits.
Reserved
6 bits. Reserved for future use. Must be zero.
Control bits
6 bits. The control bits may be (from right to left):
U (URG) Urgent pointer field significant.
A (ACK) Acknowledgment field significant.
P (PSH) Push function.
R (RST) Reset the connection.
S (SYN) Synchronize sequence numbers.
F (FIN) No more data from sender.
Window
16 bits. The number of data octets which the sender of this segment is willing to accept, beginning with the octet indicated in the acknowledgment field.
Checksum
16 bits. The checksum field is the 16 bit one’s complement of the one’s complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.
Urgent Pointer
16 bits. This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field can only be interpreted in segments for which the URG control bit has been set.
Options
Options may be transmitted at the end of the TCP header and always have a length which is a multiple of 8 bits. All options are included in the checksum. An option may begin on any octet boundary.
There are two possible formats for an option:
*
A single octet of option type.
*
An octet of option type, an octet of option length, and the actual option data octets.
The option length includes the option type and option length, as well as the option data octets.
The list of options may be shorter than that designated by the data offset field because the contents of the header beyond the End-of-Option option must be header padding i.e., zero.
A TCP must implement all options.
Data
TCP data or higher layer protocol.
Enlarge
More Details
Interested in more details about testing this protocol? click here
UDP
The User Datagram Protocol (UDP), defined by IETF RFC768, provides a simple, but unreliable message service for transaction-oriented services. Each UDP header carries both a source port identifier and destination port identifier, allowing high-level protocols to target specific applications and services among hosts.
The UDP header structure is shown as follows:
16
32 bits
Source port
Destination port
Length
Checksum
Data
UDP header structure
Source port
Source port is an optional field. When used, it indicates the port of the sending process and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted.
Destination port
Destination port has a meaning within the context of a particular Internet destination address.
Length
The length in octets of this user datagram, including this header and the data. The minimum value of the length is eight.
Checksum
The 16-bit one’s complement of the one’s complement sum of a pseudo header of information from the IP header, the UDP header and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.
ARP/RARP
RFC826 http://www.cis.ohio-state.edu/htbin/rfc/rfc826.html
RFC1293 http://www.cis.ohio-state.edu/htbin/rfc/rfc1293.html
This RFC has been replaced by RFC 2390.
The information on this page will be updated to suit the new RFC in the near future.
RFC1390 http://www.cis.ohio-state.edu/htbin/rfc/rfc1390.html
TCP/IP uses the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP) to initialize the use of Internet addressing on an Ethernet or other network that uses its own media access control (MAC). ARP allows a host to communicate with other hosts when only the Internet address of its neighbors is known. Before using IP, the host sends a broadcast ARP request containing the Internet address of the desired destination system.
The ARP/RARP header structure is shown in the illustration below.
16
32 bits
Hardware Type
Protocol Type
HLen (8)
Plen (8)
Operation
Sender Hardware Address
Sender Protocol Address
Target Hardware Address
Target Protocol Address
ARP/RARP header structure
Hardware type
Specifies a hardware interface type for which the sender requires a response.
Protocol type
Specifies the type of high-level protocol address the sender has supplied.
HLen
Hardware address length.
PLen
Protocol address length.
Operation
The values are as follows:
1 ARP request.
2 ARP response.
3 RARP request.
4 RARP response.
5 Dynamic RARP request.
6 Dynamic RARP reply.
7 Dynamic RARP error.
8 InARP request.
9 InARP reply.
Sender hardware address
HLen bytes in length.
Sender protocol address
PLen bytes in length.
Target hardware address
HLen bytes in length.
Target protocol address
PLen bytes in length.
Enlarge
More Details
Interested in more details about testing this protocol? click here
DCAP
http://info.internet.isi.edu/in-notes/rfc/files/rfc2114.txt .
The (DLSw) Data Link Switching Client Access Protocol is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions.
Since the Data Link Switching Protocol, RFC 1795, was published, some software vendors have begun implementing DLSw on workstations. The implementation of DLSw on a large number of workstations raises the important issues of scalability and efficiency. Since DLSw is a switch-to-switch protocol, it is not efficient when implemented on workstations. DCAP addresses these issues. It introduces a hierarchical structure to resolve the scalability problems. All workstations are clients to the router (server) rather than peers to the router. This creates a client/server model. It also provides a more efficient protocol between the workstation (client) and the router (server).
(Application layer)
DCAP Packet Header
The DCAP packet header is used to identify the message type and length of the frame. This is a general purpose header used for each frame that is passed between the DCAP server and the clien
8 16
Protocol ID/Version Number Message Type
Packet Length
DCAP Header Format
Protocol ID
The Protocol ID uses the first 4 bits of this field and is set to 1000.
Version number
The Version number uses the next 4 bits in this field and is set to 0001.
Message type
The message type is the DCAP message type.
The following message types exist:
DCAP Frame Name
Code
Function
CAN U REACH 0x01 Find if the station given is reachable
I CAN REACH 0x02 Positive response to CAN U REACH
I CANNOT REACH 0x03 Negative response to CAN U REACH
START DL 0x04 Setup session for given addresses
DL STARTED 0x05 Session started
START DL FAILED 0x06 Session Start failed
XID FRAME 0x07 XID frame
CONTACT STN 0x08 Contact destination to establish SABME
STN CONTACTED 0x09 Station contacted - SABME mode set
DATA FRAME 0x0A Connectionless Data Frame for a link
INFO FRAME 0x0B Connection oriented I-Frame
HALT DL 0x0C Halt Data Link session
HALT DL NOACK 0x0D Halt Data Link session without ack
DL HALTED 0x0E Session halted
FCM FRAME 0x0F Data Link Session Flow Control Message
DGRM FRAME 0x11 Connectionless Datagram Frame for circuit
CAP XCHANGE 0x12 Capabilities Exchange Message
CLOSE PEER REQUEST 0x13 Disconnect Peer Connection Request
CLOSE PEER RESPONSE 0x14 Disconnect Peer Connection Response
PEER TEST REQ 0x1D Peer keepalive test request
PEER TEST RSP 0x1E Peer keepalive response
Packet length
The total packet length is the length of the packet including the DCAP header, DCAP data and user data. The minimum size of the packet is 4, which is the length of the header.
Interested in more details about testing this protocol? click here
ATMP
RFC 2107 http://www.cis.ohio-state.edu/htbin/rfc/rfc2107.html
The Ascend Tunnel Management Protocol (ATMP) is a protocol currently being used in Ascend Communication products to allow dial-in client software to obtain virtual presence on a user's home network from remote locations. A user calls into a remote NAS but instead of using an address belonging to a network directly supported by the NAS, the client software uses an address belonging to the user's "Home Network". This address can be either provided by the client software or assigned from a pool of addresses from the Home Network address space. In either case, this address belongs to the Home Network and therefore special routing considerations are required in order to route packets to and from these clients. A tunnel between the NAS and a special “Home Agent” (HA) located on the Home Network is used to carry data to and from the client.
The format of the ATMP header is shown in the following illustration:
Version
Message type
Identifier
ATMP packet structure
Version
The ATMP protocol version must be 1.
Message type
ATMP defines a set of request and reply messages sent with UDP. There are 7 different ATMP message types represented by the following values.
MessageType Type Code
Registration Request
Challenge Request
Challenge Reply
Registration Reply
Deregister Request
Deregister Reply
Error Notification
1
2
3
4
5
6
7
Identifier
A 16 bit number used to match replies with requests. A new value should be provided in each new request. Retransmissions of the same request should use the same identifier.
Interested in more details about testing this protocol? click here
L2F
RFC 2341 http://www.cis.ohio-state.edu/htbin/rfc/rfc2341.html
The Layer 2 Forwarding protocol (L2F) permits the tunneling of the link layer of higher layer protocols. Using such tunnels it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided.
The format of the packet is shown in the following illustration:
13 16 24 32
F K P S 0 0 0 0 0 0 0 0 C
Ver
Protocol
Sequence (opt)
Multiplex ID
Client ID
Length
Payload offset
Packet key (optional)
Payload
Checksum
L2F packet structure
Version
The major version of the L2F software creating the packet.
Protocol
The protocol field specifies the protocol carried within the L2F packet.
Sequence
The sequence number is present if the S bit in the L2F header is set to 1.
Multiplex ID
The packet multiplex ID identifies a particular connection within a tunnel.
Client ID
The client ID (CLID) assists endpoints in demultiplexing tunnels.
Length
The length is the size in octets of the entire packet, including the header, all the fields and the payload.
Payload offset
This field specifies the number of bytes past the L2F header at which the payload data is expected to start. This field is present if the F bit in the L2F header is set to 1.
Packet key
The key field is present if the K bit is set in the L2F header. This is part of the authentication process.
Checksum
The checksum of the packet. The checksum field is present if the C bit in the L2F header is set to 1.
Option Messages
When the link is initiated, the endpoints communicate to verify the presence of L2F on the remote end, and to permit any needed authentication. The protocol for such negotiation is always 1, indicating L2F management. The message itself is structured as a sequence of single octets indicating an option. When the protocol field of an L2F specifies L2F management, the body of the packet is encoded as zero or more options. An option is a single octet message type, followed by zero or more sub-options. Each sub-option is a single byte sub-option value, and followed by additional bytes as appropriate for the sub-option.
Possible option messages are:
Invalid Invalid message.
L2F CONF Request configuration.
L2F CONF NAME Name of peer sending L2F CONF.
L2F CONF CHAL Random number peer challenges.
L2F CONF CLID Assigned CLID for peer to use.
L2F OPEN Accept configuration.
L2F OPEN NAME Name received from client.
L2F OPEN CHAL Challenge client received.
L2F OPEN RESP Challenge response from client.
L2F ACK LCP1 LCP CONFACK accepted from client.
L2F ACK LCP2 LCP CONFACK sent to client.
L2F OPEN TYPE Type of authentication used.
L2F OPEN ID ID associated with authentication.
L2F REQ LCP0 First LCP CONFREQ from client.
L2F CLOSE Request disconnect.
L2F CLOSE WHY Reason code for close.
L2F CLOSE STR ASCII string description.
L2F ECHO Verify presence of peer.
L2F ECHO RESP Respond to L2F_ECHO.
Interested in more details about testing this protocol? click here
L2TP
IETF draft
The L2TP Protocol is used for integrating multi-protocol dial-up services into existing Internet Service Providers Point of Presence (hereafter referred to as ISP and POP, respectively). This protocol may also be used to solve the "multilink hunt-group splitting" problem. Multilink PPP, often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Because L2TP makes a PPP session appear at a location other than the physical point at which the session was physically received, it can be used to make all channels appear at a single NAS, allowing for a multilink operation even when the physical calls are spread across distinct physical NASs.
The format of the L2TP packet is shown in the following illustration:
8 16 32 bits
T L X X S X O P X X X X VER Length
Tunnel ID SESSION ID
Ns Nr
AVP (bytes +)
L2TP packet structure
T
The T bit indicates the type of message. It is set to 0 for data messages and 1 for control messages.
L
When set, this indicates that the Length field is present, indicating the total length of the received packet. Must be set for control messages.
X
The X bits are reserved for future extensions. All reserved bits are set to 0 on outgoing messages and are ignored on incoming messages.
S
If the S bit is set, both the Nr and Ns fields are present. S must be set for control messages.
O
When set, this field indicates that the Offset Size field is present in payload messages. This bit is set to 0 for control messages.
P
If the Priority (P) bit is 1, this data message receives preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, are generally sent with this bit set to 1. Without it, a temporary interval of local congestion could result in interference with keepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit has a value of 0 for all control messages.
Ver
The value of the ver bit is always 002. This indicates a version 1 L2TP message.
Length
Overall length of the message, including header, message type AVP, plus any additional AVP's associated with a given control message type.
Tunnel ID
Identifies the tunnel to which a control message applies. If an Assigned Tunnel ID has not yet been received from the peer, Tunnel ID must be set to 0. Once an Assigned Tunnel ID is received, all further packets must be sent with Tunnel ID set to the indicated value.
Call ID
Identifies the user session within a tunnel to which a control message applies. If a control message does not apply to a single user session within the tunnel (for instance, a Stop-Control-Connection-Notification message), Call ID must be set to 0.
Nr
The sequence number expected in the next control message to be receivec.
Ns
The sequence number for this data or control message.
Data messages have two additional fields before the AVP as follows:
Offset size (16 bits) Offset pad (16 bits)
Additional fields in L2TP payload message
Offset size
This field specifies the number of bytes past the L2TP header at which the payload data is expected to start. It is recommended that data thus skipped be initialized to 0s. If the offset size is 0, or the O bit is not set, the first byte following the last byte of the L2TP header is the first byte of payload data.
AVP
The AVP (Attribute-Value Pair) is a uniform method used for encoding message types and bodies throughout L2TP. The format of the AVP is given below:
16
32 bits
M
H
O
O
O
O
Overall length
Vendor ID
Attribute
Value
L2TP AVP structure
M
The first six bits are a bit mask, describing the general attributes of the AVP. The M bit, known as the mandatory bit, controls the behavior required of an implementation which receives an AVP which it does not recognize.
H
The hidden bit controls the hiding of the data in the value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP.
Overall length
Encodes the number of octets (including the overall length field itself) contained in this AVP. It is 10 bits, permitting a maximum of 1024 bytes of data in a single AVP.
Vendor ID
The IANA assigned SMI Network Management Private Enterprise Codes value, encoded in network byte order.
Attribute
The actual attribute, a 16-bit value with a unique interpretation across all AVP's defined under a given Vendor ID.
Value
The value field follows immediately after the Attribute field, and runs for the remaining octets indicated in the overall length (i.e., overall length minus six octets of header).
Enlarge
More Details
Interested in more details about testing this protocol? click here
PPTP
PPTP (Point to Point Tunneling Protocol) allows PPP to be channeled through an IP network. It uses a client-server architecture to decouple functions which exist in current Network Access Servers and support Virtual Private Networks. It specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN, or to initiate outbound circuit switched connections. PPTP uses a GRE-like (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.
The format of the header is shown in the following illustration:
16
32 bits
Length
PPTP message type
Magic cookie
Control message type
Reserved 0
PPTP header structure
Length
Total length in octets of this PPTP message including the entire PPTP header.
PPTP message type
The message type. Possible values are:
1 Control message.
2 Management message.
Magic cookie
The magic cookie is always sent as the constant 0x1A2B3C4D. Its basic purpose is to allow the receiver to ensure that it is properly synchronized with the TCP data stream.
Control Message Type
Values may be:
1 Start-Control-Connection-Request.
2 Start-Control-Connection-Reply.
3 Stop-Control-Connection-Request.
4 Stop-Control-Connection-Reply.
5 Echo-Request.
6 Echo-Reply.
Call Management
7 Outgoing-Call-Request.
8 Outgoing-Call-Reply.
9 Incoming-Call-Request.
10 Incoming-Call-Reply.
11 Incoming-Call-Connected.
12 Call-Clear-Request.
13 Call-Disconnect-Notify.
Error Reporting
14 WAN-Error-Notify.
PPP Session Control
15 Set-Link-Info.
Reserved
A reserved field, must be set to 0.
Interested in more details about testing this protocol? click here
DHCP
This RFC has been replaced by RFC 2131.
The information on this page will be updated to suit the new RFC in the near future.
The Dynamic Host Configuration Protocol (DHCP) provides Internet hosts with configuration parameters. DHCP is an extension of BOOTP. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.
(Compliant with IETF RFC1531.)
The format of the header is shown in the following illustration:
8
16
24
32 bits
Op (1)
Htype (1)
Hlen (1)
Hops (1)
Xid (4 bytes)
Secs (2 bytes)
Flags (2 bytes)
Ciaddr (4 bytes)
Yiaddr (4 bytes)
Siaddr (4 bytes)
Giaddr (4 bytes)
Chaddr (16 bytes)
DHCP header structure
Op
The message operation code. Messages can be either BOOTREQUEST or BOOTREPLY.
Htype
The hardware address type.
Hlen
The hardware address length.
Xid
The transaction ID.
Secs
The seconds elapsed since the client began the address acquisition or renewal process.
Flags
The flags.
Ciaddr
The client IP address.
Yiaddr
The "Your" (client) IP address.
Siaddr
The IP address of the next server to use in bootstrap.
Giaddr
The relay agent IP address used in booting via a relay agent.
Chaddr
The client hardware address.
Enlarge
More Details
Interested in more details about testing this protocol? click here
DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) is an Internet routing protocol that provides an efficient mechanism for connectionless datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP multicast delivery trees using a technique called Reverse Path Multicasting
DVMRP combines many of the features of RIP with the Truncated Reverse Path Broadcasting (TRPB) algorithm. DVMRP is developed based upon RIP because an implementation was available and distance vector algorithms are simple, as compared to link-state algorithms. In addition, to allow experiments to traverse networks that do not support multicasting, a mechanism called tunneling was developed.
DVMRP differs from RIP in one very important way. RIP routes and forwards datagrams to a particular destination. The purpose of DVMRP is to keep track of the return paths to the source of multicast datagrams. To make the explanation of DVMRP more consistent with RIP, the term destination is used instead of the more proper term source, however, datagrams are not forwarded to these destinations, but rather, originate from them.
DVMRP packets are encapsulated in IP datagrams, with an IP protocol number of 2 (IGMP). All fields are transmitted in Network Byte Order. DVMRP packets use a common protocol header that specifies the IGMP Packet Type as DVMRP. DVMRP protocol packets should be sent with the Precedence field in the IP header set to Internetwork Control (hexadecimal 0xc0 for the Type of Service Octet). The common protocol header is as shown in the following illustration:
8 16 24 32 bits
Type
Code
Checksum
Reserved
Min version
Maj version
DVMRP structure
Type
Packet type. 0x13 indicates a DVMRP packet.
Code
Determines the type of DVMRP packet. Currently, there are codes for DVMRP protocol message types as well as protocol analysis and troubleshooting packets. The protocol message codes may be as follows:
Probe Neighbor discovery.
Report Route exchange.
Prune Pruning multicast delivery trees.
Graft Grafting multicast delivery trees.
Graft ack Acknowledging graft messages.
Checksum
16-bit one's complement of the one's complement sum of the DVMRP message. The checksum must be calculated upon transmission and must be validated on reception of a packet. The checksum of the DVMRP message should be calculated with the checksum field set to zero.
Reserved
Reserved for later use.
Min version
Minor version. Value must be 0xFF for this version of DVMRP.
Maj version
Major version. Value must be 3 for this version of DVMRP.
Interested in more details about testing this protocol? click here
ICMP
IETF RFC792 defines the Internet Control Message Protocol (ICMP). ICMP messages generally contain information about routing difficulties with IP datagrams or simple exchanges such as time-stamp or echo transactions.
The ICMP header structure is shown as follows:
8
16
32 bits
Type
Code
Checksum
Identifier
Sequence number
Address mask
ICMP header structure
Type Code Description
0 Echo reply.
3 Destination unreachable.
3 0 Net unreachable.
3 1 Host unreachable.
3 2 Protocol unreachable.
3 3 Port unreachable.
3 4 Fragmentation needed and DF set.
3 5 Source route failed.
4 Source quench.
5 Redirect.
5 0 Redirect datagrams for the network.
5 1 Redirect datagrams for the host.
5 2 Redirect datagrams for the type of service and network.
5 3 Redirect datagrams for the type of service and host.
8 Echo.
11 Time exceeded.
11 0 Time to live exceeded in transit.
11 1 Fragment reassemble time exceeded.
12 Parameter problem.
13 Timestamp.
14 Timestamp reply.
15 Information request.
16 Information reply.
Checksum
The 16-bit one’s complement of the one’s complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero.
Identifier
An identifier to aid in matching requests/replies; may be zero.
Sequence number
Sequence number to aid in matching requests/replies; may be zero.
Address mask
A 32-bit mask.
Enlarge
More Details
Interested in more details about testing this protocol? click here
ICMPv6
This RFC has been replaced by RFC 2463.
The information on this page will be updated to suit the new RFC in the near future.
This RFC has been replaced by RFC 2461.
The information on this page will be updated to suit the new RFC in the near future.
The Internet Control Message Protocol (ICMP) was revised during the definition of IPv6. In addition, the multicast control functions of the IPv4 Group Membership Protocol (IGMP) are now incorporated with the ICMPv6.
The structure of the ICMPv6 header is shown in the following illustration.
8
16
32 bits
Type
Code
Checksum
ICMPv6 header structure
Type
The type of the message. Messages can be error or informational messages. Error messages can be Destination unreachable, Packet too big, Time exceed, Parameter problem. The possible informational messages are, Echo Request, Echo Reply, Group Membership Query, Group Membership Report, Group Membership Reduction.
Code
For each type of message several different codes are defined.
An example of this is the Destination Unreachable message, where possible messages are: no route to destination, communication with destination administratively prohibited, not a neighbor, address unreachable, port unreachable. For further details, refer to the standard.
