rfc792 (1 of 3)
Ron Natalie <ron>
ron at brl-adm.ARPA
Wed May 14 14:00:07 AEST 1986
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]
More information about the Mod.sources.doc
mailing list