REFERENCE

  o MUST
     This word means that the item is an absolute requirement of the
     specification.  Violation of such a requirement is a fundamental
     error; there is no case where it is justified.

REFERENCE

  o MUST IMPLEMENT
     This phrase means that this specification requires that the item be
     implemented, but does not require that it be enabled by default.

REFERENCE

  o MUST NOT
     This phrase means that the item is an absolute prohibition of the
     specification.

REFERENCE

  An implementation is said to be conditionally compliant if it
  satisfies all the Relevant MUST, MUST IMPLEMENT, and MUST NOT
  requirements.  An implementation is said to be unconditionally
  compliant if it is conditionally compliant and also satisfies all the
  Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT requirements.  An
  implementation is not compliant if it is not conditionally compliant
  (i.e., it fails to satisfy one or more of the Relevant MUST, MUST
  IMPLEMENT, or MUST NOT requirements).

REFERENCE

  Likewise, routers may provide, except where explicitly prohibited by
  this memo, options which cause them to violate MUST or MUST NOT
  requirements.  A router that provides such options is compliant
  (either fully or conditionally) if and only if each such option has a
  default setting that causes the router to conform to the requirements
  of this memo.  Please note that the authors of this memo, although
  aware of market realities, strongly recommend against provision of
  such options.  Requirements are labeled MUST or MUST NOT because
  experts in the field have judged them to be particularly important to
  interoperability or proper functioning in the Internet.  Vendors
  should weigh carefully the customer support costs of providing options
  that violate those rules.

REFERENCE

   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.

REFERENCE

   Routers that can connect to ten megabit 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 [INTRO:2], that the immediate destination of
   the packet is willing and able to accept trailer-encapsulated
   packets.  A router SHOULD NOT agree (using these mechanisms) to
   accept trailer-encapsulated packets.

REFERENCE

   Routers that implement ARP MUST be compliant and SHOULD be
   unconditionally compliant with the requirements in [INTRO:2].

REFERENCE

   The link layer MUST NOT report a Destination Unreachable error to IP
   solely because there is no ARP cache entry for a destination; it
   SHOULD queue up to a small number of datagrams breifly while
   performing the ARP request/reply sequence, and reply that the
   destination is unreachable to one of the queued datagrams only when
   this proves fruitless.

REFERENCE

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

REFERENCE

   Routers that can connect to ten megabit Ethernets MUST be compliant
   and SHOULD be unconditionally compliant with the Ethernet
   requirements of [INTRO:2].

REFERENCE

   The MTU of each logical interface MUST be configurable within the
   range of legal MTUs for the interface.

REFERENCE

   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.

REFERENCE

   Routers that implement point to point or general purpose serial
   interfaces MUST IMPLEMENT PPP.

REFERENCE

   PPP MUST be supported on all general purpose serial interfaces on a
   router.  The router MAY allow the line to be configured to use point
   to point line protocols other than PPP.  Point to point interfaces
   SHOULD either default to using PPP when enabled or require
   configuration of the link layer protocol before being enabled.
   General purpose serial interfaces SHOULD require configuration of the
   link layer protocol before being enabled.

REFERENCE

   A router MAY use address/control field compression on either
   synchronous or asynchronous links.  A router MAY use protocol field
   compression on either synchronous or asynchronous links.  A router
   that indicates that it can accept these compressions MUST be able to
   accept uncompressed PPP header information also.

REFERENCE

   A router MUST negotiate the Asynchronous 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 the option and then
   ignore it.

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

   A router MUST have a mechanism to allow routing software to determine
   whether a physical interface is available to send packets or not; on
   multiplexed interfaces where permanent virtual circuits are opened
   for limited sets of neighbors, the router must also be able to
   determine whether the virtual circuits are viable.  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.

REFERENCE

   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]).

REFERENCE

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

REFERENCE

   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.

REFERENCE

         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.

REFERENCE

         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

REFERENCE

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

REFERENCE

         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.

REFERENCE

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

REFERENCE

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

REFERENCE

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

REFERENCE

         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.

REFERENCE

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

REFERENCE

   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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

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

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

   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.

REFERENCE

         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.

REFERENCE

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

REFERENCE

         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.

REFERENCE

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

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

   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.

REFERENCE

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

REFERENCE

   (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 {
        , 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.

REFERENCE

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

REFERENCE

   Routers MUST support discontiguous subnetworks.

REFERENCE

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

REFERENCE

   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.

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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]).

REFERENCE

   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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   (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).

REFERENCE

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

REFERENCE

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

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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.

REFERENCE

   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:

REFERENCE

   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.

REFERENCE

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

REFERENCE

   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.

REFERENCE

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

REFERENCE

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

