4. INTERNET LAYER - PROTOCOLS

4.1 INTRODUCTION

   This chapter and chapter 5 discuss the protocols used at the Internet
   Layer: IP, ICMP, and IGMP.  Since forwarding is obviously a crucial
   topic in a document discussing routers, chapter 5 limits itself to
   the aspects of the protocols that directly relate to forwarding.  The
   current chapter contains the remainder of the discussion of the
   Internet Layer protocols.

4.2 INTERNET PROTOCOL - IP

4.2.1 INTRODUCTION

   Routers MUST implement the IP protocol, as defined by [INTERNET:1].
   They MUST also implement its mandatory extensions: subnets (defined
   in [INTERNET:2]), IP broadcast (defined in [INTERNET:3]), and
   Classless Inter-Domain Routing (CIDR, defined in [INTERNET:15]).

   Router implementors need not consider compliance with the section of
   [INTRO:2] entitled "Internet Protocol -- IP," as that section is
   entirely duplicated or superseded in this document.  A router MUST be
   compliant, and SHOULD be unconditionally compliant, with the
   requirements of the section entitled "SPECIFIC ISSUES" relating to IP
   in [INTRO:2].

   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 router will
   not send any ICMP error message (see Section [4.3]) as a result.
   However, for diagnosis of problems a router SHOULD provide the
   capability of logging the error (see Section [1.3.3]), including the
   contents of the silently discarded datagram, and SHOULD count
   datagrams discarded.

4.2.2 PROTOCOL WALK-THROUGH

   RFC 791 [INTERNET:1] is the specification for the Internet Protocol.

4.2.2.1 Options: RFC 791 Section 3.2

   In datagrams received by the router itself, the IP layer MUST
   interpret IP options that it understands and preserve the rest
   unchanged for use by higher layer protocols.

   Higher layer protocols may require the ability to set IP options in
   datagrams they send or examine IP options in datagrams they receive.
   Later sections of this document discuss specific IP option support
   required by higher layer protocols.

   DISCUSSION
      Neither this memo nor [INTRO:2] define the order in which a
      receiver must process multiple options in the same IP header.
      Hosts and routers originating datagrams containing multiple
      options must be aware that this introduces an ambiguity in the
      meaning of certain options when combined with a source-route
      option.

   Here are the requirements for specific IP options:

   (a) Security Option

        Some environments require the Security option in every packet
        originated or received.  Routers SHOULD IMPLEMENT the revised
        security option described in [INTERNET:5].

   DISCUSSION
      Note that the security options described in [INTERNET:1] and RFC
      1038 ([INTERNET:16]) are obsolete.

   (b) Stream Identifier Option

         This option is obsolete; routers SHOULD NOT place this option
         in a datagram that the router originates.  This option MUST be
         ignored in datagrams received by the router.

   (c) Source Route Options

         A router MUST be able to act as the final destination of a
         source route.  If a router receives a packet containing a
         completed source route, the packet has reached its final
         destination.  In such an option, the pointer points beyond the
         last field and the destination address in the IP header

         addresses the router.  The option as received (the recorded
         route) MUST be passed up to the transport layer (or to ICMP
         message processing).

         In the general case, a correct response to a source-routed
         datagram traverses the same route.  A router MUST provide a
         means whereby transport protocols and applications can reverse
         the source route in a received datagram.  This reversed source
         route MUST be inserted into datagrams they originate (see
         [INTRO:2] for details) when the router is unaware of policy
         constraints.  However, if the router is policy aware, it MAY
         select another path.

         Some applications in the router MAY require that the user be
         able to enter a source route.

         A router MUST NOT originate a datagram containing multiple
         source route options.  What a router should do if asked to
         forward a packet containing multiple source route options is
         described in Section [5.2.4.1].

         When a source route option is created (which would happen when
         the router is originating a source routed datagram or is
         inserting a source route option as a result of a special
         filter), it MUST be correctly formed even if it is being
         created by reversing a recorded route that erroneously includes
         the source host (see case (B) in the discussion below).

   DISCUSSION
      Suppose a source routed datagram is to be routed from source _S to
      destination D via routers G1, G2, Gn.  Source S constructs a
      datagram with G1's IP address as its destination address, and a
      source route option to get the datagram the rest of the way to its
      destination.  However, there is 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

         Routers MAY support the Record Route option in datagrams
         originated by the router.

   (e) Timestamp Option

         Routers MAY support the timestamp option in datagrams
         originated by the router.  The following rules apply:

         o When originating a datagram containing a Timestamp Option, a
            router MUST record a timestamp in the option if

            - Its Internet address fields are not pre-specified or
            - Its first pre-specified address is the IP address of the
               logical interface over which the datagram is being sent
               (or the router's router-id if the datagram is being sent
               over an unnumbered interface).

         o If the router itself receives a datagram containing a
            Timestamp Option, the router MUST insert the current time
            into the Timestamp Option (if there is space in the option
            to do so) before passing the option to the transport layer
            or to ICMP for processing.  If space is not present, the
            router MUST increment the Overflow Count in the option.

         o A timestamp value MUST follow the rules defined in [INTRO:2].

   IMPLEMENTATION
      To maximize the utility of the timestamps contained in the
      timestamp option, the timestamp inserted should be, as nearly as
      practical, the time at which the packet arrived at the router.
      For datagrams originated by the router, the timestamp inserted
      should be, as nearly as practical, the time at which the datagram
      was passed to the Link Layer for transmission.

      The timestamp option permits the use of a non-standard time clock,
      but the use of a non-synchronized clock limits the utility of the
      time stamp.  Therefore, routers are well advised to implement the
      Network Time Protocol for the purpose of synchronizing their
      clocks.

