`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
`
`1
`
`ARISTA 1113
`
`
`
`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 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
`
` 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
`
`2
`
`
`
` 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
`
`3
`
`
`
` 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.
`
`4
`
`
`
` 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 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 |
`
`5
`
`
`
` +‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
` | 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
`
`6
`
`
`
` 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:
`
`7
`
`
`
` 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.
`
`8
`
`
`
` [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:
`
`9
`
`
`
` 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 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 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.
`
`10
`
`
`
` [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
`
`11
`
`
`
` 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.
`
`12
`
`
`
` [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
`
`13
`
`
`
` 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.
`
`14
`
`
`
` [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
`
`15
`
`
`
` 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.
`
`16
`
`
`
` [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.
`
`17
`
`
`
` 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.
`
`18
`
`
`
` [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
`
`19
`
`
`
`[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.
`
`
`
` [Page 21]
`
`20