REFERENCE

   (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

REFERENCE

   Before a router can process any IP packet, it MUST perform a the
   following basic validity checks on the packet's IP header to ensure
   that the header is meaningful.  If the packet fails any of the
   following tests, it MUST be silently discarded, and the error SHOULD
   be logged.

REFERENCE

   A router MUST NOT have a configuration option that allows disabling
   any of these tests.

REFERENCE

   If the packet passes the second and third tests, the IP header length
   field is at least 4, and both the IP total length field and the
   packet length reported by the Link Layer are at least 16 then,
   despite the above rule, the router MAY respond with an ICMP Parameter
   Problem message, whose pointer points at the IP header length field
   (if it failed the fourth test) or the IP total length field (if it
   failed the fifth test).  However, it still MUST discard the packet
   and still SHOULD log the error.

REFERENCE

   Additionally, the router SHOULD verify that the packet length
   reported by the Link Layer is at least as large as the IP total
   length recorded in the packet's IP header.  If it appears that the
   packet has been truncated, the packet MUST be discarded, the error
   SHOULD be logged, and the router SHOULD respond with an ICMP
   Parameter Problem message whose pointer points at the IP total length
   field.

REFERENCE

   When a router receives an IP packet, it must decide whether the
   packet is addressed to the router (and should be delivered locally)
   or the packet is addressed to another system (and should be handled
   by the forwarder).  There is also a hybrid case, where certain IP
   broadcasts and IP multicasts are both delivered locally and
   forwarded.  A router MUST determine which of the these three cases
   applies using the following rules.

REFERENCE

   A router MUST use the IP Destination Address, not the Ultimate
   Destination Address (the last address in the source route option),
   when determining how to handle a packet.

REFERENCE

   After it has been determined that the IP packet needs to be forwarded
   according to the rules specified in Section [5.2.3], the following
   algorithm MUST be used to determine if the Immediate Destination is
   directly accessible (see [INTERNET:2]).

REFERENCE

      If the packet contains an SSRR, the router MUST discard the packet
      and reply with an ICMP Bad Source Route error.  Otherwise, the
      router looks up the IP Destination Address in its routing table to
      determine an appropriate next hop address.

REFERENCE

   With the exception of rule 3 (Weak TOS), a router MUST use the
   following Pruning Rules when selecting a next hop for a packet.  If a

REFERENCE

   router does consider TOS when making next-hop decisions, the Rule 3
   must be applied in the order indicated below.  These rules MUST be
   (conceptually) applied to the FIB in the order that they are
   presented.  (For some historical perspective, additional pruning
   rules, and other common algorithms in use, see Appendix E.)

REFERENCE

     If, after application of the pruning rules, the set of routes is
     empty (i.e., no routes were found), the packet MUST be discarded
     and an appropriate ICMP error generated (ICMP Bad Source Route if
     the IP Destination Address came from a source route option;
     otherwise, whichever of ICMP Destination Host Unreachable or
     Destination Network Unreachable is appropriate, as described in
     Section [4.3.3.1]).

REFERENCE

     The IP header contains several reserved bits, in the Type of
     Service field and in the Flags field.  Routers MUST NOT drop
     packets merely because one or more of these reserved bits has a
     non-zero value.

REFERENCE

     Routers MUST ignore and MUST pass through unchanged the values of
     these reserved bits.  If a router fragments a packet, it MUST copy
     these bits into each fragment.

REFERENCE

   As was discussed in Section [4.2.2.7], a router MUST support IP
   fragmentation.

REFERENCE

   A router MUST NOT reassemble any datagram before forwarding it.

REFERENCE

   A router MUST be able to generate ICMP Destination Unreachable
   messages and SHOULD choose a response code that most closely matches
   the reason the message is being generated.

REFERENCE

   Routers MUST use Host Unreachable or Destination Host Unknown codes
   whenever other hosts on the same destination network might be
   reachable; otherwise, the source host may erroneously conclude that
   all hosts on the network are unreachable, and that may not be the
   case.

REFERENCE

   [INTERNET:14] describes a slight modification the form of Destination
   Unreachable messages containing Code 4 (Fragmentation needed and DF
   set).  A router MUST use this modified form when originating Code 4
   Destination Unreachable messages.

REFERENCE

   Routers MUST NOT generate the Redirect for Network or Redirect for
   Network and Type of Service messages (Codes 0 and 2) specified in

REFERENCE

   [INTERNET:8].  Routers MUST be able to generate the Redirect for Host
   message (Code 1) and SHOULD be able to generate the Redirect for Type
   of Service and Host message (Code 3) specified in [INTERNET:8].

REFERENCE

   Routers that can generate Code 3 redirects (Host and Type of Service)
   MUST have a configuration option (which defaults to on) to enable
   Code 1 (Host) redirects to be substituted for Code 3 redirects.  A
   router MUST send a Code 1 Redirect in place of a Code 3 Redirect if
   it has been configured to do so.

REFERENCE

   If a router is not able to generate Code 3 Redirects then it MUST
   generate Code 1 Redirects in situations where a Code 3 Redirect is
   called for.

REFERENCE

   Routers MUST NOT generate a Redirect Message unless all the following
   conditions are met:

REFERENCE

   The source address used in the ICMP Redirect MUST belong to the same
   logical (sub)net as the destination address.

REFERENCE

   A router using a routing protocol (other than static routes) MUST NOT
   consider paths learned from ICMP Redirects when forwarding a packet.
   If a router is not using a routing protocol, a router MAY have a

REFERENCE

      On the other hand, when a router is not acting as a router, it
      MUST comply with the behavior required of a host.

REFERENCE

   A router MUST generate a Time Exceeded message Code 0 (In Transit)
   when it discards a packet due to an expired TTL field.  A router MAY
   have a per-interface option to disable origination of these messages
   on that interface, but that option MUST default to allowing the
   messages to be originated.

REFERENCE

   The Time-to-Live (TTL) field of the IP header is defined to be a
   timer limiting the lifetime of a datagram.  It is an 8-bit field and
   the units are seconds.  Each router (or other module) that handles a
   packet MUST decrement the TTL by at least one, even if the elapsed
   time was much less than a second.  Since this is very often the case,
   the TTL is effectively a hop count limit on how far a datagram can
   propagate through the Internet.

REFERENCE

   When a router forwards a packet, it MUST reduce the TTL by at least
   one.  If it holds a packet for more than one second, it MAY decrement
   the TTL by one for each second.

REFERENCE

   If the TTL is reduced to zero (or less), the packet MUST be
   discarded, and if the destination is not a multicast address the
   router MUST send an ICMP Time Exceeded message, Code 0 (TTL Exceeded
   in Transit) message to the source.  Note that a router MUST NOT
   discard an IP unicast or broadcast packet with a non-zero TTL merely
   because it can predict that another router on the path to the
   packet's final destination will decrement the TTL to zero.  However,
   a router MAY do so for IP multicasts, in order to more efficiently
   implement IP multicast's expanding ring search algorithm (see
   [INTERNET:4]).

