tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1716

 
 
 

Towards Requirements for IP Routers

Part 2 of 6, p. 35 to 69
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 35 
3.  LINK LAYER

Although  [INTRO:1] covers Link Layer standards (IP over foo, ARP,
etc.), this document anticipates that Link-Layer material will be
covered in a separate Link Layer Requirements document.  A Link-Layer
requirements document would be applicable to both hosts and routers.
Thus, this document will not obsolete the parts of [INTRO:1] that deal
with link-layer issues.

3.1  INTRODUCTION

   Routers have essentially the same Link Layer protocol requirements as
   other sorts of Internet systems.  These requirements are given in
   chapter 3 of Requirements for Internet Gateways [INTRO:1].  A router
   MUST comply with its requirements and SHOULD comply with its
   recommendations.  Since some of the material in that document has
   become somewhat dated, some additional requirements and explanations
   are included below.

   DISCUSSION:
      It is expected that the Internet community will produce a
      Requirements for Internet Link Layer standard which will supersede
      both this chapter and chapter 3 of [INTRO:1].


3.2  LINK/INTERNET LAYER INTERFACE

   Although this document does not attempt to specify the interface
   between the Link Layer and the upper layers, it is worth noting here
   that other parts of this document, particularly chapter 5, require
   various sorts of information to be passed across this layer boundary.

   This section uses the following definitions:

   o  Source physical address

      The source physical address is the Link Layer address of the host
      or router from which the packet was received.

   o  Destination physical address

      The destination physical address is the Link Layer address to
      which the packet was sent.

   The information that must pass from the Link Layer to the
   Internetwork Layer for each received packet is:

Top      Up      ToC       Page 36 
   (1)  The IP packet [5.2.2],

   (2)  The length of the data portion (i.e., not including the Link-
        Layer framing) of the Link Layer frame [5.2.2],

   (3)  The identity of the physical interface from which the IP packet
        was received [5.2.3], and

   (4)  The classification of the packet's destination physical address
        as a Link Layer unicast, broadcast, or multicast [4.3.2],
        [5.3.4].

   In addition, the Link Layer also should provide:

   (5)  The source physical address.

   The information that must pass from the Internetwork Layer to the
   Link Layer for each transmitted packet is:

   (1)  The IP packet [5.2.1]

   (2)  The length of the IP packet [5.2.1]

   (3)  The destination physical interface [5.2.1]

   (4)  The next hop IP address [5.2.1]

   In addition, the Internetwork Layer also should provide:

   (5)  The Link Layer priority value [5.3.3.2]

   The Link Layer must also notify the Internetwork Layer if the packet
   to be transmitted causes a Link Layer precedence-related error
   [5.3.3.3].

3.3  SPECIFIC ISSUES


3.3.1  Trailer Encapsulation

      Routers which can connect to 10Mb Ethernets MAY be able to receive
      and forward Ethernet packets encapsulated using the trailer
      encapsulation described in [LINK:1].  However, a router SHOULD NOT
      originate trailer encapsulated packets.  A router MUST NOT
      originate trailer encapsulated packets without first verifying,
      using the mechanism described in section 2.3.1 of [INTRO:2], that
      the immediate destination of the packet is willing and able to

Top      Up      ToC       Page 37 
      accept trailer-encapsulated packets.  A router SHOULD NOT agree
      (using these same mechanisms) to accept trailer-encapsulated
      packets.

3.3.2  Address Resolution Protocol - ARP

      Routers which implement ARP MUST be compliant and SHOULD be
      unconditionally compliant with the requirements in section 2.3.2
      of [INTRO:2].

      The link layer MUST NOT report a Destination Unreachable error to
      IP solely because there is no ARP cache entry for a destination.

      A router MUST not believe any ARP reply which claims that the Link
      Layer address of another host or router is a broadcast or
      multicast address.

3.3.3  Ethernet and 802.3 Coexistence

      Routers which can connect to 10Mb Ethernets MUST be compliant and
      SHOULD be unconditionally compliant with the requirements of
      Section [2.3.3] of [INTRO:2].

