From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc792.txt | 1218 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1218 insertions(+) create mode 100644 doc/rfc/rfc792.txt (limited to 'doc/rfc/rfc792.txt') 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] + -- cgit v1.2.3