REFERENCE

      A router MUST maintain a TOS value for each route in its routing
      table.  Routes learned through a routing protocol that does not
      support TOS MUST be assigned a TOS of zero (the default TOS).

REFERENCE

      To choose a route to a destination, a router MUST use an algorithm
      equivalent to the following:

REFERENCE

   DISCUSSION
      Although TOS has been little used in the past, its use by hosts is
      now mandated by the Requirements for Internet Hosts RFCs
      ([INTRO:2] and [INTRO:3]).  Support for TOS in routers may become
      a MUST in the future, but is a SHOULD for now until we get more
      experience with it and can better judge both its benefits and its
      costs.

REFERENCE

   Routers SHOULD implement precedence-ordered queue service.
   Precedence-ordered queue service means that when a packet is selected
   for output on a (logical) link, the packet of highest precedence that
   has been queued for that link is sent.  Routers that implement
   precedence-ordered queue service MUST also have a configuration
   option to suppress precedence-ordered queue service in the Internet
   Layer.

REFERENCE

   Any router MAY implement other policy-based throughput management
   procedures that result in other than strict precedence ordering, but
   it MUST be configurable to suppress them (i.e., use strict ordering).

REFERENCE

   Routers that implement precedence-ordered queuing MUST IMPLEMENT, and
   other routers SHOULD IMPLEMENT, Lower Layer Precedence Mapping.

REFERENCE

   o MUST be able to map IP Precedence to Link Layer priority mechanisms
      for link layers that have such a feature defined.

REFERENCE

   o MUST have a configuration option to select the Link Layer's default
      priority treatment for all IP traffic

REFERENCE

   (1) MUST accept and process incoming traffic of all precedence levels
        normally, unless it has been administratively configured to do
        otherwise.

REFERENCE

   (2) MAY implement a validation filter to administratively restrict
        the use of precedence levels by particular traffic sources.  If
        provided, this filter MUST NOT filter out or cut off the
        following sorts of ICMP error messages: Destination Unreachable,
        Redirect, Time Exceeded, and Parameter Problem.  If this filter
        is provided, the procedures required for packet filtering by
        addresses are required for this filter also.

REFERENCE

   (3) MAY implement a cutoff function that allows the router to be set
        to refuse or drop traffic with precedence below a specified
        level.  This function may be activated by management actions or
        by some implementation dependent heuristics, but there MUST be a
        configuration option to disable any heuristic mechanism that
        operates without human intervention.  An ICMP Destination
        Unreachable message with code 15 SHOULD be sent when a packet is
        dropped by the cutoff function, unless this has been suppressed
        by configuration choice.

REFERENCE

        A router MUST NOT refuse to forward datagrams with IP precedence
        of 6 (Internetwork Control) or 7 (Network Control) solely due to
        precedence cutoff.  However, other criteria may be used in
        conjunction with precedence cutoff to filter high precedence
        traffic.

REFERENCE

   (4) MUST NOT change precedence settings on packets it did not
        originate.

REFERENCE

   (7) MUST respond appropriately to Link Layer precedence-related error
        indications where provided.  An ICMP Destination Unreachable
        message with code 15 SHOULD be sent when a packet is dropped
        because a link cannot accept it due to a precedence-related
        condition, unless this has been suppressed by configuration
        choice.

REFERENCE

   A router MUST NOT forward any packet that the router received as a
   Link Layer broadcast, unless it is directed to an IP Multicast
   address.  In this latter case, one would presume that link layer
   broadcast was used due to the lack of an effective multicast service.

REFERENCE

   A router MUST NOT forward any packet which the router received as a
   Link Layer multicast unless the packet's destination address is an IP
   multicast address.

REFERENCE

   When a router sends a packet as a Link Layer broadcast, the IP
   destination address MUST be a legal IP broadcast or IP multicast
   address.

REFERENCE

   As was described in that section, packets addressed to any of these
   addresses SHOULD be silently discarded, but if they are not, they
   MUST be treated according to the same rules that apply to packets
   addressed to the non-obsolete forms of the broadcast addresses
   described above.  These rules are described in the next few sections.

REFERENCE

   Limited broadcasts MUST NOT be forwarded.  Limited broadcasts MUST
   NOT be discarded.  Limited broadcasts MAY be sent and SHOULD be sent
   instead of directed broadcasts where limited broadcasts will suffice.