3.3.4  Maximum Transmission Unit - MTU

      The MTU of each logical interface MUST be configurable.

      Many Link Layer protocols define a maximum frame size that may be
      sent.  In such cases, a router MUST NOT allow an MTU to be set
      which would allow sending of frames larger than those allowed by
      the Link Layer protocol.  However, a router SHOULD be willing to
      receive a packet as large as the maximum frame size even if that
      is larger than the MTU.

      DISCUSSION:
         Note that this is a stricter requirement than imposed on hosts
         by [INTRO:2], which requires that the MTU of each physical
         interface be configurable.

         If a network is using an MTU smaller than the maximum frame
         size for the Link Layer, a router may receive packets larger
         than the MTU from hosts which are in the process of
         initializing themselves, or which have been misconfigured.

         In general, the Robustness Principle indicates that these
         packets should be successfully received, if at all possible.

Top      Up      ToC       Page 38 
3.3.5  Point-to-Point Protocol - PPP

      Contrary to [INTRO:1], the Internet does have a standard serial
      line protocol: the Point-to-Point Protocol (PPP), defined in
      [LINK:2], [LINK:3], [LINK:4], and [LINK:5].

      A serial line interface is any interface which is designed to send
      data over a telephone, leased, dedicated or direct line (either 2
      or 4 wire) using a standardized modem or bit serial interface
      (such as RS-232, RS-449 or V.35), using either synchronous or
      asynchronous clocking.

      A general purpose serial interface is a serial line interface
      which is not solely for use as an access line to a network for
      which an alternative IP link layer specification exists (such as
      X.25 or Frame Relay).

      Routers which contain such general purpose serial interfaces MUST
      implement PPP.

      PPP MUST be supported on all general purpose serial interfaces on
      a router.  The router MAY allow the line to be configured to use
      serial line protocols other than PPP, all general purpose serial
      interfaces MUST default to using PPP.

3.3.5.1  Introduction

         This section provides guidelines to router implementors so that
         they can ensure interoperability with other routers using PPP
         over either synchronous or asynchronous links.

         It is critical that an implementor understand the semantics of
         the option negotiation mechanism.  Options are a means for a
         local device to indicate to a remote peer what the local device
         will *accept* from the remote peer, not what it wishes to send.
         It is up to the remote peer to decide what is most convenient
         to send within the confines of the set of options that the
         local device has stated that it can accept.  Therefore it is
         perfectly acceptable and normal for a remote peer to ACK all
         the options indicated in an LCP Configuration Request (CR) even
         if the remote peer does not support any of those options.
         Again, the options are simply a mechanism for either device to
         indicate to its peer what it will accept, not necessarily what
         it will send.

Top      Up      ToC       Page 39 
3.3.5.2  Link Control Protocol (LCP) Options

         The PPP Link Control Protocol (LCP) offers a number of options
         that may be negotiated.  These options include (among others)
         address and control field compression, protocol field
         compression, asynchronous character map, Maximum Receive Unit
         (MRU), Link Quality Monitoring (LQM), magic number (for
         loopback detection), Password Authentication Protocol (PAP),
         Challenge Handshake Authentication Protocol (CHAP), and the
         32-bit Frame Check Sequence (FCS).

         A router MAY do address/control field compression on either
         synchronous or asynchronous links.  A router MAY do protocol
         field compression on either synchronous or asynchronous links.
         A router MAY indicate that it can accept these compressions,
         but MUST be able to accept uncompressed PPP header information
         even if it has indicated a willingness to receive compressed
         PPP headers.

         DISCUSSION:
            These options control the appearance of the PPP header.
            Normally the PPP header consists of the address field (one
            byte containing the value 0xff), the control field (one byte
            containing the value 0x03), and the two-byte protocol field
            that identifies the contents of the data area of the frame.
            If a system negotiates address and control field compression
            it indicates to its peer that it will accept PPP frames that
            have or do not have these fields at the front of the header.
            It does not indicate that it will be sending frames with
            these fields removed.  The protocol field may also be
            compressed from two to one byte in most cases.


         IMPLEMENTATION:
            Some hardware does not deal well with variable length header
            information.  In those cases it makes most sense for the
            remote peer to send the full PPP header.  Implementations
            may ensure this by not sending the address/control field and
            protocol field compression options to the remote peer.  Even
            if the remote peer has indicated an ability to receive
            compressed headers there is no requirement for the local
            router to send compressed headers.

         A router MUST negotiate the Async Control Character Map (ACCM)
         for asynchronous PPP links, but SHOULD NOT negotiate the ACCM
         for synchronous links.  If a router receives an attempt to
         negotiate the ACCM over a synchronous link, it MUST ACKnowledge

