summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc792.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc792.txt')
-rw-r--r--doc/rfc/rfc792.txt1218
1 files changed, 1218 insertions, 0 deletions
diff --git a/doc/rfc/rfc792.txt b/doc/rfc/rfc792.txt
new file mode 100644
index 0000000..5c659e8
--- /dev/null
+++ b/doc/rfc/rfc792.txt
@@ -0,0 +1,1218 @@
+
+
+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 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
+
+
+
+ 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 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 21]
+