RFC 1122:Requirements for Internet Hosts -- Commun...
RFC-Ref

3. INTERNET LAYER PROTOCOLS

3.1. INTRODUCTION

The Robustness Principle: "Be liberal in what you accept, and conservative in what you send" is particularly important in the Internet layer, where one misbehaving host can deny Internet service to many other hosts.

The protocol standards used in the Internet layer are:

Other important references are listed in Section 5 of this document.

The Internet layer of host software MUST implement both IP and ICMP. See Section 3.3.7 for the requirements on support of IGMP.

The host IP layer has two basic functions: (1) choose the "next hop" gateway or host for outgoing IP datagrams and (2) reassemble incoming IP datagrams. The IP layer may also (3) implement intentional fragmentation of outgoing datagrams. Finally, the IP layer must (4) provide diagnostic and error functionality. We expect that IP layer functions may increase somewhat in the future, as further Internet control and management facilities are developed.

For normal datagrams, the processing is straightforward. For incoming datagrams, the IP layer:

  1. verifies that the datagram is correctly formatted;
  2. verifies that it is destined to the local host;
  3. processes options;
  4. reassembles the datagram if necessary; and
  5. passes the encapsulated message to the appropriate transport-layer protocol module.

For outgoing datagrams, the IP layer:

  1. sets any fields not set by the transport layer;
  2. selects the correct first hop on the connected network (a process called "routing");
  3. fragments the datagram if necessary and if intentional fragmentation is implemented (see Section 3.3.3); and
  4. passes the packet(s) to the appropriate link-layer driver.

A host is said to be multihomed if it has multiple IP addresses. Multihoming introduces considerable confusion and complexity into the protocol suite, and it is an area in which the Internet architecture falls seriously short of solving all problems. There are two distinct problem areas in multihoming:

  1. Local multihoming -- the host itself is multihomed; or
  2. Remote multihoming -- the local host needs to communicate with a remote multihomed host.

At present, remote multihoming MUST be handled at the application layer, as discussed in the companion RFC [INTRO:1]. A host MAY support local multihoming, which is discussed in this document, and in particular in Section 3.3.4.

Any host that forwards datagrams generated by another host is acting as a gateway and MUST also meet the specifications laid out in the gateway requirements RFC [INTRO:2]. An Internet host that includes embedded gateway code MUST have a configuration switch to disable the gateway function, and this switch MUST default to the non-gateway mode. In this mode, a datagram arriving through one interface will not be forwarded to another host or gateway (unless it is source-routed), regardless of whether the host is single- homed or multihomed. The host software MUST NOT automatically move into gateway mode if the host has more than one interface, as the operator of the machine may neither want to provide that service nor be competent to do so.

In the following, the action specified in certain cases is to "silently discard" a received datagram. This means that the datagram will be discarded without further processing and that the host will not send any ICMP error message (see Section 3.2.2) as a result. However, for diagnosis of problems a host SHOULD provide the capability of logging the error (see Section 1.2.3), including the contents of the silently-discarded datagram, and SHOULD record the event in a statistics counter.

DISCUSSION:

Silent discard of erroneous datagrams is generally intended to prevent "broadcast storms".

3.2. PROTOCOL WALK-THROUGH

3.2.1. Internet Protocol -- IP

3.2.1.1. Version Number: RFC-791std5 Section 3.1

A datagram whose version number is not 4 MUST be silently discarded.

3.2.1.2. Checksum: RFC-791std5 Section 3.1

A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum.

3.2.1.3. Addressing: RFC-791std5 Section 3.2

There are now five classes of IP addresses: Class A through Class E. Class D addresses are used for IP multicasting [IP:4], while Class E addresses are reserved for experimental use.

A multicast (Class D) address is a 28-bit logical address that stands for a group of hosts, and may be either permanent or transient. Permanent multicast addresses are allocated by the Internet Assigned Number Authority [INTRO:6], while transient addresses may be allocated dynamically to transient groups. Group membership is determined dynamically using IGMP [IP:4].

We now summarize the important special cases for Class A, B, and C IP addresses, using the following notation for an IP address: 

                { <Network-number>, <Host-number> }

or 

   
             { <Network-number>, <Subnet-number>, <Host-number> }