4.2.2.2 Addresses in Options: RFC 791 Section 3.1

   Routers are called upon to insert their address into Record Route,
   Strict Source and Record Route, Loose Source and Record Route, or
   Timestamp Options.  When a router inserts its address into such an
   option, it MUST use the IP address of the logical interface on which

   the packet is being sent.  Where this rule cannot be obeyed because
   the output interface has no IP address (i.e., is an unnumbered
   interface), the router MUST instead insert its router-id.  The
   router's router-id is one of the router's IP addresses.  The Router
   ID may be specified on a system basis or on a per-link basis.  Which
   of the router's addresses is used as the router-id MUST NOT change
   (even across reboots) unless changed by the network manager.
   Relevant management changes include reconfiguration of the router
   such that the IP address used as the router-id ceases to be one of
   the router's IP addresses.  Routers with multiple unnumbered
   interfaces MAY have multiple router-id's.  Each unnumbered interface
   MUST be associated with a particular router-id.  This association
   MUST NOT change (even across reboots) without reconfiguration of the
   router.

   DISCUSSION
      This specification does not allow for routers that do not have at
      least one IP address.  We do not view this as a serious
      limitation, since a router needs an IP address to meet the
      manageability requirements of Chapter [8] even if the router is
      connected only to point-to-point links.

   IMPLEMENTATION

      One possible method of choosing the router-id that fulfills this
      requirement is to use the numerically smallest (or greatest) IP
      address (treating the address as a 32-bit integer) that is
      assigned to the router.

4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1

   The IP header contains two reserved bits: one in the Type of Service
   byte and the other in the Flags field.  A router MUST NOT set either
   of these bits to one in datagrams originated by the router.  A router
   MUST NOT drop (refuse to receive or forward) a packet merely because
   one or more of these reserved bits has a non-zero value; i.e., the
   router MUST NOT check the values of thes bits.

   DISCUSSION
      Future revisions to the IP protocol may make use of these unused
      bits.  These rules are intended to ensure that these revisions can
      be deployed without having to simultaneously upgrade all routers
      in the Internet.

4.2.2.4 Type of Service: RFC 791 Section 3.1

   The Type-of-Service byte in the IP header is divided into three
   sections: the Precedence field (high-order 3 bits), a field that is
   customarily called Type of Service or TOS (next 4 bits), and a
   reserved bit (the low order bit).

   Rules governing the reserved bit were described in Section [4.2.2.3].

   A more extensive discussion of the TOS field and its use can be found
   in [ROUTE:11].

   The description of the IP Precedence field is superseded by Section
   [5.3.3].  RFC 795, Service Mappings, is obsolete and SHOULD NOT be
   implemented.

4.2.2.5 Header Checksum: RFC 791 Section 3.1

   As stated in Section [5.2.2], a router MUST verify the IP checksum of
   any packet that is received, and MUST discard messages containing
   invalid checksums.  The router MUST NOT provide a means to disable
   this checksum verification.

   A router MAY use incremental IP header checksum updating when the
   only change to the IP header is the time to live.  This will reduce
   the possibility of undetected corruption of the IP header by the
   router.  See [INTERNET:6] for a discussion of incrementally updating
   the checksum.

   IMPLEMENTATION
      A more extensive description of the IP checksum, including
      extensive implementation hints, can be found in [INTERNET:6] and
      [INTERNET:7].

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1

   A router MUST ignore IP options which it does not recognize.  A
   corollary of this requirement is that a router MUST implement the End
   of Option List option and the No Operation option, since neither
   contains an explicit length.

   DISCUSSION
      All future IP options will include an explicit length.

