Get raw text for this example
/*     Header file for program AnetTest   ICMP header     Attention: you can use this header only if you build some complex headers, containing IP header   this header must be combined with some other headers (on the channel level at least)       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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | unused |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    */
// **********************************************************
// COMMON ICMP
// type of ICMP message
.icmp.type 8
// code of ICMP message
.icmp.code 0
// icmp crc
.icmp.crc 0x0000 icmp.crc ICMPcrc
// icmp unused area
.icmp.unused 0x00000000
// values for icmp.type
DEFINE
PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF
PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').
.
echoreq 8 DEFINE
PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF
PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').
.
echorep 0 DEFINE
PARAMETERS: <name> <value>
Defines the substitution which will be applied while reading some values (in parameters to commands and others). <name> will be replaced by <value>. This substitution may be also performed in strings enclosed in apostrophes. In this case the <name> must be enclosed in $ (ex: 'value = $name$'. See also command GDEF
PARAMETERS: <new name> <original name>
Defines the substitution which will be applied while reading almost any read word from text. <New name> will be replaced by <original name>. This substitution may be also performed in strings enclosed in apostrophes. In this case the name must be enclosed in $ (ex: 'value = $name$').
.
redmes 5  
/*      RFC 792 (RFC792)    Internet RFC/STD/FYI/BCP Archives  [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]    Alternate Formats: rfc792.txt | rfc792.txt.pdf    RFC 792 - Internet Control Message Protocol    Network Working Group J. Postel  Request for Comments: 792 ISI   September 1981  Updates: RFCs 777, 760  Updates: IENs 109, 128     INTERNET CONTROL MESSAGE PROTOCOL     DARPA INTERNET PROGRAM   PROTOCOL SPECIFICATION    Introduction     The Internet Protocol (IP) [1] is used for host-to-host datagram   service in a system of interconnected networks called the   Catenet [2]. The network connecting devices are called Gateways.   These gateways communicate between themselves for control purposes   via a Gateway to Gateway Protocol (GGP) [3,4]. Occasionally a   gateway or destination host will communicate with a source host, for   example, to report an error in datagram processing. For such   purposes this protocol, the Internet Control Message Protocol (ICMP),   is used. ICMP, uses the basic support of IP as if it were a higher   level protocol, however, ICMP is actually an integral part of IP, and   must be implemented by every IP module.     ICMP messages are sent in several situations: for example, when a   datagram cannot reach its destination, when the gateway does not have   the buffering capacity to forward a datagram, and when the gateway   can direct the host to send traffic on a shorter route.     The Internet Protocol is not designed to be absolutely reliable. The   purpose of these control messages is to provide feedback about   problems in the communication environment, not to make IP reliable.   There are still no guarantees that a datagram will be delivered or a   control message will be returned. Some datagrams may still be   undelivered without any report of their loss. The higher level   protocols that use IP must implement their own reliability procedures   if reliable communication is required.     The ICMP messages typically report errors in the processing of   datagrams. To avoid the infinite regress of messages about messages   etc., no ICMP messages are sent about ICMP messages. Also ICMP   messages are only sent about errors in handling fragment zero of   fragemented datagrams. (Fragment zero has the fragment offeset equal   zero).     [Page 1]     September 1981  RFC 792    Message Formats     ICMP messages are sent using the basic IP header. The first octet of   the data portion of the datagram is a ICMP type field; the value of   this field determines the format of the remaining data. Any field   labeled
"unused"
is reserved for later extensions and must be zero   when sent, but receivers should not use these fields (except to   INCLUDE
PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without INCLUDE
PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without INCLUDE
PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without include before it.
before it.
before it.
them in the checksum). Unless otherwise noted under the   individual format descriptions, the values of the internet header   fields are as follows:     Version     4     IHL     Internet header length in 32-bit words.     Type of Service     0     Total Length     Length of internet header and data in octets.     Identification, Flags, Fragment OFFSET
PARAMETERS: <number of bites>
The position of the next defined field will be shifted to the left for the given <number of bits> which must be from 1 to 7. So every written value will be shifter to the left before writing. Nevertheless, after the writing the left bits will be also changed and set to 0. To avoid this use command MASK
PARAMETERS: <field's mask>
Defines the mask for the next defined field. Mask is hexadecimal number. Value for field will be written only in bits corresponding not null bits of mask. See "headers/tcp_header.fws".
. See "headers/tcp_header.fws"
    Used in fragmentation, see [1].     Time to Live     Time to live in seconds; as this field is decremented at each   machine in which the datagram is processed, the value in this   field should be at least as great as the number of gateways which   this datagram will traverse.     Protocol     ICMP = 1     Header Checksum     The 16 bit one
's complement of the one'
s complement sum of all 16   bit words in the header. For computing the checksum, the checksum   field should be zero. This checksum may be replaced in the   future.    [Page 2]    September 1981  RFC 792     Source Address     The address of the gateway or host that composes the ICMP message.   Unless otherwise noted, this can be any of a gateway's addresses.     Destination Address     The address of the gateway or host to which the message should be   sent.     [Page 3]     September 1981  RFC 792    Destination Unreachable Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | unused |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Destination Address     The source network and address from the original datagram's data.     ICMP Fields:     Type     3     Code     0 = net unreachable;     1 = host unreachable;     2 = protocol unreachable;     3 = port unreachable;     4 = fragmentation needed and DF set;     5 = source route failed.     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Internet Header + 64 bits of Data Datagram     The internet header plus the first 64 bits of the original    [Page 4]    September 1981  RFC 792     datagram's data. This data is used by the host to match the   message to the appropriate process. If a higher level protocol   uses port numbers, they are assumed to be in the first 64 data   bits of the original datagram's data.     Description     If, according to the information in the gateway's routing tables,   the network specified in the internet destination field of a   datagram is unreachable, e.g., the distance to the network is   infinity, the gateway may send a destination unreachable message   to the internet source host of the datagram. In addition, in some   networks, the gateway may be able to determine if the internet   destination host is unreachable. Gateways in these networks may   send destination unreachable messages to the source host when the   destination host is unreachable.     If, in the destination host, the IP module cannot deliver the   datagram because the indicated protocol module or process port is   not active, the destination host may send a destination   unreachable message to the source host.     Another case is when a datagram must be fragmented to be forwarded   by a gateway yet the Don't Fragment flag is on. In this case the   gateway must discard the datagram and may RETURN
PARAMETERS:
Stops processing current file. If it was included in another file then processing will continue from that INCLUDE
PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without INCLUDE
PARAMETERS: <name of file>
Starts processing the content of given file. The search of file will be performed in the current directory, all search paths (see option -I). For every path the content of samples, headers, traces folders will be also examined. You can also type just the name of file without include before it.
before it.
command.
a destination   unreachable message.     Codes 0, 1, 4, and 5 may be received from a gateway. Codes 2 and   3 may be received from a host.     [Page 5]     September 1981  RFC 792    Time Exceeded Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | unused |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Destination Address     The source network and address from the original datagram's data.     ICMP Fields:     Type     11     Code     0 = time to live exceeded in transit;     1 = fragment reassembly time exceeded.     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Internet Header + 64 bits of Data Datagram     The internet header plus the first 64 bits of the original   datagram's data. This data is used by the host to match the   message to the appropriate process. If a higher level protocol   uses port numbers, they are assumed to be in the first 64 data   bits of the original datagram's data.     Description     If the gateway processing a datagram finds the time to live field    [Page 6]    September 1981  RFC 792     is zero it must discard the datagram. The gateway may also notify   the source host via the time exceeded message.     If a host reassembling a fragmented datagram cannot complete the   reassembly due to missing fragments within its time limit it   discards the datagram, and it may send a time exceeded message.     If fragment zero is not available then no time exceeded need be   sent at all.     Code 0 may be received from a gateway. Code 1 may be received   from a host.     [Page 7]     September 1981  RFC 792    Parameter Problem Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Pointer | unused |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Destination Address     The source network and address from the original datagram's data.     ICMP Fields:     Type     12     Code     0 = pointer indicates the error.     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Pointer     If code = 0, identifies the octet where an error was detected.     Internet Header + 64 bits of Data Datagram     The internet header plus the first 64 bits of the original   datagram's data. This data is used by the host to match the   message to the appropriate process. If a higher level protocol   uses port numbers, they are assumed to be in the first 64 data   bits of the original datagram's data.    [Page 8]    September 1981  RFC 792     Description     If the gateway or host processing a datagram finds a problem with   the header parameters such that it cannot complete processing the   datagram it must discard the datagram. One potential source of   such a problem is with incorrect arguments in an option. The   gateway or host may also notify the source host via the parameter   problem message. This message is only sent if the error caused   the datagram to be discarded.     The pointer identifies the octet of the original datagram's header   where the error was detected (it may be in the middle of an   option). For example, 1 indicates something is wrong with the   Type of Service, and (if there are options present) 20 indicates   something is wrong with the type code of the first option.     Code 0 may be received from a gateway or a host.     [Page 9]     September 1981  RFC 792    Source Quench Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | unused |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Destination Address     The source network and address of the original datagram's data.     ICMP Fields:     Type     4     Code     0     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Internet Header + 64 bits of Data Datagram     The internet header plus the first 64 bits of the original   datagram's data. This data is used by the host to match the   message to the appropriate process. If a higher level protocol   uses port numbers, they are assumed to be in the first 64 data   bits of the original datagram's data.     Description     A gateway may discard internet datagrams if it does not have the   buffer space needed to queue the datagrams for output to the next   network on the route to the destination network. If a gateway    [Page 10]    September 1981  RFC 792     discards a datagram, it may send a source quench message to the   internet source host of the datagram. A destination host may also   send a source quench message if datagrams arrive too fast to be   processed. The source quench message is a request to the host to   cut BACK
PARAMETERS: <number of bytes>
Reduces the pointer for the given <number of bytes>.
the rate at which it is sending traffic to the internet   destination. The gateway may send a source quench message for   every message that it discards. On receipt of a source quench   message, the source host should cut BACK
PARAMETERS: <number of bytes>
Reduces the pointer for the given <number of bytes>.
the rate at which it is   sending traffic to the specified destination until it no longer   receives source quench messages from the gateway. The source host   can then gradually increase the rate at which it sends traffic to   the destination until it again receives source quench messages.     The gateway or host may send the source quench message when it   approaches its capacity limit rather than waiting until the   capacity is exceeded. This means that the data datagram which   triggered the source quench message may be delivered.     Code 0 may be received from a gateway or a host.     [Page 11]     September 1981  RFC 792    Redirect Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Gateway Internet Address |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Internet Header + 64 bits of Original Data Datagram |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Destination Address     The source network and address of the original datagram's data.     ICMP Fields:     Type     5     Code     0 = Redirect datagrams for the Network.     1 = Redirect datagrams for the Host.     2 = Redirect datagrams for the Type of Service and Network.     3 = Redirect datagrams for the Type of Service and Host.     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Gateway Internet Address     Address of the gateway to which traffic for the network specified   in the internet destination network field of the original   datagram's data should be sent.    [Page 12]    September 1981  RFC 792     Internet Header + 64 bits of Data Datagram     The internet header plus the first 64 bits of the original   datagram's data. This data is used by the host to match the   message to the appropriate process. If a higher level protocol   uses port numbers, they are assumed to be in the first 64 data   bits of the original datagram's data.     Description     The gateway sends a redirect message to a host in the following   situation. A gateway, G1, receives an internet datagram from a   host on a network to which the gateway is attached. The gateway,   G1, checks its routing table and obtains the address of the next   gateway, G2, on the route to the datagram's internet destination   network, X. If G2 and the host identified by the internet source   address of the datagram are on the same network, a redirect   message is sent to the host. The redirect message advises the   host to send its traffic for network X directly to gateway G2 as   this is a shorter path to the destination. The gateway forwards   the original datagram's data to its internet destination.     For datagrams with the IP source route options and the gateway   address in the destination address field, a redirect message is   not sent even if there is a better route to the ultimate   destination than the next address in the source route.     Codes 0, 1, 2, and 3 may be received from a gateway.     [Page 13]     September 1981  RFC 792    Echo or Echo Reply Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Identifier | Sequence Number |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Data ...   +-+-+-+-+-     IP Fields:     Addresses     The address of the source in an echo message will be the   destination of the echo reply message. To form an echo reply   message, the source and destination addresses are simply reversed,   the type code changed to 0, and the checksum recomputed.     IP Fields:     Type     8 for echo message;     0 for echo reply message.     Code     0     Checksum     The checksum is the 16-bit ones
'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.   If the total length is odd, the received data is padded with one   octet of zeros for computing the checksum. This checksum may be   replaced in the future.     Identifier     If code = 0, an identifier to aid in matching echos and replies,   may be zero.     Sequence Number    [Page 14]    September 1981  RFC 792     If code = 0, a sequence number to aid in matching echos and   replies, may be zero.     Description     The data received in the echo message must be returned in the echo   reply message.     The identifier and sequence number may be used by the echo sender   to aid in matching the replies with the echo requests. For   example, the identifier might be used like a port in TCP or UDP to   identify a session, and the sequence number might be incremented   on each echo request sent. The echoer returns these same values   in the echo reply.     Code 0 may be received from a gateway or a host.     [Page 15]     September 1981  RFC 792    Timestamp or Timestamp Reply Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Identifier | Sequence Number |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Originate Timestamp |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Receive Timestamp |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Transmit Timestamp |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Addresses     The address of the source in a timestamp message will be the   destination of the timestamp reply message. To form a timestamp   reply message, the source and destination addresses are simply   reversed, the type code changed to 14, and the checksum   recomputed.     IP Fields:     Type     13 for timestamp message;     14 for timestamp reply message.     Code     0     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Identifier    [Page 16]    September 1981  RFC 792     If code = 0, an identifier to aid in matching timestamp and   replies, may be zero.     Sequence Number     If code = 0, a sequence number to aid in matching timestamp and   replies, may be zero.     Description     The data received (a timestamp) in the message is returned in the   reply together with an additional timestamp. The timestamp is 32   bits of milliseconds since midnight UT. One use of these   timestamps is described by Mills [5].     The Originate Timestamp is the time the sender last touched the   message before sending it, the Receive Timestamp is the time the   echoer first touched it on receipt, and the Transmit Timestamp is   the time the echoer last touched the message on sending it.     If the time is not available in miliseconds or cannot be provided   with respect to midnight UT then any time can be inserted in a   timestamp provided the high order bit of the timestamp is also set   to indicate this non-standard value.     The identifier and sequence number may be used by the echo sender   to aid in matching the replies with the requests. For example,   the identifier might be used like a port in TCP or UDP to identify   a session, and the sequence number might be incremented on each   request sent. The destination returns these same values in the   reply.     Code 0 may be received from a gateway or a host.     [Page 17]     September 1981  RFC 792    Information Request or Information Reply Message     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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Type | Code | Checksum |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Identifier | Sequence Number |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     IP Fields:     Addresses     The address of the source in a information request message will be   the destination of the information reply message. To form a   information reply message, the source and destination addresses   are simply reversed, the type code changed to 16, and the checksum   recomputed.     IP Fields:     Type     15 for information request message;     16 for information reply message.     Code     0     Checksum     The checksum is the 16-bit ones
'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.   This checksum may be replaced in the future.     Identifier     If code = 0, an identifier to aid in matching request and replies,   may be zero.     Sequence Number     If code = 0, a sequence number to aid in matching request and   replies, may be zero.    [Page 18]    September 1981  RFC 792     Description     This message may be sent with the source network in the IP header   source and destination address fields zero (which means
"this"
  network). The replying IP module should send the reply with the   addresses fully specified. This message is a way for a host to   find out the number of the network it is on.     The identifier and sequence number may be used by the echo sender   to aid in matching the replies with the requests. For example,   the identifier might be used like a port in TCP or UDP to identify   a session, and the sequence number might be incremented on each   request sent. The destination returns these same values in the   reply.     Code 0 may be received from a gateway or a host.     [Page 19]     September 1981  RFC 792    Summary of Message Types     0 Echo Reply     3 Destination Unreachable     4 Source Quench     5 Redirect     8 Echo     11 Time Exceeded     12 Parameter Problem     13 Timestamp     14 Timestamp Reply     15 Information Request     16 Information Reply    [Page 20]    September 1981  RFC 792    References     [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program   Protocol Specification," RFC 791, USC/Information Sciences   Institute, September 1981.     [2] Cerf, V.,
"The Catenet Model for Internetworking,"
IEN 48,   Information Processing Techniques Office, Defense Advanced   Research Projects Agency, July 1978.     [3] Strazisar, V., "Gateway Routing: An Implementation   Specification", IEN 30, Bolt Beranek and Newman, April 1979.     [4] Strazisar, V.,
"How to Build a Gateway"
, IEN 109, Bolt Beranek   and Newman, August 1979.     [5] Mills, D.,
"DCNET Internet Clock Service,"
RFC 778, COMSAT   Laboratories, April 1981.        Comments about this RFC:  RFC 792: type 17,18 ??Nothing? why? by lt (8/27/2005)  RFC 792: Hi,I just want a clarification, The RFC states this on page-5 and 6 "... by Sumsid (11/16/2005)  RFC 792: There is a small spelling error in this doc : " Also ICMP messages are only... by Arun Koshy (3/26/2004)  RFC 792: For more details on calculation of the checksum, read RFC 1071. by Birk (8/15/2005)  RFC 792: Smelling pistake: May the feeling of elitism be ephemeral. Try correcting... by iconoclast (1/21/2005)  RFC 792: Pls Specify the details in Simple format by sundar (8/23/2005)  RFC 792: hiyour wellcome in new room in paltalk ok by devin_63@hotmail.com (9/4/2004)  RFC 792: i need of new techonology documents by praveen (8/30/2005)  RFC 792: Hi, I'm trying to understand the ICMP, I wanna write a aplicattion like ping,... by Devhxx (11/4/2003)      Previous: RFC 0791 - Internet Protocol  Next: RFC 0793 - Transmission Control Protocol    */