Top      Up      ToC       Page 40 
         the option and then ignore it.

         DISCUSSION:
            There are implementations that offer both sync and async
            modes of operation and may use the same code to implement
            the option negotiation.  In this situation it is possible
            that one end or the other may send the ACCM option on a
            synchronous link.

         A router SHOULD properly negotiate the maximum receive unit
         (MRU).  Even if a system negotiates an MRU smaller than 1,500
         bytes, it MUST be able to receive a 1,500 byte frame.

         A router SHOULD negotiate and enable the link quality
         monitoring (LQM) option.

         DISCUSSION:
            This memo does not specify a policy for deciding whether the
            link's quality is adequate.  However, it is important (see
            Section [3.3.6]) that a router disable failed links.

         A router SHOULD implement and negotiate the magic number option
         for loopback detection.

         A router MAY support the authentication options (PAP - password
         authentication protocol, and/or CHAP - challenge handshake
         authentication protocol).

         A router MUST support 16-bit CRC frame check sequence (FCS) and
         MAY support the 32-bit CRC.

3.3.5.3  IP Control Protocol (ICP) Options

         A router MAY offer to perform IP address negotiation.  A router
         MUST accept a refusal (REJect) to perform IP address
         negotiation from the peer.

         A router SHOULD NOT perform Van Jacobson header compression of
         TCP/IP packets if the link speed is in excess of 64 Kbps.
         Below that speed the router MAY perform Van Jacobson (VJ)
         header compression.  At link speeds of 19,200 bps or less the
         router SHOULD perform VJ header compression.

Top      Up      ToC       Page 41 
3.3.6  Interface Testing

      A router MUST have a mechanism to allow routing software to
      determine whether a physical interface is available to send
      packets or not.  A router SHOULD have a mechanism to allow routing
      software to judge the quality of a physical interface.  A router
      MUST have a mechanism for informing the routing software when a
      physical interface becomes available or unavailable to send
      packets because of administrative action.  A router MUST have a
      mechanism for informing the routing software when it detects a
      Link level interface has become available or unavailable, for any
      reason.

      DISCUSSION:
         It is crucial that routers have workable mechanisms for
         determining that their network connections are functioning
         properly, since failure to do so (or failure to take the proper
         actions when a problem is detected) can lead to black holes.

         The mechanisms available for detecting problems with network
         connections vary considerably, depending on the Link Layer
         protocols in use and also in some cases on the interface
         hardware chosen by the router manufacturer.  The intent is to
         maximize the capability to detect failures within the Link-
         Layer constraints.

Top      Up      ToC       Page 42 
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 which 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]), and IP broadcast (defined in
      [INTERNET:3]).

      A router  MUST be compliant, and SHOULD be unconditionally
      compliant, with the requirements of sections 3.2.1 and 3.3 of
      [INTRO:2], except that:

      o  Section 3.2.1.1 may be ignored, since it duplicates
         requirements found in this memo.

      o  Section 3.2.1.2 may be ignored, since it duplicates
         requirements found in this memo.

      o  Section 3.2.1.3 should be ignored, since it is superseded by
         Section [4.2.2.11] of this memo.

      o  Section 3.2.1.4 may be ignored, since it duplicates
         requirements found in this memo.

      o  Section 3.2.1.6 should be ignored, since it is superseded by
         Section [4.2.2.4] of this memo.

      o  Section 3.2.1.8 should be ignored, since it is superseded by
         Section [4.2.2.1] of this memo.

      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

Top      Up      ToC       Page 43 
      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 record the event in a statistics counter.

4.2.2  PROTOCOL WALK-THROUGH

      RFC 791 is [INTERNET:1], 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 those 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

