home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-06-09 | 29.1 KB | 1,219 lines |
-
-
- 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]
-
-