and the notation "-1" for a field that contains all 1 bits. This notation is not intended to imply that the 1-bits in an address mask need be contiguous. 

            (a)  { 0, 0 }

                 This host on this network.  MUST NOT be sent, except as
                 a source address as part of an initialization procedure
                 by which the host learns its own IP address.

                 See also Section 3.3.6 for a non-standard use of {0,0}.

            (b)  { 0, <Host-number> }

                 Specified host on this network.  It MUST NOT be sent,
                 except as a source address as part of an initialization
                 procedure by which the host learns its full IP address.

            (c)  { -1, -1 }

                 Limited broadcast.  It MUST NOT be used as a source
                 address.

                 A datagram with this destination address will be
                 received by every host on the connected physical
                 network but will not be forwarded outside that network.

            (d)  { <Network-number>, -1 }

                 Directed broadcast to the specified network.  It MUST
                 NOT be used as a source address.

            (e)  { <Network-number>, <Subnet-number>, -1 }

                 Directed broadcast to the specified subnet.  It MUST
                 NOT be used as a source address.

            (f)  { <Network-number>, -1, -1 }

                 Directed broadcast to all subnets of the specified
                 subnetted network.  It MUST NOT be used as a source
                 address.

            (g)  { 127, <any> }

                 Internal host loopback address.  Addresses of this form
                 MUST NOT appear outside a host.

The <Network-number> is administratively assigned so that its value will be unique in the entire world.

IP addresses are not permitted to have the value 0 or -1 for any of the <Host-number>, <Network-number>, or <Subnet- number> fields (except in the special cases listed above). This implies that each of these fields will be at least two bits long.

For further discussion of broadcast addresses, see Section 3.3.6.

A host MUST support the subnet extensions to IP [IP:3]. As a result, there will be an address mask of the form: {-1, -1, 0} associated with each of the host's local IP addresses; see Sections 3.2.2.9 and 3.3.1.1.

When a host sends any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or multicast address).

A host MUST silently discard an incoming datagram that is not destined for the host. An incoming datagram is destined for the host if the datagram's destination address field is:

  1. (one of) the host's IP address(es); or
  2. an IP broadcast address valid for the connected network; or
  3. the address for a multicast group of which the host is a member on the incoming physical interface.

For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; we use the term "specific-destination address" for the equivalent local IP address of the host. The specific-destination address is defined to be the destination address in the IP header unless the header contains a broadcast or multicast address, in which case the specific-destination is an IP address assigned to the physical interface on which the datagram arrived.

A host MUST silently discard an incoming datagram containing an IP source address that is invalid by the rules of this section. This validation could be done in either the IP layer or by each protocol in the transport layer.

DISCUSSION:

A mis-addressed datagram might be caused by a link- layer broadcast of a unicast datagram or by a gateway or host that is confused or mis-configured.

An architectural goal for Internet hosts was to allow IP addresses to be featureless 32-bit numbers, avoiding algorithms that required a knowledge of the IP address format. Otherwise, any future change in the format or interpretation of IP addresses will require host software changes. However, validation of broadcast and multicast addresses violates this goal; a few other violations are described elsewhere in this document.

Implementers should be aware that applications depending upon the all-subnets directed broadcast address (f) may be unusable on some networks. All- subnets broadcast is not widely implemented in vendor gateways at present, and even when it is implemented, a particular network administration may disable it in the gateway configuration.

3.2.1.4. Fragmentation and Reassembly: RFC-791std5 Section 3.2

The Internet model requires that every host support reassembly. See Sections 3.3.2 and 3.3.3 for the requirements on fragmentation and reassembly.

3.2.1.5. Identification: RFC-791std5 Section 3.2

When sending an identical copy of an earlier datagram, a host MAY optionally retain the same Identification field in the copy.

DISCUSSION:

Some Internet protocol experts have maintained that when a host sends an identical copy of an earlier datagram, the new copy should contain the same Identification value as the original. There are two suggested advantages: (1) if the datagrams are fragmented and some of the fragments are lost, the receiver may be able to reconstruct a complete datagram from fragments of the original and the copies; (2) a congested gateway might use the IP Identification field (and Fragment Offset) to discard duplicate datagrams from the queue.