REFERENCE

   A router MUST classify as network-prefix-directed broadcasts all
   valid, directed broadcasts destined for a remote network or an
   attached nonsubnetted network.  Note that in view of CIDR, such
   appear to be host addresses within the network prefix; we preclude
   inspection of the host part of such network prefixes.  Given a route
   and no overriding policy, then, a router MUST forward network-
   prefix-directed broadcasts.  Network-Prefix-Directed broadcasts MAY

REFERENCE

   A router MAY have an option to disable receiving network-prefix-
   directed broadcasts on an interface and MUST have an option to
   disable forwarding network-prefix-directed broadcasts.  These options
   MUST default to permit receiving and forwarding network-prefix-
   directed broadcasts.

REFERENCE

   o If precedence-ordered queue service (described in Section
      [5.3.3.1]) is implemented and enabled, the router MUST NOT discard
      a packet whose IP precedence is higher than that of a packet that
      is not discarded.

REFERENCE

   A router SHOULD NOT forward any packet that has an invalid IP source
   address or a source address on network 0.  A router SHOULD NOT
   forward, except over a loopback interface, any packet that has a
   source address on network 127.  A router MAY have a switch that
   allows the network manager to disable these checks.  If such a switch
   is provided, it MUST default to performing the checks.

REFERENCE

   A router SHOULD NOT forward any packet that has an invalid IP
   destination address or a destination address on network 0.  A router
   SHOULD NOT forward, except over a loopback interface, any packet that
   has a destination address on network 127.  A router MAY have a switch
   that allows the network manager to disable these checks.  If such a
   switch is provided, it MUST default to performing the checks.

REFERENCE

   A router SHOULD IMPLEMENT the ability to filter traffic based on a
   comparison of the source address of a packet and the forwarding table
   for a logical interface on which the packet was received.  If this
   filtering is enabled, the router MUST silently discard a packet if
   the interface on which the packet was received is not the interface
   on which a packet would be forwarded to reach the address contained
   in the source address.  In simpler terms, if a router wouldn't route
   a packet containing this address through a particular interface, it
   shouldn't believe the address if it appears as a source address in a
   packet read from this interface.

REFERENCE

   If this feature is implemented, it MUST be disabled by default.