4.2.2.7 Fragmentation: RFC 791 Section 3.2

   Fragmentation, as described in [INTERNET:1], MUST be supported by a
   router.

   When a router fragments an IP datagram, it SHOULD minimize the number
   of fragments.  When a router fragments an IP datagram, it SHOULD send
   the fragments in order.  A fragmentation method that may generate one
   IP fragment that is significantly smaller than the other MAY cause
   the first IP fragment to be the smaller one.

   DISCUSSION
      There are several fragmentation techniques in common use in the
      Internet.  One involves splitting the IP datagram into IP
      fragments with the first being MTU sized, and the others being
      approximately the same size, smaller than the MTU.  The reason for
      this is twofold.  The first IP fragment in the sequence will be
      the effective MTU of the current path between the hosts, and the
      following IP fragments are sized to minimize the further
      fragmentation of the IP datagram.  Another technique is to split
      the IP datagram into MTU sized IP fragments, with the last
      fragment being the only one smaller, as described in [INTERNET:1].

      A common trick used by some implementations of TCP/IP is to
      fragment an IP datagram into IP fragments that are no larger than
      576 bytes when the IP datagram is to travel through a router.
      This is intended to allow the resulting IP fragments to pass the
      rest of the path without further fragmentation.  This would,
      though, create more of a load on the destination host, since it
      would have a larger number of IP fragments to reassemble into one
      IP datagram.  It would also not be efficient on networks where the
      MTU only changes once and stays much larger than 576 bytes.
      Examples include LAN networks such as an IEEE 802.5 network with a
      MTU of 2048 or an Ethernet network with an MTU of 1500).

      One other fragmentation technique discussed was splitting the IP
      datagram into approximately equal sized IP fragments, with the
      size less than or equal to the next hop network's MTU.  This is
      intended to minimize the number of fragments that would result
      from additional fragmentation further down the path, and assure
      equal delay for each fragment.

      Routers SHOULD generate the least possible number of IP fragments.

      Work with slow machines leads us to believe that if it is
      necessary to fragment messages, sending the small IP fragment
      first maximizes the chance of a host with a slow interface of
      receiving all the fragments.

4.2.2.8 Reassembly: RFC 791 Section 3.2

   As specified in the corresponding section of [INTRO:2], a router MUST
   support reassembly of datagrams that it delivers to itself.