However, the observed patterns of datagram loss in the Internet do not favor the probability of retransmitted fragments filling reassembly gaps, while other mechanisms (e.g., TCP repacketizing upon retransmission) tend to prevent retransmission of an identical datagram [IP:9]. Therefore, we believe that retransmitting the same Identification field is not useful. Also, a connectionless transport protocol like UDP would require the cooperation of the application programs to retain the same Identification value in identical datagrams.

3.2.1.6. Type-of-Service: RFC-791std5 Section 3.2

The "Type-of-Service" byte in the IP header is divided into two sections: the Precedence field (high-order 3 bits), and a field that is customarily called "Type-of-Service" or "TOS" (low-order 5 bits). In this document, all references to "TOS" or the "TOS field" refer to the low-order 5 bits only.

The Precedence field is intended for Department of Defense applications of the Internet protocols. The use of non-zero values in this field is outside the scope of this document and the IP standard specification. Vendors should consult the Defense Communication Agency (DCA) for guidance on the IP Precedence field and its implications for other protocol layers. However, vendors should note that the use of precedence will most likely require that its value be passed between protocol layers in just the same way as the TOS field is passed.

The IP layer MUST provide a means for the transport layer to set the TOS field of every datagram that is sent; the default is all zero bits. The IP layer SHOULD pass received

TOS values up to the transport layer.

The particular link-layer mappings of TOS contained in RFC-795 SHOULD NOT be implemented.

DISCUSSION:

While the TOS field has been little used in the past, it is expected to play an increasing role in the near future. The TOS field is expected to be used to control two aspects of gateway operations: routing and queueing algorithms. See Section 2 of [INTRO:1] for the requirements on application programs to specify TOS values.

The TOS field may also be mapped into link-layer service selectors. This has been applied to provide effective sharing of serial lines by different classes of TCP traffic, for example. However, the mappings suggested in RFC-795 for networks that were included in the Internet as of 1981 are now obsolete.

3.2.1.7. Time-to-Live: RFC-791std5 Section 3.2

A host MUST NOT send a datagram with a Time-to-Live (TTL) value of zero.

A host MUST NOT discard a datagram just because it was received with TTL less than 2.

The IP layer MUST provide a means for the transport layer to set the TTL field of every datagram that is sent. When a fixed TTL value is used, it MUST be configurable. The current suggested value will be published in the "Assigned Numbers" RFC.

DISCUSSION:

The TTL field has two functions: limit the lifetime of TCP segments (see RFC-793std7 [TCP:1], p. 28), and terminate Internet routing loops. Although TTL is a time in seconds, it also has some attributes of a hop- count, since each gateway is required to reduce the TTL field by at least one.

The intent is that TTL expiration will cause a datagram to be discarded by a gateway but not by the destination host; however, hosts that act as gateways by forwarding datagrams must follow the gateway rules for TTL.

A higher-layer protocol may want to set the TTL in order to implement an "expanding scope" search for some Internet resource. This is used by some diagnostic tools, and is expected to be useful for locating the "nearest" server of a given class using IP multicasting, for example. A particular transport protocol may also want to specify its own TTL bound on maximum datagram lifetime.

A fixed value must be at least big enough for the Internet "diameter," i.e., the longest possible path. A reasonable value is about twice the diameter, to allow for continued Internet growth.

3.2.1.8. Options: RFC-791std5 Section 3.2

There MUST be a means for the transport layer to specify IP options to be included in transmitted IP datagrams (see Section 3.4).

All IP options (except NOP or END-OF-LIST) received in datagrams MUST be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message). The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others.

Later sections of this document discuss specific IP option support required by each of ICMP, TCP, and UDP.

DISCUSSION:

Passing all received IP options to the transport layer is a deliberate "violation of strict layering" that is designed to ease the introduction of new transport- relevant IP options in the future. Each layer must pick out any options that are relevant to its own processing and ignore the rest. For this purpose, every IP option except NOP and END-OF-LIST will include a specification of its own length.

This document does not define the order in which a receiver must process multiple options in the same IP header. Hosts sending multiple options must be aware that this introduces an ambiguity in the meaning of certain options when combined with a source-route option.

IMPLEMENTATION:

The IP layer must not crash as the result of an option length that is outside the possible range. For example, erroneous option lengths have been observed to put some IP implementations into infinite loops.