REFERENCE

   A value matching any address (e.g., a keyword any, an address with a
   mask of all 0's, or a network prefix whose length is zero) MUST be
   allowed as a source and/or destination address.

REFERENCE

   The router MUST allow packets to be silently discarded (i.e.,
   discarded without an ICMP error message being sent).

REFERENCE

   o MUST silently discard any packets which are received on that
      interface but are not addressed to the router

REFERENCE

   o MUST NOT send packets out that interface, except for datagrams
      originated by the router

REFERENCE

   o MUST NOT announce via any routing protocols the availability of
      paths through the interface

REFERENCE

   When a router ceases forwarding it MUST stop advertising all routes,
   except for third party routes.  It MAY continue to receive and use
   routes from other routers in its routing domains.  If the forwarding
   database is retained, the router MUST NOT cease timing the routes in
   the forwarding database.  If routes that have been received from
   other routers are remembered, the router MUST NOT cease timing the
   routes that it has remembered.  It MUST discard any routes whose
   timers expire while forwarding is disabled, just as it would do if
   forwarding were enabled.

REFERENCE

   If an interface fails or is disabled a router MUST remove and stop
   advertising all routes in its forwarding database that make use of
   that interface.  It MUST disable all static routes that make use of
   that interface.  If other routes to the same destination and TOS are
   learned or remembered by the router, the router MUST choose the best
   alternate, and add it to its forwarding database.  The router SHOULD
   send ICMP destination unreachable or ICMP redirect messages, as
   appropriate, in reply to all packets that it is unable to forward due
   to the interface being unavailable.

REFERENCE

   If an interface that had not been available becomes available, a
   router MUST reenable any static routes that use that interface.  If
   routes that would use that interface are learned by the router, then
   these routes MUST be evaluated along with all the other learned
   routes, and the router MUST make a decision as to which routes should
   be placed in the forwarding database.  The implementor is referred to
   Chapter [7], Application Layer - Routing Protocols for further
   information on how this decision is made.

REFERENCE

5.3.13.1 Unrecognized Options Unrecognized IP options in forwarded
   packets MUST be passed through unchanged.

REFERENCE

   This option is obsolete.  If the Stream Identifier option is present
   in a packet forwarded by the router, the option MUST be ignored and
   passed through unchanged.

REFERENCE

   A router MUST implement support for source route options in forwarded
   packets.  A router MAY implement a configuration option that, when
   enabled, causes all source-routed packets to be discarded.  However,
   such an option MUST NOT be enabled by default.

REFERENCE

   Routers MUST support the Record Route option in forwarded packets.

REFERENCE

   A router MAY provide a configuration option that, if enabled, will
   cause the router to ignore (i.e., pass through unchanged) Record
   Route options in forwarded packets.  If provided, such an option MUST
   default to enabling the record-route.  This option should not affect
   the processing of Record Route options in datagrams received by the
   router itself (in particular, Record Route options in ICMP echo
   requests will still be processed according to Section [4.3.3.6]).

REFERENCE

   Routers MUST support the timestamp option in forwarded packets.  A
   timestamp value MUST follow the rules given [INTRO:2].

REFERENCE

   If the flags field = 3 (timestamp and prespecified address), the
   router MUST add its timestamp if the next prespecified address
   matches any of the router's IP addresses.  It is not necessary that
   the prespecified address be either the address of the interface on
   which the packet arrived or the address of the interface over which
   it will be sent.

REFERENCE

   A router MAY provide a configuration option which, if enabled, will
   cause the router to ignore (i.e., pass through unchanged) Timestamp
   options in forwarded datagrams when the flag word is set to zero
   (timestamps only) or one (timestamp and registering IP address).  If
   provided, such an option MUST default to off (that is, the router
   does not ignore the timestamp).  This option should not affect the
   processing of Timestamp options in datagrams received by the router
   itself (in particular, a router will insert timestamps into Timestamp
   options in datagrams received by the router, and Timestamp options in
   ICMP echo requests will still be processed according to Section
   [4.3.3.6]).

REFERENCE

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

REFERENCE

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

REFERENCE

      Urgent Pointer: RFC 793 Section 3.1:
           A TCP MUST inform the application layer asynchronously
           whenever it receives an Urgent pointer and there was
           previously no pending urgent data, or whenever the Urgent
           pointer advances in the data stream.  There MUST be a way for
           the application to learn how much urgent data remains to be
           read from the connection, or at least to determine whether or
           not more urgent data remains to be read.

REFERENCE

      TCP Connection Failures:
           An application MUST be able to set the value for R2 for a
           particular connection.  For example, an interactive
           application might set R2 to ``infinity,'' giving the user
           control over when to disconnect.

REFERENCE

      TCP Multihoming:
           If an application on a multihomed host does not specify the
           local IP address when actively opening a TCP connection, then
           the TCP MUST ask the IP layer to select a local IP address
           before sending the (first) SYN.  See the function
           GET_SRCADDR() in Section 3.4.

REFERENCE

      IP Options:
           An application MUST be able to specify a source route when it
           actively opens a TCP connection, and this MUST take
           precedence over a source route received in a datagram.

REFERENCE

   o The requirements concerning the Maximum Segment Size Option in
      [INTRO:2] are amended as follows: ICMP Destination Unreachable
      codes 11 and 12 are additional soft error conditions.  Therefore,
      these message MUST NOT cause TCP to abort a connection.

REFERENCE

   Routers MUST NOT by default redistribute routing data they do not
   themselves use, trust or otherwise consider valid.  In rare cases, it
   may be necessary to redistribute suspicious information, but this
   should only happen under direct intercession by some human agency.

REFERENCE

   A router that implements any routing protocol (other than static
   routes) MUST IMPLEMENT OSPF (see Section [7.2.2]).  A router MAY
   implement additional IGPs.

REFERENCE

   Note that to comply with Section [8.3] of this memo, a router that
   implements OSPF MUST implement the OSPF MIB [MGT:14].

REFERENCE

   The area of inter-AS routing is a current topic of research inside
   the Internet Engineering Task Force.  The Exterior Gateway Protocol
   (EGP) described in Section [Appendix F.1] has traditionally been the
   inter-AS protocol of choice, but is now historical.  The Border
   Gateway Protocol (BGP) eliminates many of the restrictions and
   limitations of EGP, and is therefore growing rapidly in popularity.
   A router is not required to implement any inter-AS routing protocol.
   However, if a router does implement EGP it also MUST IMPLEMENT BGP.
   Although it was not designed as an exterior gateway protocol, RIP
   (described in Section [7.2.4]) is sometimes used for inter-AS
   routing.

REFERENCE

   A router that supports a dynamic routing protocol MUST allow static
   routes to be defined with any metric valid for the routing protocol
   used.  The router MUST provide the ability for the user to specify a
   list of static routes that may or may not be propagated through the
   routing protocol.  In addition, a router SHOULD support the following
   additional information if it supports a routing protocol that could
   make use of the information.  They are:

REFERENCE

      A router MUST allow a metric to be assigned to a static route for
      each routing domain that it supports.  Each such metric MUST be
      explicitly assigned to a specific routing domain.  For example:

REFERENCE

   Filtering of routing information allows control of paths used by a
   router to forward packets it receives.  A router should be selective
   in which sources of routing information it listens to and what routes
   it believes.  Therefore, a router MUST provide the ability to
   specify:

REFERENCE

   Some routing protocols do not recognize logical interfaces as a
   source of routing information.  In such cases the router MUST provide
   the ability to specify

REFERENCE

   If a router supports assignment of preferences, the router MUST NOT
   propagate any routes it does not prefer as first party information.
   If the routing protocol being used to propagate the routes does not
   support distinguishing between first and third party information, the
   router MUST NOT propagate any routes it does not prefer.

REFERENCE

   Routing information for routes which the router does not use (router
   S in the above example) MUST NOT be passed to any other router.

REFERENCE

   Routers MUST be able to exchange routing information between separate
   IP interior routing protocols, if independent IP routing processes
   can run in the same router.  Routers MUST provide some mechanism for
   avoiding routing loops when routers are configured for bi-directional
   exchange of routing information between two separate interior routing

REFERENCE

   processes.  Routers MUST provide some priority mechanism for choosing
   routes from independent routing processes.  Routers SHOULD provide
   administrative control of IGP-IGP exchange when used across
   administrative boundaries.

REFERENCE

   Routers MUST be manageable by SNMP [MGT:3].  The SNMP MUST operate
   using UDP/IP as its transport and network protocols.  Others MAY be
   supported (e.g., see [MGT:25, MGT:26, MGT:27, and MGT:28]).  SNMP

REFERENCE

   management operations MUST operate as if the SNMP was implemented on
   the router itself.  Specifically, management operations MUST be
   effected by sending SNMP management requests to any of the IP
   addresses assigned to any of the router's interfaces.  The actual
   management operation may be performed either by the router or by a
   proxy for the router.

REFERENCE

   All SNMP operations (get, get-next, get-response, set, and trap) MUST
   be implemented.

REFERENCE

   Routers MUST provide a mechanism for rate-limiting the generation of
   SNMP trap messages.  Routers MAY provide this mechanism through the
   algorithms for asynchronous alert management described in [MGT:5].

REFERENCE

   A router's community table MUST allow for at least one entry and
   SHOULD allow for at least two entries.

REFERENCE

   Routers MUST allow the user to manually (i.e., without using SNMP)
   examine, add, delete and change entries in the SNMP community table.
   The user MUST be able to set the community name or construct a MIB
   view.  The user MUST be able to configure communities as read-only
   (i.e., they do not allow SETs) or read-write (i.e., they do allow
   SETs).

REFERENCE

   The user MUST be able to define at least one IP address to which
   notifications are sent for each community or MIB view, if traps are
   used.  These addresses SHOULD be definable on a community or MIB view
   basis.  It SHOULD be possible to enable or disable notifications on a
   community or MIB view basis.

REFERENCE

   A router SHOULD provide the ability to specify a list of valid
   network managers for any particular community.  If enabled, a router
   MUST validate the source address of the SNMP datagram against the
   list and MUST discard the datagram if its address does not appear.
   If the datagram is discarded the router MUST take all actions
   appropriate to an SNMP authentication failure.

REFERENCE

   The community table MUST be saved in non-volatile storage.

REFERENCE

   The initial state of the community table SHOULD contain one entry,
   with the community name string public and read-only access.  The
   default state of this entry MUST NOT send traps.  If it is
   implemented, then this entry MUST remain in the community table until
   the administrator changes it or deletes it.

REFERENCE

   o The System, Interface, IP, ICMP, and UDP groups of MIB-II [MGT:2]
      MUST be implemented.

REFERENCE

   o The Interface Extensions MIB [MGT:18] MUST be implemented.

REFERENCE

   o The IP Forwarding Table MIB [MGT:20] MUST be implemented.

REFERENCE

   o If the router implements TCP (e.g., for Telnet) then the TCP group
      of MIB-II [MGT:2] MUST be implemented.

REFERENCE

   o If the router implements EGP then the EGP group of MIB-II [MGT:2]
      MUST be implemented.

REFERENCE

   o If the router supports OSPF then the OSPF MIB [MGT:14] MUST be
      implemented.

REFERENCE

   o If the router supports BGP then the BGP MIB [MGT:15] MUST be
      implemented.

REFERENCE

   o If the router has Ethernet, 802.3, or StarLan interfaces then the
      Ethernet-Like MIB [MGT:6] MUST be implemented.

REFERENCE

   o If the router has 802.4 interfaces then the 802.4 MIB [MGT:7] MUST
      be implemented.

REFERENCE

   o If the router has 802.5 interfaces then the 802.5 MIB [MGT:8] MUST
      be implemented.

REFERENCE

   o If the router has FDDI interfaces that implement ANSI SMT 7.3 then
      the FDDI MIB [MGT:9] MUST be implemented.

REFERENCE

   o If the router has FDDI interfaces that implement ANSI SMT 6.2 then
      the FDDI MIB [MGT:29] MUST be implemented.

REFERENCE

   o If the router has interfaces that use V.24 signalling, such as RS-
      232, V.10, V.11, V.35, V.36, or RS-422/423/449, then the RS-232
      [MGT:10] MIB MUST be implemented.

REFERENCE

   o If the router has T1/DS1 interfaces then the T1/DS1 MIB [MGT:16]
      MUST be implemented.

REFERENCE

   o If the router has T3/DS3 interfaces then the T3/DS3 MIB [MGT:17]
      MUST be implemented.

REFERENCE

   o If the router has SMDS interfaces then the SMDS Interface Protocol
      MIB [MGT:19] MUST be implemented.

REFERENCE

   o If the router supports PPP over any of its interfaces then the PPP
      MIBs [MGT:11], [MGT:12], and [MGT:13] MUST be implemented.

REFERENCE

   o If the router supports RIP Version 2 then the RIP Version 2 MIB
      [MGT:21] MUST be implemented.

REFERENCE

   o If the router supports X.25 over any of its interfaces then the
      X.25 MIBs [MGT:22, MGT:23 and MGT:24] MUST be implemented.

REFERENCE

   The Vendor Specific MIB for the router MUST provide access to all
   statistical, state, configuration, and control information that is
   not available through the Standard and Experimental MIBs that have
   been implemented.  This information MUST be available for both
   monitoring and control operations.

REFERENCE

   The vendor SHOULD make available the specifications for all Vendor
   Specific MIB variables.  These specifications MUST conform to the SMI
   [MGT:1] and the descriptions MUST be in the form specified in
   [MGT:4].

REFERENCE

   For all additional application protocols that a router implements,
   the router MUST be compliant and SHOULD be unconditionally compliant
   with the relevant requirements of [INTRO:3].

REFERENCE

   A router MAY provide BOOTP relay-agent capability.  If it does, it
   MUST conform to the specifications in [APPL:3].

REFERENCE

   Sections [4.2.2.11] and [5.3.7] discussed invalid IP source
   addresses.  According to these rules, a router must not forward any
   received datagram whose IP source address is 0.0.0.0.  However,
   routers that support a BOOTP relay agent MUST accept for local
   delivery to the relay agent BOOTREQUEST messages whose IP source
   address is 0.0.0.0.

REFERENCE

   There exists a minimum set of conditions that must be satisfied
   before a router may forward packets.  A router MUST NOT enable
   forwarding on any physical interface unless either:

REFERENCE

   These parameters MUST be explicitly configured:

REFERENCE

   o A router MUST NOT use factory-configured default values for its IP
      addresses, prefix lengths, or router-id, and

REFERENCE

   o A router MUST NOT assume that an unconfigured interface is an
      unnumbered interface.

REFERENCE

   A router MUST allow its IP addresses and their address masks or
   prefix lengths to be statically configured and saved in non-volatile
   storage.

REFERENCE

   If the dynamic method is provided, the choice of method to be used in
   a particular router MUST be configurable.

REFERENCE

   Routers MUST support Out-Of-Band (OOB) access.  OOB access SHOULD
   provide the same functionality as in-band access.  This access SHOULD
   implement access controls, to prevent unauthorized access.

REFERENCE

   A router MUST include both in-band and out-of-band mechanisms to
   allow the network manager to reload, stop, and restart the router.  A
   router SHOULD also contain a mechanism (such as a watchdog timer)
   which will reboot the router automatically if it hangs due to a
   software or hardware fault.

REFERENCE

   There MUST be mechanisms for detecting and responding to
   misconfigurations.  If a command is executed incorrectly, the router
   SHOULD give an error message.  The router SHOULD NOT accept a poorly
   formed command as if it were correct.

REFERENCE

      (1) A router MUST provide in-band network access, but (except as
           required by Section [8.2]) for security considerations this
           access SHOULD be disabled by default.  Vendors MUST document
           the default state of any in-band access.  This access SHOULD
           implement access controls, to prevent unauthorized access.

REFERENCE

      (2) A router MUST provide the ability to initiate an ICMP echo.
           The following options SHOULD be implemented:

REFERENCE

           Routers MUST provide a method for auditing security related
           failures or violations to include:

REFERENCE

           Routers MUST provide a method of limiting or disabling such
           auditing but auditing SHOULD be on by default.  Possible
           methods for auditing include listing violations to a console
           if present, logging or counting them internally, or logging
           them to a remote security server through the SNMP trap
           mechanism or the Unix logging mechanism as appropriate.  A
           router MUST implement at least one of these reporting
           mechanisms - it MAY implement more than one.

REFERENCE

   A router MUST NOT have undocumented back door access and master
   passwords.  A vendor MUST ensure any such access added for purposes
   of debugging or product development are deleted before the product is
   distributed to its customers.

REFERENCE

   However, in performing this router-like function, the host MUST obey
   all the relevant rules for a router forwarding source-routed
   datagrams [INTRO:2].  This includes the following specific
   provisions:

REFERENCE

   (A) TTL
        The TTL field MUST be decremented and the datagram perhaps
        discarded as specified for a router in [INTRO:2].

REFERENCE

   (B) ICMP Destination Unreachable
        A host MUST be able to generate Destination Unreachable messages
        with the following codes:
        4 (Fragmentation Required but DF Set) when a source-routed
          datagram cannot be fragmented to fit into the target network;
        5 (Source Route Failed) when a source-routed datagram cannot be
          forwarded, e.g., because of a routing problem or because the
          next hop of a strict source route is not on a connected
          network.

REFERENCE

   (D) Record Route Option
        A host that is forwarding a source-routed datagram containing a
        Record Route option MUST update that option, if it has room.

REFERENCE

   (E) Timestamp Option
        A host that is forwarding a source-routed datagram containing a
        Timestamp Option MUST add the current timestamp to that option,
        according to the rules for this option.

REFERENCE

   A host that supports non-local source-routing MUST have a
   configurable switch to disable forwarding, and this switch MUST
   default to disabled.

REFERENCE

   The host MUST satisfy all router requirements for configurable policy
   filters [INTRO:2] restricting non-local forwarding.

REFERENCE

         An implementation of EGP MUST include indirect neighbor
         support.

REFERENCE

         The interval between Hello command retransmissions and the
         interval between Poll retransmissions SHOULD be configurable
         but there MUST be a minimum value defined.

REFERENCE

         The interval at which an implementation will respond to Hello
         commands and Poll commands SHOULD be configurable but there
         MUST be a minimum value defined.

REFERENCE

   An implementation MUST default to not providing the external list of
   routers in other autonomous systems; only the internal list of
   routers together with the nets that are reachable through those
   routers should be included in an Update Response/Indication packet.
   However, an implementation MAY elect to provide a configuration
   option enabling the external list to be provided.  An implementation
   MUST NOT include in the external list routers that were learned
   through the external list provided by a router in another autonomous
   system.  An implementation MUST NOT send a network back to the
   autonomous system from which it is learned, i.e.  it MUST do split-
   horizon on an autonomous system level.

REFERENCE

   If more than 255 internal or 255 external routers need to be
   specified in a Network Reachability update, the networks reachable
   from routers that can not be listed MUST be merged into the list for
   one of the listed routers.  Which of the listed routers is chosen for
   this purpose SHOULD be user configurable, but SHOULD default to the
   source address of the EGP update being generated.

REFERENCE

   If a network is shared with the peer, an implementation MUST send an
   unsolicited update upon entry to the Up state if the source network
   is the shared network.

REFERENCE

   An EGP implementation MUST include support for the abort timer (as
   documented in section 4.1.4 of RFC 904).  An implementation SHOULD
   use the abort timer in the Idle state to automatically issue a Start
   event to restart the protocol machine.  Recommended values are P4 for
   a critical error (Administratively prohibited, Protocol Violation and
   Parameter Problem) and P5 for all others.  The abort timer SHOULD NOT
   be started when a Stop event was manually initiated (such as through
   a network management protocol).

REFERENCE

   When the EGP state machine is in the Idle state, it MUST reply to
   Cease commands with a Cease-ack response.

REFERENCE

   An EGP implementation MUST include support for both active and
   passive polling modes.

REFERENCE

   As noted the Hello and Poll Intervals should only be present in
   Request and Confirm messages.  Therefore the length of an EGP
   Neighbor Acquisition Message is 14 bytes for a Request or Confirm
   message and 10 bytes for a Refuse, Cease or Cease-ack message.
   Implementations MUST NOT send 14 bytes for Refuse, Cease or Cease-ack
   messages but MUST allow for implementations that send 14 bytes for
   these messages.

REFERENCE

   Response or indication packets received with a sequence number not
   equal to S MUST be discarded.  The send sequence number S MUST be
   incremented just before the time a Poll command is sent and at no
   other times.

REFERENCE

        An implementation of RIP MUST provide a means for timing out
        routes.  Since messages are occasionally lost, implementations
        MUST NOT invalidate a route based on a single missed update.

REFERENCE

        Implementations MUST by default wait six times the update
        interval before invalidating a route.  A router MAY have
        configuration options to alter this value.

REFERENCE

   An implementation of RIP MUST implement split horizon, a scheme used
   for avoiding problems caused by including routes in updates sent to
   the router from which they were learned.

REFERENCE

      Triggered updates (also called flash updates) are a mechanism for
      immediately notifying a router's neighbors when the router adds or
      deletes routes or changes their metrics.  A router MUST send a
      triggered update when routes are deleted or their metrics are
      increased.  A router MAY send a triggered update when routes are
      added or their metrics decreased.

REFERENCE

      Since triggered updates can cause excessive routing overhead,
      implementations MUST use the following mechanism to limit the
      frequency of triggered updates:

REFERENCE

      Triggered updates SHOULD include all routes that have changed
      since the most recent regular (non-triggered) update.  Triggered
      updates MUST NOT include routes that have not changed since the
      most recent regular update.

REFERENCE

   Note that to comply with Section [6.1] of this memo, a router SHOULD
   use UDP checksums in RIP packets that it originates, MUST discard RIP
   packets received with invalid UDP checksums, but MUST NOT discard
   received RIP packets simply because they do not contain UDP
   checksums.

REFERENCE

   A RIP implementation SHOULD support host routes.  If it does not, it
   MUST (as described on page 27 of [ROUTE:3]) ignore host routes in
   received updates.  A router MAY log ignored hosts routes.

REFERENCE

   The special address 0.0.0.0 is used to describe a default route.  A
   default route is used as the route of last resort (i.e., when a route
   to the specific net does not exist in the routing table).  The router
   MUST be able to create a RIP entry for the address 0.0.0.0.

REFERENCE

   When processing an update, the following validity checks MUST be
   performed:

REFERENCE

   o The response MUST be from UDP port 520.

REFERENCE

   o The source address MUST be on a directly connected subnet (or on a
      directly connected, non-subnetted network) to be considered valid.

REFERENCE

   o The source address MUST NOT be one of the router's addresses.

REFERENCE

   An implementation MUST NOT replace an existing route if the metric
   received is equal to the existing metric except in accordance with
   the following heuristic.

REFERENCE

   An implementation MAY choose to implement the following heuristic to
   deal with the above situation.  Normally, it is useless to change the
   route to a network from one router to another if both are advertised
   at the same metric.  However, the route being advertised by one of
   the routers may be in the process of timing out.  Instead of waiting
   for the route to timeout, the new route can be used after a specified
   amount of time has elapsed.  If this heuristic is implemented, it
   MUST wait at least halfway to the expiration point before the new
   route is installed.

Network Working Group F. Baker, Editor
Request for Comments: 1812 Cisco Systems
Obsoletes: 1716, 1009 June 1995
Category: Standards Track

Requirements for IP Version 4 Routers

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

PREFACE

This document is an updated version of RFC 1716, the historical
Router Requirements document. That RFC preserved the significant
work that went into the working group, but failed to adequately
describe current technology for the IESG to consider it a current
standard.

The current editor had been asked to bring the document up to date,
so that it is useful as a procurement specification and a guide to
implementors. In this, he stands squarely on the shoulders of those
who have gone before him, and depends largely on expert contributors
for text. Any credit is theirs; the errors are his.

The content and form of this document are due, in large part, to the
working group's chair, and document's original editor and author:
Philip Almquist. It is also largely due to the efforts of its
previous editor, Frank Kastenholz. Without their efforts, this
document would not exist.

Table of Contents

Baker Standards Track PAGE 1

RFC 1812 Requirements for IP Version 4 Routers June 1995

Baker Standards Track PAGE 2