Top      Up      ToC       Page 44 
              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 (i.e., the pointer points beyond
              the last field and the destination address in the IP
              header addresses the router), the packet 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).

              In order to respond correctly to source-routed datagrams
              it receives, a router MUST provide a means whereby
              transport protocols and applications can reverse the
              source route in a received datagram and insert the
              reversed source route into datagrams they originate (see
              Section 4 of [INTRO:2] for details).

              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, 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

Top      Up      ToC       Page 45 
                 (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
                 timestamp 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.

              o  A timestamp value MUST follow the rules given in
                 Section [3.2.2.8] of [INTRO:2].

              IMPLEMENTATION:
                 To maximize the utility of the timestamps contained in
                 the timestamp option, it is suggested that the
                 timestamp inserted 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

Top      Up      ToC       Page 46 
                 transmission.


4.2.2.2  Addresses in Options: RFC-791 Section 3.1

         When a router inserts its address into a Record Route, Strict
         Source and Record Route, Loose Source and Record Route, or
         Timestamp, 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.  Which of the router's addresses is used as the
         router-id MUST NOT change (even across reboots) unless changed
         by the network manager or unless the configuration of the
         router is changed 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 which 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.

Top      Up      ToC       Page 47 
         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 which is received.  The router MUST NOT
         provide a means to disable this checksum verification.

         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.

Top      Up      ToC       Page 48 
         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 MUST send the fragments in order.  A fragmentation method
         which may generate one IP fragment which 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 hopefully 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 per page 26 of [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.  In general, this allows 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 (such as an 802.5 network
            with a MTU of 2048 or an Ethernet network with an MTU of
            1536).

            One other fragmentation technique discussed was splitting
            the IP datagram into approximately equal sized IP fragments,
            with the size being smaller than the next hop network's MTU.
            This is intended to minimize the number of fragments that
            would result from additional fragmentation further down the

Top      Up      ToC       Page 49 
            path.

            In most cases, routers should try and create situations that
            will generate the lowest number of IP fragments possible.

            Work with slow machines leads us to believe that if it is
            necessary to send small packets in a fragmentation scheme,
            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 Section 3.3.2 of [INTRO:2], a router MUST
         support reassembly of datagrams which 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].  Note in particular
         that a router MUST NOT check the TTL of a packet except when
         forwarding it.

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

         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.

         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: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 Unicast (that
         is class A, B, and C) IP addresses, using the following
         notation for an IP address:

Top      Up      ToC       Page 50 
            { <Network-number>, <Host-number> }

         or

            { <Network-number>, <Subnet-number>, <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.  This
         notation is not intended to imply that the 1-bits in a subnet
         mask need be contiguous.

         (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

Top      Up      ToC       Page 51 
              routers except that the router MAY uses 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-number>, -1 }

              Network Directed Broadcast - a broadcast directed to the
              specified network.  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)  { <Network-number>, <Subnet-number>, -1 }

              Subnetwork Directed Broadcast - a broadcast sent to the
              specified subnet.  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.

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

              All Subnets Directed Broadcast - a broadcast sent to all
              subnets of the specified subnetted network.  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.

Top      Up      ToC       Page 52 
         (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
         [4.2.3.1].

         Since (as described in Section [4.2.1]) a router must support
         the subnet extensions to IP, there will be a subnet mask of the
         form: { -1, -1, 0 } associated with each of the host's local IP
         addresses; see Sections [4.3.3.9], [5.2.4.2], and [10.2.2].

         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 which the router is
            interested in.

         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

Top      Up      ToC       Page 53 
         section.  This validation could be done either by the IP layer
         or by each protocol in the transport layer.

         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, { <Network-number>, -1 }, { <Network-
              number>, <Subnet-number>, -1 }, and { <Network-number>,
              -1, -1 }.

         (2)  SHOULD silently discard on receipt (i.e., don't even
              deliver to applications in the router) any packet
              addressed to 0.0.0.0, { <Network-number>, 0 }, {
              <Network-number>, <Subnet-number>, 0 }, or { <Network-
              number>, 0, 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 network or subnet (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, {
              <Network-number>, 0 }, { <Network-number>, <Subnet-
              number>, 0 }, or { <Network-number>, 0, 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.

Top      Up      ToC       Page 54 
         DISCUSSION:
            In the second bullet, the router obviously cannot recognize
            addresses of the form { <Network-number>, <Subnet-number>, 0
            } if the router does not know how the particular network is
            subnetted.  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 Section 3.3.7 of [INTRO:2].
         An IP router SHOULD support local IP multicasting on all
         connected networks for which a mapping from Class D IP
         addresses to link-layer addresses has been specified (see the
         various IP-over-xxx specifications), and on all connected
         point-to-point links.  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

         In order 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

Top      Up      ToC       Page 55 
         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 via a
         path which is not part of the subnetted network.  This is known
         as discontiguous subnetwork support.

         Routers MUST support discontiguous subnetworks.

         IMPLEMENTATION:
            In general, a router should not make assumptions about what
            are subnets and what are not, but simply ignore the concept
            of Class in networks, and treat each route as a { network,
            mask }-tuple.


         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 numbers to their networks and
            aggregate several network numbers into a single route
            advertisement.  By eliminating the strict class boundaries
            of the IP address and treating each route as a {network
            number, mask}-tuple these strains may be greatly reduced.

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

         Furthermore, for similar reasons, a subnetted network need not
         have a consistent subnet mask through all parts of the network.
         For example, one subnet may use an 8 bit subnet mask, another
         10 bit, and another 6 bit.  This is known as variable subnet-

Top      Up      ToC       Page 56 
         masks.

         Routers MUST support variable subnet-masks.

4.3  INTERNET CONTROL MESSAGE PROTOCOL - ICMP


4.3.1  INTRODUCTION

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

      ICMP messages are grouped in two classes which 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 doesn't have one).

Top      Up      ToC       Page 57 
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 which triggered the response.

4.3.2.3  Original Message Header

         Every ICMP error message includes the Internet header and at
         least the first 8 data bytes of the datagram that triggered the
         error.  More than 8 bytes MAY be sent, but the resulting ICMP
         datagram SHOULD have a length of less than or equal to 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, 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 which 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.

         EDITOR'S COMMENTS:
            The following paragraph originally read:

               ICMP error messages MUST have their IP Precedence field

Top      Up      ToC       Page 58 
               set to the same value as the IP Precedence field in the
               packet which provoked the sending of the ICMP error
               message, except that the precedence value MUST be 6
               (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL), SHOULD be
               7, and MAY be settable for the following types of ICMP
               error messages: Unreachable, Redirect, Time Exceeded, and
               Parameter Problem.

            I believe that the following paragraph is equivalent and
            easier for humans to parse (Source Quench is the only other
            ICMP Error message).  Other interpretations of the original
            are sought.

         ICMP Source Quench error messages MUST have their IP Precedence
         field set to the same value as the IP Precedence field in the
         packet which provoked the sending of the ICMP Source Quench
         message.  All other ICMP error messages (Destination
         Unreachable, Redirect, Time Exceeded, and Parameter Problem)
         MUST have their precedence value set to 6 (INTERNETWORK
         CONTROL) or 7 (NETWORK CONTROL), SHOULD be 7.  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.

         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.

Top      Up      ToC       Page 59 
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 number 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

Top      Up      ToC       Page 60 
            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, 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

Top      Up      ToC       Page 61 
                 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 route can not forward a packet because it has no routes at
         all to the destination network 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 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 host on the
         same subnet that the router used by the host to route certain
         packets should be changed.

Top      Up      ToC       Page 62 
         Contrary to section 3.2.2.2 of [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 which 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 MUST fulfill requirements of [INTRO:2], section
         [3.3.2] apply.

         When the router receives (i.e., is destined for the router) a
         Time Exceeded message, it MUST comply with section 3.2.2.4 of

Top      Up      ToC       Page 63 
         [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 and sends corresponding Echo Replies.  A
         router MUST be prepared to receive, reassemble and echo an ICMP
         Echo Request datagram at least as large 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 which, 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 results from the conclusions reached
            in section [3.2.2.6] of [INTRO:2].

         As stated in Section [10.3.3], a router MUST also implement an
         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

Top      Up      ToC       Page 64 
         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.

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 numbers 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.

Top      Up      ToC       Page 65 
         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 subnet
         mask.

         A router MUST NOT respond to an Address Mask Request which has

Top      Up      ToC       Page 66 
         a source address of 0.0.0.0 and which arrives on a physical
         interface which has associated with it multiple logical
         interfaces and the subnet masks for those interfaces are not
         all the same.

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

         Because hosts may not be able to learn the subnet 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 subnet masks.
         However, this feature can be dangerous in environments which
         use variable length subnet 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 the same IP network number and physical interface but
            have different subnet masks.

         The { <Network-number>, -1, -1 } form (on subnetted networks)
         or the { <Network-number>, -1 } form (on non-subnetted
         networks) 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 which intentionally lie
            to their hosts about the subnet 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 networks or subnets are in
            use on the same physical network.

Top      Up      ToC       Page 67 
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 of 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 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.

Top      Up      ToC       Page 68 
5.  INTERNET LAYER - FORWARDING


5.1  INTRODUCTION

   This section describes the process of forwarding packets.

5.2  FORWARDING WALK-THROUGH

   There is no separate specification of the forwarding function in IP.
   Instead, forwarding is covered by the protocol specifications for the
   internet layer protocols ([INTERNET:1], [INTERNET:2], [INTERNET:3],
   [INTERNET:8], and [ROUTE:11]).

5.2.1  Forwarding Algorithm

      Since none of the primary protocol documents describe the
      forwarding algorithm in any detail, we present it here.  This is
      just a general outline, and omits important details, such as
      handling of congestion, that are dealt with in later sections.

      It is not required that an implementation follow exactly the
      algorithms given in sections [5.2.1.1], [5.2.1.2], and [5.2.1.3].
      Much of the challenge of writing router software is to maximize
      the rate at which the router can forward packets while still
      achieving the same effect of the algorithm.  Details of how to do
      that are beyond the scope of this document, in part because they
      are heavily dependent on the architecture of the router.  Instead,
      we merely point out the order dependencies among the steps:

      (1)  A router MUST verify the IP header, as described in section
           [5.2.2], before performing any actions based on the contents
           of the header.  This allows the router to detect and discard
           bad packets before the expenditure of other resources.

      (2)  Processing of certain IP options requires that the router
           insert its IP address into the option.  As noted in Section
           [5.2.4], the address inserted MUST be the address of the
           logical interface on which the packet is sent or the router's
           router-id if the packet is sent over an unnumbered interface.
           Thus, processing of these options cannot be completed until
           after the output interface is chosen.

      (3)  The router cannot check and decrement the TTL before checking
           whether the packet should be delivered to the router itself,
           for reasons mentioned in Section [4.2.2.9].

Top      Up      ToC       Page 69 
      (4)  More generally, when a packet is delivered locally to the
           router, its IP header MUST NOT be modified in any way (except
           that a router may be required to insert a timestamp into any
           Timestamp options in the IP header).  Thus, before the router
           determines whether the packet is to be delivered locally to
           the router, it cannot update the IP header in any way that it
           is not prepared to undo.

5.2.1.1  General

         This section covers the general forwarding algorithm.  This
         algorithm applies to all forms of packets to be forwarded:
         unicast, multicast, and broadcast.


         (1)  The router receives the IP packet (plus additional
              information about it, as described in Section [3.1]) from
              the Link Layer.

         (2)  The router validates the IP header, as described in
              Section [5.2.2].  Note that IP reassembly is not done,
              except on IP fragments to be queued for local delivery in
              step (4).

         (3)  The router performs most of the processing of any IP
              options.  As described in Section [5.2.4], some IP options
              require additional processing after the routing decision
              has been made.

         (4)  The router examines the destination IP address of the IP
              datagram, as described in Section [5.2.3], to determine
              how it should continue to process the IP datagram.  There
              are three possibilities:

              o  The IP datagram is destined for the router, and should
                 be queued for local delivery, doing reassembly if
                 needed.

              o  The IP datagram is not destined for the router, and
                 should be queued for forwarding.

              o  The IP datagram should be queued for forwarding, but (a
                 copy) must also be queued for local delivery.


Next RFC Part