Here are the requirements for specific IP options: 

            (a)  Security Option

                 Some environments require the Security option in every
                 datagram; such a requirement is outside the scope of
                 this document and the IP standard specification.  Note,
                 however, that the security options described in RFC-791std5
                 and RFC-1038(-> 1108hist) are obsolete.  For DoD applications,
                 vendors should consult [IP:8] for guidance.

            (b)  Stream Identifier Option

                 This option is obsolete; it SHOULD NOT be sent, and it
                 MUST be silently ignored if received.

            (c)  Source Route Options

                 A host MUST support originating a source route and MUST
                 be able to act as the final destination of a source
                 route.

                 If host receives a datagram containing a completed
                 source route (i.e., the pointer points beyond the last
                 field), the datagram has reached its final destination;
                 the option as received (the recorded route) MUST be
                 passed up to the transport layer (or to ICMP message
                 processing).  This recorded route will be reversed and
                 used to form a return source route for reply datagrams
                 (see discussion of IP Options in Section 4).  When a
                 return source route is built, it MUST be correctly
                 formed even if the recorded route included the source
                 host (see case (B) in the discussion below).

                 An IP header containing more than one Source Route
                 option MUST NOT be sent; the effect on routing of
                 multiple Source Route options is implementation-
                 specific.

                 Section 3.3.5 presents the rules for a host acting as
                 an intermediate hop in a source route, i.e., forwarding

                 a source-routed datagram.

                 DISCUSSION:
                      If a source-routed datagram is fragmented, each
                      fragment will contain a copy of the source route.
                      Since the processing of IP options (including a
                      source route) must precede reassembly, the
                      original datagram will not be reassembled until
                      the final destination is reached.

                      Suppose a source routed datagram is to be routed
                      from host S to host D via gateways G1, G2, ... Gn.
                      There was an ambiguity in the specification over
                      whether the source route option in a datagram sent
                      out by S should be (A) or (B):

                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT

                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG

                      (where >> represents the pointer).  If (A) is
                      sent, the datagram received at D will contain the
                      option: {G1, G2, ... Gn >>}, with S and D as the
                      IP source and destination addresses.  If (B) were
                      sent, the datagram received at D would again
                      contain S and D as the same IP source and
                      destination addresses, but the option would be:
                      {S, G1, ...Gn >>}; i.e., the originating host
                      would be the first hop in the route.

            (d)  Record Route Option

                 Implementation of originating and processing the Record
                 Route option is OPTIONAL.

            (e)  Timestamp Option

                 Implementation of originating and processing the
                 Timestamp option is OPTIONAL.  If it is implemented,
                 the following rules apply:

                 o    The originating host MUST record a timestamp in a
                      Timestamp option whose Internet address fields are
                      not pre-specified or whose first pre-specified
                      address is the host's interface address.

                 o    The destination host MUST (if possible) add the
                      current timestamp to a Timestamp option before
                      passing the option to the transport layer or to
                      ICMP for processing.

                 o    A timestamp value MUST follow the rules given in
                      Section 3.2.2.8 for the ICMP Timestamp message.

3.2.2. Internet Control Message Protocol -- ICMP

ICMP messages are grouped into two classes. 

         *
              ICMP error messages:

               Destination Unreachable   (see Section 3.2.2.1)
               Redirect                  (see Section 3.2.2.2)
               Source Quench             (see Section 3.2.2.3)
               Time Exceeded             (see Section 3.2.2.4)
               Parameter Problem         (see Section 3.2.2.5)

         *
              ICMP query messages:

                Echo                     (see Section 3.2.2.6)
                Information              (see Section 3.2.2.7)
                Timestamp                (see Section 3.2.2.8)
                Address Mask             (see Section 3.2.2.9)

If an ICMP message of unknown type is received, it MUST be silently discarded.

Every ICMP error message includes the Internet header and at least the first 8 data octets of the datagram that triggered the error; more than 8 octets MAY be sent; this header and data MUST be unchanged from the received datagram.

In those cases where the Internet layer is required to pass an ICMP error message to the transport layer, the IP protocol number MUST be extracted from the original header and used to select the appropriate transport protocol entity to handle the error.

An ICMP error message SHOULD be sent with normal (i.e., zero) TOS bits.

