please dont rip this site

Scenix Lib IO OSI3 Tcpip Documentation Rfcs RFC792.TXT

 






       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]



file: /Techref/scenix/lib/io/osi3/tcpip/Documentation/RFCs/rfc792.txt, 31KB, , updated: 2005/8/19 18:11, local time: 2024/3/19 00:56,
TOP NEW HELP FIND: 
3.235.199.19:LOG IN

 ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://www.sxlist.com/Techref/scenix/lib/io/osi3/tcpip/Documentation/RFCs/rfc792.txt"> scenix lib io osi3 tcpip Documentation RFCs rfc792</A>

Did you find what you needed?

 

Welcome to sxlist.com!


Site supported by
sales, advertizing,
& kind contributors
just like you!

Please don't rip/copy
(here's why

Copies of the site on CD
are available at minimal cost.
 

Welcome to www.sxlist.com!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .