summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc777.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc777.txt')
-rw-r--r--doc/rfc/rfc777.txt826
1 files changed, 826 insertions, 0 deletions
diff --git a/doc/rfc/rfc777.txt b/doc/rfc/rfc777.txt
new file mode 100644
index 0000000..9e0e5c8
--- /dev/null
+++ b/doc/rfc/rfc777.txt
@@ -0,0 +1,826 @@
+
+
+Network Working Group J. Postel
+Request for Comments: 777 ISI
+ April 1981
+Updates: IENs 109, 128
+Updates: RFC 760
+
+ Internet Control Message Protocol
+
+
+
+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.
+
+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 check these fields. Unless
+ otherwise noted under the individual format descriptions, the values
+ of the internet header fields are as follows:
+
+
+
+
+ [Page 1]
+
+
+ April 1981
+RFC 777
+
+
+
+ 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.
+
+ 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 2]
+
+
+April 1981
+RFC 777
+
+
+
+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 | 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.
+
+ 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, 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 sends a destination unreachable message to
+
+
+
+ [Page 3]
+
+
+ April 1981
+RFC 777
+
+
+
+ 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 return a destination
+ unreachable message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 4]
+
+
+April 1981
+RFC 777
+
+
+
+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 | 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.
+
+ 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
+ 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.
+
+
+
+
+
+
+ [Page 5]
+
+
+ April 1981
+RFC 777
+
+
+
+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 | Parameter | 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 = problem with option.
+
+ Parameter
+
+ If code = 0, IP option type.
+
+ 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 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 an option that is not implemented, or incorrect
+ arguments in an option. The gateway or host may also notify the
+ source host via the parameter problem message.
+
+
+
+
+
+[Page 6]
+
+
+April 1981
+RFC 777
+
+
+
+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 | 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
+
+ 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
+ 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.
+
+
+
+
+ [Page 7]
+
+
+ April 1981
+RFC 777
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 8]
+
+
+April 1981
+RFC 777
+
+
+
+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 | unused |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+ 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.
+
+ 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 9]
+
+
+ April 1981
+RFC 777
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]
+
+
+April 1981
+RFC 777
+
+
+
+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 | unused |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+ IP Fields:
+
+ Type
+
+ 8 for echo message;
+
+ 0 for echo reply message.
+
+ Description
+
+ The data received in the echo message must be returned in the echo
+ reply message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 11]
+
+
+ April 1981
+RFC 777
+
+
+
+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 | unused |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+ IP Fields:
+
+ Type
+
+ 13 for timestamp message;
+
+ 14 for timestamp reply message.
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 12]
+
+
+April 1981
+RFC 777
+
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 13]
+
+
+ April 1981
+RFC 777
+
+
+
+References
+
+ [1] Postel, J., ed., "DOD Standard Internet Protocol", IEN 128,
+ RFC 760, USC/Information Sciences Institute, NTIS ADA079730,
+ January 1980. Appears in: Computer Communication Review,
+ Special Interest Group on Data Communications, ACM, V.10, N.4,
+ October 1980.
+
+ [2] Cerf, V., "The Catenet Model for Internetworking," Information
+ Processing Techniques Office, Defense Advanced Research
+ Projects Agency, IEN 48, 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 14]
+ \ No newline at end of file