An ICMP error message MUST NOT be sent as the result of receiving:

NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.

DISCUSSION:

These rules will prevent the "broadcast storms" that have resulted from hosts returning ICMP error messages in response to broadcast datagrams. For example, a broadcast UDP segment to a non-existent port could trigger a flood of ICMP Destination Unreachable datagrams from all machines that do not have a client for that destination port. On a large Ethernet, the resulting collisions can render the network useless for a second or more.

Every datagram that is broadcast on the connected network should have a valid IP broadcast address as its IP destination (see Section 3.3.6). However, some hosts violate this rule. To be certain to detect broadcast datagrams, therefore, hosts are required to check for a link-layer broadcast as well as an IP-layer broadcast address.

IMPLEMENTATION:

This requires that the link layer inform the IP layer when a link-layer broadcast datagram has been received; see Section 2.4.

3.2.2.1. Destination Unreachable: RFC-792std5

The following additional codes are hereby defined: 

                    6 = destination network unknown

                    7 = destination host unknown

                    8 = source host isolated

                    9 = communication with destination network
                            administratively prohibited

                   10 = communication with destination host
                            administratively prohibited

                   11 = network unreachable for type of service

                   12 = host unreachable for type of service

A host SHOULD generate Destination Unreachable messages with code: 

            2    (Protocol Unreachable), when the designated transport
                 protocol is not supported; or

            3    (Port Unreachable), when the designated transport
                 protocol (e.g., UDP) is unable to demultiplex the
                 datagram but has no protocol mechanism to inform the
                 sender.

A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose.

A Destination Unreachable message that is received with code 0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a routing transient and MUST therefore be interpreted as only a hint, not proof, that the specified destination is unreachable [IP:11]. For example, it MUST NOT be used as proof of a dead gateway (see Section 3.3.1).

3.2.2.2. Redirect: RFC-792std5

A host SHOULD NOT send an ICMP Redirect message; Redirects are to be sent only by gateways.

A host receiving a Redirect message MUST update its routing information accordingly. Every host MUST be prepared to accept both Host and Network Redirects and to process them as described in Section 3.3.1.2 below.

A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-) net through which the Redirect arrived [INTRO:2, Appendix A], or if the source of the Redirect is not the current first-hop gateway for the specified destination (see Section 3.3.1).

3.2.2.3. Source Quench: RFC-792std5

A host MAY send a Source Quench message if it is approaching, or has reached, the point at which it is forced to discard incoming datagrams due to a shortage of reassembly buffers or other resources. See Section 2.2.3 of [INTRO:2] for suggestions on when to send Source Quench.

If a Source Quench message is received, the IP layer MUST report it to the transport layer (or ICMP processing). In general, the transport or application layer SHOULD implement a mechanism to respond to Source Quench for any protocol that can send a sequence of datagrams to the same destination and which can reasonably be expected to maintain enough state information to make this feasible. See Section 4 for the handling of Source Quench by TCP and UDP.

DISCUSSION:

A Source Quench may be generated by the target host or by some gateway in the path of a datagram. The host receiving a Source Quench should throttle itself back for a period of time, then gradually increase the transmission rate again. The mechanism to respond to Source Quench may be in the transport layer (for connection-oriented protocols like TCP) or in the application layer (for protocols that are built on top of UDP).

A mechanism has been proposed [IP:14] to make the IP layer respond directly to Source Quench by controlling the rate at which datagrams are sent, however, this proposal is currently experimental and not currently recommended.

3.2.2.4. Time Exceeded: RFC-792std5

An incoming Time Exceeded message MUST be passed to the transport layer.

DISCUSSION:

A gateway will send a Time Exceeded Code 0 (In Transit) message when it discards a datagram due to an expired TTL field. This indicates either a gateway routing loop or too small an initial TTL value.

A host may receive a Time Exceeded Code 1 (Reassembly Timeout) message from a destination host that has timed out and discarded an incomplete datagram; see Section 3.3.2 below. In the future, receipt of this message might be part of some "MTU discovery" procedure, to discover the maximum datagram size that can be sent on the path without fragmentation.

3.2.2.5. Parameter Problem: RFC-792std5

A host SHOULD generate Parameter Problem messages. An incoming Parameter Problem message MUST be passed to the transport layer, and it MAY be reported to the user.