4.2.2.9 Time to Live: RFC 791 Section 3.2

   Time to Live (TTL) handling for packets originated or received by the
   router is governed by [INTRO:2]; this section changes none of its
   stipulations.  However, since the remainder of the IP Protocol
   section of [INTRO:2] is rewritten, this section is as well.

   Note in particular that a router MUST NOT check the TTL of a packet
   except when forwarding it.

   A router MUST NOT originate or forward a datagram with a Time-to-Live
   (TTL) value of zero.

   A router MUST NOT discard a datagram just because it was received
   with TTL equal to zero or one; if it is to the router and otherwise
   valid, the router MUST attempt to receive it.

   On messages the router originates, 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 number SHOULD exceed the typical internet diameter, and current
   wisdom suggests that it should exceed twice the internet diameter to
   allow for growth.  Current suggested values are normally posted in
   the Assigned Numbers RFC.  The TTL field has two functions: limit the
   lifetime of TCP segments (see RFC 793 [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 router is required to
   reduce the TTL field by at least one.

   TTL expiration is intended to cause datagrams to be discarded by
   routers, but not by the destination host.  Hosts that act as routers
   by forwarding datagrams must therefore follow the router's 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 default 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.  As
   of this writing, messages crossing the United States frequently
   traverse 15 to 20 routers; this argues for a default TTL value in
   excess of 40, and 64 is a common value.

4.2.2.10 Multi-subnet Broadcasts: RFC 922

   All-subnets broadcasts (called multi-subnet broadcasts in
   [INTERNET:3]) have been deprecated.  See Section [5.3.5.3].

4.2.2.11 Addressing: RFC 791 Section 3.2

   As noted in 2.2.5.1, there are now five classes of IP addresses:
   Class A through Class E.  Class D addresses are used for IP
   multicasting [INTERNET:4], while Class E addresses are reserved for
   experimental use.  The distinction between Class A, B, and C
   addresses is no longer important; they are used as generalized
   unicast network prefixes with only historical interest in their
   class.

   An IP multicast 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:7], while transient addresses may be allocated
   dynamically to transient groups.  Group membership is determined
   dynamically using IGMP [INTERNET:4].

   We now summarize the important special cases for general purpose
   unicast IP addresses, using the following notation for an IP address:

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

   and the notation -1 for a field that contains all 1 bits and the
   notation 0 for a field that contains all 0 bits.

   (a) { 0, 0 }

        This host on this network.  It MUST NOT be used as a source
        address by routers, except the router MAY use this as a source
        address as part of an initialization procedure (e.g., if the
        router is using BOOTP to load its configuration information).

        Incoming datagrams with a source address of { 0, 0 } which are
        received for local delivery (see Section [5.2.3]), MUST be
        accepted if the router implements the associated protocol and
        that protocol clearly defines appropriate action to be taken.
        Otherwise, a router MUST silently discard any locally-delivered
        datagram whose source address is { 0, 0 }.

   DISCUSSION
      Some protocols define specific actions to take in response to a
      received datagram whose source address is { 0, 0 }.  Two examples
      are BOOTP and ICMP Mask Request.  The proper operation of these
      protocols often depends on the ability to receive datagrams whose
      source address is { 0, 0 }.  For most protocols, however, it is
      best to ignore datagrams having a source address of { 0, 0 } since
      they were probably generated by a misconfigured host or router.
      Thus, if a router knows how to deal with a given datagram having a
      { 0, 0 } source address, the router MUST accept it.  Otherwise,
      the router MUST discard it.

   See also Section [4.2.3.1] for a non-standard use of { 0, 0 }.

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

         Specified host on this network.  It MUST NOT be sent by routers
         except that the router MAY use this as a source address as part
         of an initialization procedure by which the it learns its own
         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 and router on the connected physical network, but
         will not be forwarded outside that network.

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

         Directed Broadcast - a broadcast directed to the specified
         network prefix.  It MUST NOT be used as a source address.  A
         router MAY originate Network Directed Broadcast packets.  A
         router MUST receive Network Directed Broadcast packets; however
         a router MAY have a configuration option to prevent reception
         of these packets.  Such an option MUST default to allowing
         reception.

    (e) { 127, <any> }

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

    The <Network-prefix> is administratively assigned so that its value
    will be unique in the routing domain to which the device is
    connected.

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

   DISCUSSION
      Previous versions of this document also noted that subnet numbers
      must be neither 0 nor -1, and must be at least two bits in length.
      In a CIDR world, the subnet number is clearly an extension of the
      network prefix and cannot be interpreted without the remainder of
      the prefix.  This restriction of subnet numbers is therefore
      meaningless in view of CIDR and may be safely ignored.

   For further discussion of broadcast addresses, see Section [4.2.3.1].

   When a router originates any datagram, the IP source address MUST be
   one of its own IP addresses (but not a broadcast or multicast
   address).  The only exception is during initialization.

   For most purposes, a datagram addressed to a broadcast or multicast
   destination is processed as if it had been addressed to one of the
   router's IP addresses; that is to say:

   o A router MUST receive and process normally any packets with a
      broadcast destination address.

   o A router MUST receive and process normally any packets sent to a
      multicast destination address that the router has asked to
      receive.

   The term specific-destination address means 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 router MUST silently discard any received datagram containing an IP
   source address that is invalid by the rules of this section.  This
   validation could be done either by the IP layer or (when appropriate)
   by each protocol in the transport layer.  As with any datagram a
   router discards, the datagram discard SHOULD be counted.

   DISCUSSION
      A misaddressed datagram might be caused by a Link Layer broadcast
      of a unicast datagram or by another router or host that is
      confused or misconfigured.

4.2.3 SPECIFIC ISSUES

4.2.3.1 IP Broadcast Addresses

   For historical reasons, there are a number of IP addresses (some
   standard and some not) which are used to indicate that an IP packet
   is an IP broadcast.  A router

   (1) MUST treat as IP broadcasts packets addressed to 255.255.255.255
        or { <Network-prefix>, -1 }.

   (2) SHOULD silently discard on receipt (i.e., do not even deliver to
        applications in the router) any packet addressed to 0.0.0.0 or {
        <Network-prefix>, 0 }.  If these packets are not silently
        discarded, they MUST be treated as IP broadcasts (see Section
        [5.3.5]).  There MAY be a configuration option to allow receipt
        of these packets.  This option SHOULD default to discarding
        them.

   (3) SHOULD (by default) use the limited broadcast address
        (255.255.255.255) when originating an IP broadcast destined for
        a connected (sub)network (except when sending an ICMP Address
        Mask Reply, as discussed in Section [4.3.3.9]).  A router MUST
        receive limited broadcasts.

   (4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or {
        <Network-prefix>, 0 }.  There MAY be a configuration option to
        allow generation of these packets (instead of using the relevant
        1s format broadcast).  This option SHOULD default to not
        generating them.

   DISCUSSION
      In the second bullet, the router obviously cannot recognize
      addresses of the form { <Network-prefix>, 0 } if the router has no
      interface to that network prefix.  In that case, the rules of the
      second bullet do not apply because, from the point of view of the
      router, the packet is not an IP broadcast packet.

4.2.3.2 IP Multicasting

   An IP router SHOULD satisfy the Host Requirements with respect to IP
   multicasting, as specified in [INTRO:2].  An IP router SHOULD support
   local IP multicasting on all connected networks.  When a mapping from
   IP multicast addresses to link-layer addresses has been specified
   (see the various IP-over-xxx specifications), it SHOULD use that
   mapping, and MAY be configurable to use the link layer broadcast
   instead.  On point-to-point links and all other interfaces,
   multicasts are encapsulated as link layer broadcasts.  Support for

   local IP multicasting includes originating multicast datagrams,
   joining multicast groups and receiving multicast datagrams, and
   leaving multicast groups.  This implies support for all of
   [INTERNET:4] including IGMP (see Section [4.4]).

   DISCUSSION
      Although [INTERNET:4] is entitled Host Extensions for IP
      Multicasting, it applies to all IP systems, both hosts and
      routers.  In particular, since routers may join multicast groups,
      it is correct for them to perform the host part of IGMP, reporting
      their group memberships to any multicast routers that may be
      present on their attached networks (whether or not they themselves
      are multicast routers).

      Some router protocols may specifically require support for IP
      multicasting (e.g., OSPF [ROUTE:1]), or may recommend it (e.g.,
      ICMP Router Discovery [INTERNET:13]).

4.2.3.3 Path MTU Discovery

   To eliminate fragmentation or minimize it, it is desirable to know
   what is the path MTU along the path from the source to destination.
   The path MTU is the minimum of the MTUs of each hop in the path.
   [INTERNET:14] describes a technique for dynamically discovering the
   maximum transmission unit (MTU) of an arbitrary internet path.  For a
   path that passes through a router that does not support
   [INTERNET:14], this technique might not discover the correct Path
   MTU, but it will always choose a Path MTU as accurate as, and in many
   cases more accurate than, the Path MTU that would be chosen by older
   techniques or the current practice.

   When a router is originating an IP datagram, it SHOULD use the scheme
   described in [INTERNET:14] to limit the datagram's size.  If the
   router's route to the datagram's destination was learned from a
   routing protocol that provides Path MTU information, the scheme
   described in [INTERNET:14] is still used, but the Path MTU
   information from the routing protocol SHOULD be used as the initial
   guess as to the Path MTU and also as an upper bound on the Path MTU.

4.2.3.4 Subnetting

   Under certain circumstances, it may be desirable to support subnets
   of a particular network being interconnected only through a path that
   is not part of the subnetted network.  This is known as discontiguous
   subnetwork support.

   Routers MUST support discontiguous subnetworks.

   IMPLEMENTATION
      In classical IP networks, this was very difficult to achieve; in
      CIDR networks, it is a natural by-product.  Therefore, a router
      SHOULD NOT make assumptions about subnet architecture, but SHOULD
      treat each route as a generalized network prefix.

   DISCUSSION The Internet has been growing at a tremendous rate of
      late.  This has been placing severe strains on the IP addressing
      technology.  A major factor in this strain is the strict IP
      Address class boundaries.  These make it difficult to efficiently
      size network prefixes to their networks and aggregate several
      network prefixes into a single route advertisement.  By
      eliminating the strict class boundaries of the IP address and
      treating each route as a generalized network prefix, these strains
      may be greatly reduced.

      The technology for currently doing this is Classless Inter Domain
      Routing (CIDR) [INTERNET:15].

   For similar reasons, an address block associated with a given network
   prefix could be subdivided into subblocks of different sizes, so that
   the network prefixes associated with the subblocks would have
   different length.  For example, within a block whose network prefix
   is 8 bits long, one subblock may have a 16 bit network prefix,
   another may have an 18 bit network prefix, and a third a 14 bit
   network prefix.

   Routers MUST support variable length network prefixes in both their
   interface configurations and their routing databases.

4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP

4.3.1 INTRODUCTION

   ICMP is an auxiliary protocol, which provides routing, diagnostic and
   error functionality for IP.  It is described in [INTERNET:8].  A
   router MUST support ICMP.

   ICMP messages are grouped in two classes that are discussed in the
   following sections:

   ICMP error messages:

   Destination Unreachable     Section 4.3.3.1
   Redirect                    Section 4.3.3.2
   Source Quench               Section 4.3.3.3
   Time Exceeded               Section 4.3.3.4
   Parameter Problem           Section 4.3.3.5

   ICMP query messages:
   Echo                        Section 4.3.3.6
   Information                 Section 4.3.3.7
   Timestamp                   Section 4.3.3.8
   Address Mask                Section 4.3.3.9
   Router Discovery            Section 4.3.3.10


   General ICMP requirements and discussion are in the next section.

4.3.2 GENERAL ISSUES

4.3.2.1 Unknown Message Types

   If an ICMP message of unknown type is received, it MUST be passed to
   the ICMP user interface (if the router has one) or silently discarded
   (if the router does not have one).

4.3.2.2 ICMP Message TTL

   When originating an ICMP message, the router MUST initialize the TTL.
   The TTL for ICMP responses must not be taken from the packet that
   triggered the response.

4.3.2.3 Original Message Header

   Historically, every ICMP error message has included the Internet
   header and at least the first 8 data bytes of the datagram that
   triggered the error.  This is no longer adequate, due to the use of
   IP-in-IP tunneling and other technologies.  Therefore, the ICMP
   datagram SHOULD contain as much of the original datagram as possible
   without the length of the ICMP datagram exceeding 576 bytes.  The
   returned IP header (and user data) MUST be identical to that which
   was received, except that the router is not required to undo any
   modifications to the IP header that are normally performed in
   forwarding that were performed before the error was detected (e.g.,
   decrementing the TTL, or updating options).  Note that the
   requirements of Section [4.3.3.5] supersede this requirement in some
   cases (i.e., for a Parameter Problem message, if the problem is in a
   modified field, the router must undo the modification).  See Section
   [4.3.3.5]).

4.3.2.4 ICMP Message Source Address

   Except where this document specifies otherwise, the IP source address
   in an ICMP message originated by the router MUST be one of the IP
   addresses associated with the physical interface over which the ICMP
   message is transmitted.  If the interface has no IP addresses

   associated with it, the router's router-id (see Section [5.2.5]) is
   used instead.

4.3.2.5 TOS and Precedence

   ICMP error messages SHOULD have their TOS bits set to the same value
   as the TOS bits in the packet that provoked the sending of the ICMP
   error message, unless setting them to that value would cause the ICMP
   error message to be immediately discarded because it could not be
   routed to its destination.  Otherwise, ICMP error messages MUST be
   sent with a normal (i.e., zero) TOS.  An ICMP reply message SHOULD
   have its TOS bits set to the same value as the TOS bits in the ICMP
   request that provoked the reply.

   ICMP Source Quench error messages, if sent at all, MUST have their IP
   Precedence field set to the same value as the IP Precedence field in
   the packet that provoked the sending of the ICMP Source Quench
   message.  All other ICMP error messages (Destination Unreachable,
   Redirect, Time Exceeded, and Parameter Problem) SHOULD have their
   precedence value set to 6 (INTERNETWORK CONTROL) or 7 (NETWORK
   CONTROL).  The IP Precedence value for these error messages MAY be
   settable.

   An ICMP reply message MUST have its IP Precedence field set to the
   same value as the IP Precedence field in the ICMP request that
   provoked the reply.

4.3.2.6 Source Route

   If the packet which provokes the sending of an ICMP error message
   contains a source route option, the ICMP error message SHOULD also
   contain a source route option of the same type (strict or loose),
   created by reversing the portion before the pointer of the route
   recorded in the source route option of the original packet UNLESS the
   ICMP error message is an ICMP Parameter Problem complaining about a
   source route option in the original packet, or unless the router is
   aware of policy that would prevent the delivery of the ICMP error
   message.

   DISCUSSION
      In environments which use the U.S.  Department of Defense security
      option (defined in [INTERNET:5]), ICMP messages may need to
      include a security option.  Detailed information on this topic
      should be available from the Defense Communications Agency.

4.3.2.7 When Not to Send ICMP Errors

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

   o An ICMP error message, or

   o A packet which fails the IP header validation tests described in
      Section [5.2.2] (except where that section specifically permits
      the sending of an ICMP error message), or

   o A packet destined to an IP broadcast or IP multicast address, or

   o A packet sent as a Link Layer broadcast or multicast, or

   o A packet whose source address has a network prefix of zero or is an
      invalid source address (as defined in Section [5.3.7]), or

   o Any fragment of a datagram other then the first fragment (i.e., a
      packet for which the fragment offset in the IP header is nonzero).

   Furthermore, an ICMP error message MUST NOT be sent in any case where
   this memo states that a packet is to be silently discarded.

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

   DISCUSSION
      These rules aim to prevent the broadcast storms that have resulted
      from routers or hosts returning ICMP error messages in response to
      broadcast packets.  For example, a broadcast UDP packet to a non-
      existent port could trigger a flood of ICMP Destination
      Unreachable datagrams from all devices 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 packet that is broadcast on the connected network should
      have a valid IP broadcast address as its IP destination (see
      Section [5.3.4] and [INTRO:2]).  However, some devices violate
      this rule.  To be certain to detect broadcast packets, therefore,
      routers are required to check for a link-layer broadcast as well
      as an IP-layer address.

   IMPLEMENTATION+ This requires that the link layer inform the IP layer
      when a link-layer broadcast packet has been received; see Section
      [3.1].

4.3.2.8 Rate Limiting

   A router which sends ICMP Source Quench messages MUST be able to
   limit the rate at which the messages can be generated.  A router
   SHOULD also be able to limit the rate at which it sends other sorts
   of ICMP error messages (Destination Unreachable, Redirect, Time
   Exceeded, Parameter Problem).  The rate limit parameters SHOULD be
   settable as part of the configuration of the router.  How the limits
   are applied (e.g., per router or per interface) is left to the
   implementor's discretion.

   DISCUSSION
      Two problems for a router sending ICMP error message are:
      (1) The consumption of bandwidth on the reverse path, and
      (2) The use of router resources (e.g., memory, CPU time)

      To help solve these problems a router can limit the frequency with
      which it generates ICMP error messages.  For similar reasons, a
      router may limit the frequency at which some other sorts of
      messages, such as ICMP Echo Replies, are generated.

   IMPLEMENTATION
      Various mechanisms have been used or proposed for limiting the
      rate at which ICMP messages are sent:

      (1) Count-based - for example, send an ICMP error message for
           every N dropped packets overall or per given source host.
           This mechanism might be appropriate for ICMP Source Quench,
           if used, but probably not for other types of ICMP messages.

      (2) Timer-based - for example, send an ICMP error message to a
           given source host or overall at most once per T milliseconds.

      (3) Bandwidth-based - for example, limit the rate at which ICMP
           messages are sent over a particular interface to some
           fraction of the attached network's bandwidth.

4.3.3 SPECIFIC ISSUES

4.3.3.1 Destination Unreachable

   If a router cannot forward a packet because it has no routes at all
   (including no default route) to the destination specified in the
   packet, then the router MUST generate a Destination Unreachable, Code
   0 (Network Unreachable) ICMP message.  If the router does have routes
   to the destination network specified in the packet but the TOS
   specified for the routes is neither the default TOS (0000) nor the
   TOS of the packet that the router is attempting to route, then the

   router MUST generate a Destination Unreachable, Code 11 (Network
   Unreachable for TOS) ICMP message.

   If a packet is to be forwarded to a host on a network that is
   directly connected to the router (i.e., the router is the last-hop
   router) and the router has ascertained that there is no path to the
   destination host then the router MUST generate a Destination
   Unreachable, Code 1 (Host Unreachable) ICMP message.  If a packet is
   to be forwarded to a host that is on a network that is directly
   connected to the router and the router cannot forward the packet
   because no route to the destination has a TOS that is either equal to
   the TOS requested in the packet or is the default TOS (0000) then the
   router MUST generate a Destination Unreachable, Code 12 (Host
   Unreachable for TOS) ICMP message.

   DISCUSSION
      The intent is that a router generates the "generic" host/network
      unreachable if it has no path at all (including default routes) to
      the destination.  If the router has one or more paths to the
      destination, but none of those paths have an acceptable TOS, then
      the router generates the "unreachable for TOS" message.

4.3.3.2 Redirect

   The ICMP Redirect message is generated to inform a local host that it
   should use a different next hop router for certain traffic.

   Contrary to [INTRO:2], a router MAY ignore ICMP Redirects when
   choosing a path for a packet originated by the router if the router
   is running a routing protocol or if forwarding is enabled on the
   router and on the interface over which the packet is being sent.

4.3.3.3 Source Quench

   A router SHOULD NOT originate ICMP Source Quench messages.  As
   specified in Section [4.3.2], a router that does originate Source
   Quench messages MUST be able to limit the rate at which they are
   generated.

   DISCUSSION
      Research seems to suggest that Source Quench consumes network
      bandwidth but is an ineffective (and unfair) antidote to
      congestion.  See, for example, [INTERNET:9] and [INTERNET:10].
      Section [5.3.6] discusses the current thinking on how routers
      ought to deal with overload and network congestion.

   A router MAY ignore any ICMP Source Quench messages it receives.

   DISCUSSION
      A router itself may receive a Source Quench as the result of
      originating a packet sent to another router or host.  Such
      datagrams might be, e.g., an EGP update sent to another router, or
      a telnet stream sent to a host.  A mechanism has been proposed
      ([INTERNET:11], [INTERNET:12]) to make the IP layer respond
      directly to Source Quench by controlling the rate at which packets
      are sent, however, this proposal is currently experimental and not
      currently recommended.

4.3.3.4 Time Exceeded

   When a router is forwarding a packet and the TTL field of the packet
   is reduced to 0, the requirements of section [5.2.3.8] apply.

   When the router is reassembling a packet that is destined for the
   router, it is acting as an Internet host.  [INTRO:2]'s reassembly
   requirements therefore apply.

   When the router receives (i.e., is destined for the router) a Time
   Exceeded message, it MUST comply with [INTRO:2].

4.3.3.5 Parameter Problem

   A router MUST generate a Parameter Problem message for any error not
   specifically covered by another ICMP message.  The IP header field or
   IP option including the byte indicated by the pointer field MUST be
   included unchanged in the IP header returned with this ICMP message.
   Section [4.3.2] defines an exception to this requirement.

   A new variant of the Parameter Problem message was defined in
   [INTRO:2]:
        Code 1 = required option is missing.

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

4.3.3.6 Echo Request/Reply

   A router MUST implement an ICMP Echo server function that receives
   Echo Requests sent to the router, and sends corresponding Echo
   Replies.  A router MUST be prepared to receive, reassemble and echo
   an ICMP Echo Request datagram at least as the maximum of 576 and the
   MTUs of all the connected networks.

   The Echo server function MAY choose not to respond to ICMP echo
   requests addressed to IP broadcast or IP multicast addresses.

   A router SHOULD have a configuration option that, if enabled, causes
   the router to silently ignore all ICMP echo requests; if provided,
   this option MUST default to allowing responses.

   DISCUSSION
      The neutral provision about responding to broadcast and multicast
      Echo Requests derives from [INTRO:2]'s "Echo Request/Reply"
      section.

   As stated in Section [10.3.3], a router MUST also implement a
   user/application-layer interface for sending an Echo Request and
   receiving an Echo Reply, for diagnostic purposes.  All ICMP Echo
   Reply messages MUST be passed to this interface.

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

   Data received in an ICMP Echo Request MUST be entirely included in
   the resulting Echo Reply.

   If a Record Route and/or Timestamp option is received in an ICMP Echo
   Request, this option (these options) SHOULD be updated to include the
   current router 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, unless the router is aware of policy that
   would prevent the delivery of the message.

4.3.3.7 Information Request/Reply

   A router SHOULD NOT originate or respond to 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 prefixes at boot time.  However,
      these messages are now obsolete.  The RARP and BOOTP protocols
      provide better mechanisms for a host to discover its own IP
      address.

4.3.3.8 Timestamp and Timestamp Reply

   A router MAY implement Timestamp and Timestamp Reply.  If they are
   implemented then:

   o The ICMP Timestamp server function MUST return a Timestamp Reply to
      every Timestamp message that is received.  It SHOULD be designed
      for minimum variability in delay.

   o An ICMP Timestamp Request message to an IP broadcast or IP
      multicast address MAY be silently discarded.

   o The IP source address in an ICMP Timestamp Reply MUST be the same
      as the specific-destination address of the corresponding Timestamp
      Request message.

   o If a Source Route option is received in an ICMP Timestamp Request,
      the return route MUST be reversed and used as a Source Route
      option for the Timestamp Reply message, unless the router is aware
      of policy that would prevent the delivery of the message.

   o If a Record Route and/or Timestamp option is received in a
      Timestamp Request, this (these) option(s) SHOULD be updated to
      include the current router and included in the IP header of the
      Timestamp Reply message.

   o If the router provides an application-layer interface for sending
      Timestamp Request messages then incoming Timestamp Reply messages
      MUST be passed up to the ICMP user interface.

   The preferred form for a timestamp value (the standard value) is
   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 16 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.

   IMPLEMENTATION
      To meet the second condition, a router may need to query some time
      server when the router is booted or restarted.  It is recommended
      that the UDP Time Server Protocol be used for this purpose.  A
      more advanced implementation would use the Network Time Protocol
      (NTP) to achieve nearly millisecond clock synchronization;
      however, this is not required.

4.3.3.9 Address Mask Request/Reply

   A router MUST implement support for receiving ICMP Address Mask
   Request messages and responding with ICMP Address Mask Reply
   messages.  These messages are defined in [INTERNET:2].

   A router SHOULD have a configuration option for each logical
   interface specifying whether the router is allowed to answer Address
   Mask Requests for that interface; this option MUST default to
   allowing responses.  A router MUST NOT respond to an Address Mask
   Request before the router knows the correct address mask.

   A router MUST NOT respond to an Address Mask Request that has a
   source address of 0.0.0.0 and which arrives on a physical interface
   that has associated with it multiple logical interfaces and the
   address masks for those interfaces are not all the same.

   A router SHOULD examine all ICMP Address Mask Replies that it
   receives to determine whether the information it contains matches the
   router's knowledge of the address mask.  If the ICMP Address Mask
   Reply appears to be in error, the router SHOULD log the address mask
   and the sender's IP address.  A router MUST NOT use the contents of
   an ICMP Address Mask Reply to determine the correct address mask.

   Because hosts may not be able to learn the address mask if a router
   is down when the host boots up, a router MAY broadcast a gratuitous
   ICMP Address Mask Reply on each of its logical interfaces after it
   has configured its own address masks.  However, this feature can be
   dangerous in environments that use variable length address masks.
   Therefore, if this feature is implemented, gratuitous Address Mask
   Replies MUST NOT be broadcast over any logical interface(s) which
   either:

   o Are not configured to send gratuitous Address Mask Replies.  Each
      logical interface MUST have a configuration parameter controlling
      this, and that parameter MUST default to not sending the
      gratuitous Address Mask Replies.

   o Share subsuming (but not identical) network prefixes and physical
      interface.

   The { <Network-prefix>, -1 } form of the IP broadcast address MUST be
   used for broadcast Address Mask Replies.

   DISCUSSION
      The ability to disable sending Address Mask Replies by routers is
      required at a few sites that intentionally lie to their hosts
      about the address mask.  The need for this is expected to go away

      as more and more hosts become compliant with the Host Requirements
      standards.

      The reason for both the second bullet above and the requirement
      about which IP broadcast address to use is to prevent problems
      when multiple IP network prefixes are in use on the same physical
      network.

4.3.3.10 Router Advertisement and Solicitations

   An IP router MUST support the router part of the ICMP Router
   Discovery Protocol [INTERNET:13] on all connected networks on which
   the router supports either IP multicast or IP broadcast addressing.
   The implementation MUST include all the configuration variables
   specified for routers, with the specified defaults.

   DISCUSSION
      Routers are not required to implement the host part of the ICMP
      Router Discovery Protocol, but might find it useful for operation
      while IP forwarding is disabled (i.e., when operating as a host).

   DISCUSSION We note that it is quite common for hosts to use RIP
      Version 1 as the router discovery protocol.  Such hosts listen to
      RIP traffic and use and use information extracted from that
      traffic to discover routers and to make decisions as to which
      router to use as a first-hop router for a given destination.
      While this behavior is discouraged, it is still common and
      implementors should be aware of it.

4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP

   IGMP [INTERNET:4] is a protocol used between hosts and multicast
   routers on a single physical network to establish hosts' membership
   in particular multicast groups.  Multicast routers use this
   information, in conjunction with a multicast routing protocol, to
   support IP multicast forwarding across the Internet.

   A router SHOULD implement the host part of IGMP.