DISCUSSION:

The ICMP Parameter Problem message is sent to the source host for any problem not specifically covered by another ICMP message. Receipt of a Parameter Problem message generally indicates some local or remote implementation error.

A new variant on the Parameter Problem message is hereby defined: 

              Code 1 = required option is missing.

DISCUSSION:

This variant is currently in use in the military community for a missing security option.

3.2.2.6. Echo Request/Reply: RFC-792std5

Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A host SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes.

An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.

DISCUSSION:

This neutral provision results from a passionate debate between those who feel that ICMP Echo to a broadcast address provides a valuable diagnostic capability and those who feel that misuse of this feature can too easily create packet storms.

The IP source address in an ICMP Echo Reply MUST be the same as the specific-destination address (defined in Section 3.2.1.3) of the corresponding ICMP Echo Request message.

Data received in an ICMP Echo Request MUST be entirely included in the resulting Echo Reply. However, if sending the Echo Reply requires intentional fragmentation that is not implemented, the datagram MUST be truncated to maximum transmission size (see Section 3.3.3) and sent.

Echo Reply messages MUST be passed to the ICMP user interface, unless the corresponding Echo Request originated in the IP layer.

If a Record Route and/or Time Stamp option is received in an ICMP Echo Request, this option (these options) SHOULD be updated to include the current host and included in the IP header of the Echo Reply message, without "truncation". Thus, the recorded route will be for the entire round trip.

If a Source Route option is received in an ICMP Echo Request, the return route MUST be reversed and used as a Source Route option for the Echo Reply message.

3.2.2.7. Information Request/Reply: RFC-792std5

A host SHOULD NOT implement these messages.

DISCUSSION:

The Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations, to allow them to discover their IP network numbers at boot time. However, the RARP and BOOTP protocols provide better mechanisms for a host to discover its own IP address.

3.2.2.8. Timestamp and Timestamp Reply: RFC-792std5

A host MAY implement Timestamp and Timestamp Reply. If they are implemented, the following rules MUST be followed.

  • The ICMP Timestamp server function returns a Timestamp Reply to every Timestamp message that is received. If this function is implemented, it SHOULD be designed for minimum variability in delay (e.g., implemented in the kernel to avoid delay in scheduling a user process).

The following cases for Timestamp are to be handled according to the corresponding rules for ICMP Echo:

The preferred form for a timestamp value (the "standard value") is in units of milliseconds since midnight Universal Time. However, it may be difficult to provide this value with millisecond resolution. For example, many systems use clocks that update only at line frequency, 50 or 60 times per second. Therefore, some latitude is allowed in a "standard value": 

            (a)  A "standard value" MUST be updated at least 15 times
                 per second (i.e., at most the six low-order bits of the
                 value may be undefined).

            (b)  The accuracy of a "standard value" MUST approximate
                 that of operator-set CPU clocks, i.e., correct within a
                 few minutes.

3.2.2.9. Address Mask Request/Reply: RFC-950std5

A host MUST support the first, and MAY implement all three, of the following methods for determining the address mask(s) corresponding to its IP address(es):

  1. static configuration information;
  2. obtaining the address mask(s) dynamically as a side- effect of the system initialization process (see [INTRO:1]); and
  3. sending ICMP Address Mask Request(s) and receiving ICMP Address Mask Reply(s).

The choice of method to be used in a particular host MUST be configurable.

When method (3), the use of Address Mask messages, is enabled, then: 

            (a)  When it initializes, the host MUST broadcast an Address
                 Mask Request message on the connected network
                 corresponding to the IP address.  It MUST retransmit
                 this message a small number of times if it does not
                 receive an immediate Address Mask Reply.

            (b)  Until it has received an Address Mask Reply, the host
                 SHOULD assume a mask appropriate for the address class
                 of the IP address, i.e., assume that the connected
                 network is not subnetted.

            (c)  The first Address Mask Reply message received MUST be
                 used to set the address mask corresponding to the
                 particular local IP address.  This is true even if the
                 first Address Mask Reply message is "unsolicited", in
                 which case it will have been broadcast and may arrive
                 after the host has ceased to retransmit Address Mask
                 Requests.  Once the mask has been set by an