5.3 SPECIFIC ISSUES

5.3.1 Time to Live (TTL)

   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.

   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.

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

   DISCUSSION
      The IP TTL is used, somewhat schizophrenically, as both a hop
      count limit and a time limit.  Its hop count function is critical
      to ensuring that routing problems can't melt down the network by
      causing packets to loop infinitely in the network.  The time limit
      function is used by transport protocols such as TCP to ensure
      reliable data transfer.  Many current implementations treat TTL as
      a pure hop count, and in parts of the Internet community there is
      a strong sentiment that the time limit function should instead be
      performed by the transport protocols that need it.

      In this specification, we have reluctantly decided to follow the
      strong belief among the router vendors that the time limit
      function should be optional.  They argued that implementation of
      the time limit function is difficult enough that it is currently
      not generally done.  They further pointed to the lack of
      documented cases where this shortcut has caused TCP to corrupt
      data (of course, we would expect the problems created to be rare
      and difficult to reproduce, so the lack of documented cases
      provides little reassurance that there haven't been a number of
      undocumented cases).

      IP multicast notions such as the expanding ring search may not
      work as expected unless the TTL is treated as a pure hop count.
      The same thing is somewhat true of traceroute.

      ICMP Time Exceeded messages are required because the traceroute
      diagnostic tool depends on them.

      Thus, the tradeoff is between severely crippling, if not
      eliminating, two very useful tools and avoiding a very rare and
      transient data transport problem that may not occur at all.  We
      have chosen to preserve the tools.

5.3.2 Type of Service (TOS)

      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].  The Precedence field
      will be discussed in Section [5.3.3].  A more extensive discussion
      of the TOS field and its use can be found in [ROUTE:11].

      A router SHOULD consider the TOS field in a packet's IP header
      when deciding how to forward it.  The remainder of this section
      describes the rules that apply to routers that conform to this
      requirement.

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

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

      (1) The router locates in its routing table all available routes
           to the destination (see Section [5.2.4]).

      (2) If there are none, the router drops the packet because the
           destination is unreachable.  See section [5.2.4].

      (3) If one or more of those routes have a TOS that exactly matches
           the TOS specified in the packet, the router chooses the route
           with the best metric.

      (4) Otherwise, the router repeats the above step, except looking
           at routes whose TOS is zero.

      (5) If no route was chosen above, the router drops the packet
           because the destination is unreachable.  The router returns
           an ICMP Destination Unreachable error specifying the
           appropriate code: either Network Unreachable with Type of
           Service (code 11) or Host Unreachable with Type of Service
           (code 12).

   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.

      Various people have proposed that TOS should affect other aspects
      of the forwarding function.  For example:

      (1) A router could place packets that have the Low Delay bit set
           ahead of other packets in its output queues.

      (2) a router is forced to discard packets, it could try to avoid
           discarding those which have the High Reliability bit set.

      These ideas have been explored in more detail in [INTERNET:17] but
      we don't yet have enough experience with such schemes to make
      requirements in this area.

5.3.3 IP Precedence

      This section specifies requirements and guidelines for appropriate
      processing of the IP Precedence field in routers.  Precedence is a
      scheme for allocating resources in the network based on the
      relative importance of different traffic flows.  The IP
      specification defines specific values to be used in this field for
      various types of traffic.

      The basic mechanisms for precedence processing in a router are
      preferential resource allocation, including both precedence-
      ordered queue service and precedence-based congestion control, and
      selection of Link Layer priority features.  The router also
      selects the IP precedence for routing, management and control
      traffic it originates.  For a more extensive discussion of IP
      Precedence and its implementation see [FORWARD:6].

      Precedence-ordered queue service, as discussed in this section,
      includes but is not limited to the queue for the forwarding
      process and queues for outgoing links.  It is intended that a

      router supporting precedence should also use the precedence
      indication at whatever points in its processing are concerned with
      allocation of finite resources, such as packet buffers or Link
      Layer connections.  The set of such points is implementation-
      dependent.

   DISCUSSION
      Although the Precedence field was originally provided for use in
      DOD systems where large traffic surges or major damage to the
      network are viewed as inherent threats, it has useful applications
      for many non-military IP networks.  Although the traffic handling
      capacity of networks has grown greatly in recent years, the
      traffic generating ability of the users has also grown, and
      network overload conditions still occur at times.  Since IP-based
      routing and management protocols have become more critical to the
      successful operation of the Internet, overloads present two
      additional risks to the network:

      (1) High delays may result in routing protocol packets being lost.
           This may cause the routing protocol to falsely deduce a
           topology change and propagate this false information to other
           routers.  Not only can this cause routes to oscillate, but an
           extra processing burden may be placed on other routers.

      (2) High delays may interfere with the use of network management
           tools to analyze and perhaps correct or relieve the problem
           in the network that caused the overload condition to occur.

      Implementation and appropriate use of the Precedence mechanism
      alleviates both of these problems.

5.3.3.1 Precedence-Ordered Queue Service

   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.

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

   As detailed in Section [5.3.6], routers that implement precedence-
   ordered queue service discard low precedence packets before
   discarding high precedence packets for congestion control purposes.

   Preemption (interruption of processing or transmission of a packet)
   is not envisioned as a function of the Internet Layer.  Some
   protocols at other layers may provide preemption features.

5.3.3.2 Lower Layer Precedence Mappings

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

   A router that implements Lower Layer Precedence Mapping:

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

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

   o SHOULD be able to configure specific nonstandard mappings of IP
      precedence values to Link Layer priority values for each
      interface.

   DISCUSSION
      Some research questions the workability of the priority features
      of some Link Layer protocols, and some networks may have faulty
      implementations of the link layer priority mechanism.  It seems
      prudent to provide an escape mechanism in case such problems show
      up in a network.

      On the other hand, there are proposals to use novel queuing
      strategies to implement special services such as multimedia
      bandwidth reservation or low-delay service.  Special services and
      queuing strategies to support them are current research subjects
      and are in the process of standardization.

      Implementors may wish to consider that correct link layer mapping
      of IP precedence is required by DOD policy for TCP/IP systems used
      on DOD networks.  Since these requirements are intended to
      encourage (but not force) the use of precedence features in the
      hope of providing better Internet service to all users, routers
      supporting precedence-ordered queue service should default to
      maintaining strict precedence ordering regardless of the type of
      service requested.

5.3.3.3 Precedence Handling For All Routers

   A router (whether or not it employs precedence-ordered queue
   service):

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

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

   DISCUSSION
      Precedence filtering should be applicable to specific
      source/destination IP Address pairs, specific protocols, specific
      ports, and so on.

   An ICMP Destination Unreachable message with code 14 SHOULD be sent
   when a packet is dropped by the validation filter, unless this has
   been suppressed by configuration choice.

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

        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.

   DISCUSSION
      Unrestricted precedence cutoff could result in an unintentional
      cutoff of routing and control traffic.  In the general case, host
      traffic should be restricted to a value of 5 (CRITIC/ECP) or
      below; this is not a requirement and may not be correct in certain
      systems.

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

   (5) SHOULD be able to configure distinct precedence values to be used
        for each routing or management protocol supported (except for
        those protocols, such as OSPF, which specify which precedence
        value must be used).

   (6) MAY be able to configure routing or management traffic precedence
        values independently for each peer address.

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

   DISCUSSION
      The precedence cutoff mechanism described in (3) is somewhat
      controversial.  Depending on the topological location of the area
      affected by the cutoff, transit traffic may be directed by routing
      protocols into the area of the cutoff, where it will be dropped.
      This is only a problem if another path that is unaffected by the
      cutoff exists between the communicating points.  Proposed ways of
      avoiding this problem include providing some minimum bandwidth to
      all precedence levels even under overload conditions, or
      propagating cutoff information in routing protocols.  In the
      absence of a widely accepted (and implemented) solution to this
      problem, great caution is recommended in activating cutoff
      mechanisms in transit networks.

      A transport layer relay could legitimately provide the function
      prohibited by (4) above.  Changing precedence levels may cause
      subtle interactions with TCP and perhaps other protocols; a
      correct design is a non-trivial task.

      The intent of (5) and (6) (and the discussion of IP Precedence in
      ICMP messages in Section [4.3.2]) is that the IP precedence bits
      should be appropriately set, whether or not this router acts upon
      those bits in any other way.  We expect that in the future
      specifications for routing protocols and network management
      protocols will specify how the IP Precedence should be set for
      messages sent by those protocols.

      The appropriate response for (7) depends on the link layer
      protocol in use.  Typically, the router should stop trying to send
      offensive traffic to that destination for some period of time, and

      should return an ICMP Destination Unreachable message with code 15
      (service not available for precedence requested) to the traffic
      source.  It also should not try to reestablish a preempted Link
      Layer connection for some time.

5.3.4 Forwarding of Link Layer Broadcasts

   The encapsulation of IP packets in most Link Layer protocols (except
   PPP) allows a receiver to distinguish broadcasts and multicasts from
   unicasts simply by examining the Link Layer protocol headers (most
   commonly, the Link Layer destination address).  The rules in this
   section that refer to Link Layer broadcasts apply only to Link Layer
   protocols that allow broadcasts to be distinguished; likewise, the
   rules that refer to Link Layer multicasts apply only to Link Layer
   protocols that allow multicasts to be distinguished.

   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.

   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.

   A router SHOULD silently discard a packet that is received via a Link
   Layer broadcast but does not specify an IP multicast or IP broadcast
   destination address.

   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.

5.3.5 Forwarding of Internet Layer Broadcasts

   There are two major types of IP broadcast addresses; limited
   broadcast and directed broadcast.  In addition, there are three
   subtypes of directed broadcast: a broadcast directed to a specified
   network prefix, a broadcast directed to a specified subnetwork, and a
   broadcast directed to all subnets of a specified network.
   Classification by a router of a broadcast into one of these
   categories depends on the broadcast address and on the router's
   understanding (if any) of the subnet structure of the destination
   network.  The same broadcast will be classified differently by
   different routers.

   A limited IP broadcast address is defined to be all-ones: { -1, -1 }
   or 255.255.255.255.

   A network-prefix-directed broadcast is composed of the network prefix
   of the IP address with a local part of all-ones or { <Network-
   prefix>, -1 }.  For example, a Class A net broadcast address is
   net.255.255.255, a Class B net broadcast address is net.net.255.255
   and a Class C net broadcast address is net.net.net.255 where net is a
   byte of the network address.

   The all-subnets-directed-broadcast is not well defined in a CIDR
   environment, and was deprecated in version 1 of this memo.

   As was described in Section [4.2.3.1], a router may encounter certain
   non-standard IP broadcast addresses:

   o 0.0.0.0 is an obsolete form of the limited broadcast address

   o { <Network-prefix>, 0 } is an obsolete form of a network-prefix-
      directed broadcast address.

   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.

5.3.5.1 Limited Broadcasts

   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.

   DISCUSSION
      Some routers contain UDP servers which function by resending the
      requests (as unicasts or directed broadcasts) to other servers.
      This requirement should not be interpreted as prohibiting such
      servers.  Note, however, that such servers can easily cause packet
      looping if misconfigured.  Thus, providers of such servers would
      probably be well advised to document their setup carefully and to
      consider carefully the TTL on packets that are sent.

5.3.5.2 Directed Broadcasts

   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

   be sent.

   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.

   DISCUSSION
      There has been some debate about forwarding or not forwarding
      directed broadcasts.  In this memo we have made the forwarding
      decision depend on the router's knowledge of the destination
      network prefix.  Routers cannot determine that a message is
      unicast or directed broadcast apart from this knowledge.  The
      decision to forward or not forward the message is by definition
      only possible in the last hop router.

5.3.5.3 All-subnets-directed Broadcasts

   The first version of this memo described an algorithm for
   distributing a directed broadcast to all the subnets of a classical
   network number.  This algorithm was stated to be "broken," and
   certain failure cases were specified.

   In a CIDR routing domain, wherein classical IP network numbers are
   meaningless, the concept of an all-subnets-directed-broadcast is also
   meaningless.  To the knowledge of the working group, the facility was
   never implemented or deployed, and is now relegated to the dustbin of
   history.

5.3.5.4  Subnet-directed Broadcasts

   The first version of this memo spelled out procedures for dealing
   with subnet-directed-broadcasts.  In a CIDR routing domain, these are
   indistinguishable from net-drected-broadcasts.  The two are therefore
   treated together in section [5.3.5.2 Directed Broadcasts], and should
   be viewed as network-prefix directed broadcasts.

5.3.6 Congestion Control

   Congestion in a network is loosely defined as a condition where
   demand for resources (usually bandwidth or CPU time) exceeds
   capacity.  Congestion avoidance tries to prevent demand from
   exceeding capacity, while congestion recovery tries to restore an
   operative state.  It is possible for a router to contribute to both
   of these mechanisms.  A great deal of effort has been spent studying
   the problem.  The reader is encouraged to read [FORWARD:2] for a
   survey of the work.  Important papers on the subject include

   [FORWARD:3], [FORWARD:4], [FORWARD:5], [FORWARD:10], [FORWARD:11],
   [FORWARD:12], [FORWARD:13], [FORWARD:14], and [INTERNET:10], among
   others.

   The amount of storage that router should have available to handle
   peak instantaneous demand when hosts use reasonable congestion
   policies, such as described in [FORWARD:5], is a function of the
   product of the bandwidth of the link times the path delay of the
   flows using the link, and therefore storage should increase as this
   Bandwidth*Delay product increases.  The exact function relating
   storage capacity to probability of discard is not known.

   When a router receives a packet beyond its storage capacity it must
   (by definition, not by decree) discard it or some other packet or
   packets.  Which packet to discard is the subject of much study but,
   unfortunately, little agreement so far.  The best wisdom to date
   suggests discarding a packet from the data stream most heavily using
   the link.  However, a number of additional factors may be relevant,
   including the precedence of the traffic, active bandwidth
   reservation, and the complexity associated with selecting that
   packet.

   A router MAY discard the packet it has just received; this is the
   simplest but not the best policy.  Ideally, the router should select
   a packet from one of the sessions most heavily abusing the link,
   given that the applicable Quality of Service policy permits this.  A
   recommended policy in datagram environments using FIFO queues is to
   discard a packet randomly selected from the queue (see [FORWARD:5]).
   An equivalent algorithm in routers using fair queues is to discard
   from the longest queue or that using the greatest virtual time (see
   [FORWARD:13]).  A router MAY use these algorithms to determine which
   packet to discard.

   If a router implements a discard policy (such as Random Drop) under
   which it chooses a packet to discard from a pool of eligible packets:

   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.

   o A router MAY protect packets whose IP headers request the maximize
      reliability TOS, except where doing so would be in violation of
      the previous rule.

   o A router MAY protect fragmented IP packets, on the theory that
      dropping a fragment of a datagram may increase congestion by
      causing all fragments of the datagram to be retransmitted by the

      source.

   o To help prevent routing perturbations or disruption of management
      functions, the router MAY protect packets used for routing
      control, link control, or network management from being discarded.
      Dedicated routers (i.e., routers that are not also general purpose
      hosts, terminal servers, etc.) can achieve an approximation of
      this rule by protecting packets whose source or destination is the
      router itself.

   Advanced methods of congestion control include a notion of fairness,
   so that the 'user' that is penalized by losing a packet is the one
   that contributed the most to the congestion.  No matter what
   mechanism is implemented to deal with bandwidth congestion control,
   it is important that the CPU effort expended be sufficiently small
   that the router is not driven into CPU congestion also.

   As described in Section [4.3.3.3], this document recommends that a
   router SHOULD NOT send a Source Quench to the sender of the packet
   that it is discarding.  ICMP Source Quench is a very weak mechanism,
   so it is not necessary for a router to send it, and host software
   should not use it exclusively as an indicator of congestion.

5.3.7 Martian Address Filtering

   An IP source address is invalid if it is a special IP address, as
   defined in 4.2.2.11 or 5.3.7, or is not a unicast address.

   An IP destination address is invalid if it is among those defined as
   illegal destinations in 4.2.3.1, or is a Class E address (except
   255.255.255.255).

   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.

   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.

   If a router discards a packet because of these rules, it SHOULD log
   at least the IP source address, the IP destination address, and, if

   the problem was with the source address, the physical interface on
   which the packet was received and the Link Layer address of the host
   or router from which the packet was received.

5.3.8 Source Address Validation

   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.

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

   DISCUSSION
      This feature can provide useful security improvements in some
      situations, but can erroneously discard valid packets in
      situations where paths are asymmetric.

5.3.9 Packet Filtering and Access Lists

   As a means of providing security and/or limiting traffic through
   portions of a network a router SHOULD provide the ability to
   selectively forward (or filter) packets.  If this capability is
   provided, filtering of packets SHOULD be configurable either to
   forward all packets or to selectively forward them based upon the
   source and destination prefixes, and MAY filter on other message
   attributes.  Each source and destination address SHOULD allow
   specification of an arbitrary prefix length.

   DISCUSSION
      This feature can provide a measure of privacy, where systems
      outside a boundary are not permitted to exchange certain protocols
      with systems inside the boundary, or are limited as to which
      systems they may communicate with.  It can also help prevent
      certain classes of security breach, wherein a system outside a
      boundary masquerades as a system inside the boundary and mimics a
      session with it.

   If supported, a router SHOULD be configurable to allow one of an

   o Include list - specification of a list of message definitions to be
      forwarded, or an

   o Exclude list - specification of a list of message definitions NOT
      to be forwarded.

   A "message definition", in this context, specifies the source and
   destination network prefix, and may include other identifying
   information such as IP Protocol Type or TCP port number.

   A router MAY provide a configuration switch that allows a choice
   between specifying an include or an exclude list, or other equivalent
   controls.

   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.

   In addition to address pairs, the router MAY allow any combination of
   transport and/or application protocol and source and destination
   ports to be specified.

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

   The router SHOULD allow an appropriate ICMP unreachable message to be
   sent when a packet is discarded.  The ICMP message SHOULD specify
   Communication Administratively Prohibited (code 13) as the reason for
   the destination being unreachable.

   The router SHOULD allow the sending of ICMP destination unreachable
   messages (code 13) to be configured for each combination of address
   pairs, protocol types, and ports it allows to be specified.

   The router SHOULD count and SHOULD allow selective logging of packets
   not forwarded.

5.3.10 Multicast Routing

   An IP router SHOULD support forwarding of IP multicast packets, based
   either on static multicast routes or on routes dynamically determined
   by a multicast routing protocol (e.g., DVMRP [ROUTE:9]).  A router
   that forwards IP multicast packets is called a multicast router.

5.3.11 Controls on Forwarding

   For each physical interface, a router SHOULD have a configuration
   option that specifies whether forwarding is enabled on that
   interface.  When forwarding on an interface is disabled, the router:

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

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

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

   DISCUSSION
      This feature allows the network manager to essentially turn off an
      interface but leaves it accessible for network management.

      Ideally, this control would apply to logical rather than physical
      interfaces.  It cannot, because there is no known way for a router
      to determine which logical interface a packet arrived absent a
      one-to-one correspondence between logical and physical interfaces.

5.3.12 State Changes

   During router operation, interfaces may fail or be manually disabled,
   or may become available for use by the router.  Similarly, forwarding
   may be disabled for a particular interface or for the entire router
   or may be (re)enabled.  While such transitions are (usually)
   uncommon, it is important that routers handle them correctly.

5.3.12.1 When a Router Ceases Forwarding

   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.

   DISCUSSION
      When a router ceases forwarding, it essentially ceases being a
      router.  It is still a host, and must follow all of the
      requirements of Host Requirements [INTRO:2].  The router may still
      be a passive member of one or more routing domains, however.  As
      such, it is allowed to maintain its forwarding database by
      listening to other routers in its routing domain.  It may not,
      however, advertise any of the routes in its forwarding database,
      since it itself is doing no forwarding.  The only exception to
      this rule is when the router is advertising a route that uses only

      some other router, but which this router has been asked to
      advertise.

   A router MAY send ICMP destination unreachable (host unreachable)
   messages to the senders of packets that it is unable to forward.  It
   SHOULD NOT send ICMP redirect messages.

   DISCUSSION
      Note that sending an ICMP destination unreachable (host
      unreachable) is a router action.  This message should not be sent
      by hosts.  This exception to the rules for hosts is allowed so
      that packets may be rerouted in the shortest possible time, and so
      that black holes are avoided.

5.3.12.2 When a Router Starts Forwarding

   When a router begins forwarding, it SHOULD expedite the sending of
   new routing information to all routers with which it normally
   exchanges routing information.

5.3.12.3 When an Interface Fails or is Disabled

   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.

5.3.12.4 When an Interface is Enabled

   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.

   A router SHOULD expedite the sending of new routing information to
   all routers with which it normally exchanges routing information.

5.3.13 IP Options

   Several options, such as Record Route and Timestamp, contain slots
   into which a router inserts its address when forwarding the packet.
   However, each such option has a finite number of slots, and therefore
   a router may find that there is not free slot into which it can
   insert its address.  No requirement listed below should be construed
   as requiring a router to insert its address into an option that has
   no remaining slot to insert it into.  Section [5.2.5] discusses how a
   router must choose which of its addresses to insert into an option.

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

5.3.13.2 Security Option

   Some environments require the Security option in every packet; such a
   requirement is outside the scope of this document and the IP standard
   specification.  Note, however, that the security options described in
   [INTERNET:1] and [INTERNET:16] are obsolete.  Routers SHOULD
   IMPLEMENT the revised security option described in [INTERNET:5].

   DISCUSSION
      Routers intended for use in networks with multiple security levels
      should support packet filtering based on IPSO (RFC-1108) labels.
      To implement this support, the router would need to permit the
      router administrator to configure both a lower sensitivity limit
      (e.g. Unclassified) and an upper sensitivity limit (e.g. Secret)
      on each interface.  It is commonly but not always the case that
      the two limits are the same (e.g. a single-level interface).
      Packets caught by an IPSO filter as being out of range should be
      silently dropped and a counter should note the number of packets
      dropped because of out of range IPSO labels.

5.3.13.3 Stream Identifier Option

   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.

5.3.13.4 Source Route Options

   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.

   DISCUSSION
      The ability to source route datagrams through the Internet is
      important to various network diagnostic tools.  However, source
      routing may be used to bypass administrative and security controls
      within a network.  Specifically, those cases where manipulation of
      routing tables is used to provide administrative separation in
      lieu of other methods such as packet filtering may be vulnerable
      through source routed packets.

   EDITORS+COMMENTS
      Packet filtering can be defeated by source routing as well, if it
      is applied in any router except one on the final leg of the source
      routed path.  Neither route nor packet filters constitute a
      complete solution for security.

5.3.13.5 Record Route Option

   Routers MUST support the Record Route option in forwarded packets.

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

   DISCUSSION
      There are some people who believe that Record Route is a security
      problem because it discloses information about the topology of the
      network.  Thus, this document allows it to be disabled.

5.3.13.6 Timestamp Option

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

   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.

   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 network layer for transmission.

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

   DISCUSSION
      Like the Record Route option, the Timestamp option can reveal
      information about a network's topology.  Some people consider this
      to be a security concern.

6. TRANSPORT LAYER

   A router is not required to implement any Transport Layer protocols
   except those required to support Application Layer protocols
   supported by the router.  In practice, this means that most routers
   implement both the Transmission Control Protocol (TCP) and the User
   Datagram Protocol (UDP).

6.1 USER DATAGRAM PROTOCOL - UDP

   The User Datagram Protocol (UDP) is specified in [TRANS:1].

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

   o This specification does not specify the interfaces between the
      various protocol layers.  Thus, a router's interfaces need not
      comply with [INTRO:2], except where compliance is required for
      proper functioning of Application Layer protocols supported by the
      router.

   o Contrary to [INTRO:2], an application SHOULD NOT disable generation
      of UDP checksums.

   DISCUSSION
      Although a particular application protocol may require that UDP
      datagrams it receives must contain a UDP checksum, there is no
      general requirement that received UDP datagrams contain UDP
      checksums.  Of course, if a UDP checksum is present in a received
      datagram, the checksum must be verified and the datagram discarded
      if the checksum is incorrect.

6.2 TRANSMISSION CONTROL PROTOCOL - TCP

   The Transmission Control Protocol (TCP) is specified in [TRANS:2].

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

   o This specification does not specify the interfaces between the
      various protocol layers.  Thus, a router need not comply with the
      following requirements of [INTRO:2] (except of course where
      compliance is required for proper functioning of Application Layer
      protocols supported by the router):

      Use of Push: RFC-793 Section 2.8:
           Passing a received PSH flag to the application layer is now
           OPTIONAL.

      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.

      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.

      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.

      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.

   o For similar reasons, a router need not comply with any of the
      requirements of [INTRO:2].

   o The requirements concerning the Maximum Segment Size Option in
      [INTRO:2] are amended as follows: a router that implements the
      host portion of MTU discovery (discussed in Section [4.2.3.3] of
      this memo) uses 536 as the default value of SendMSS only if the
      path MTU is unknown; if the path MTU is known, the default value
      for SendMSS is the path MTU - 40.

   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.

   DISCUSSION
      It should particularly be noted that a TCP implementation in a
      router must conform to the following requirements of [INTRO:2]:

      o Providing a configurable TTL.  [Time to Live: RFC-793 Section
         3.9]

      o Providing an interface to configure keep-alive behavior, if
         keep-alives are used at all.  [TCP Keep-Alives]

      o Providing an error reporting mechanism, and the ability to
         manage it.  [Asynchronous Reports]

      o Specifying type of service.  [Type-of-Service]

      The general paradigm applied is that if a particular interface is
      visible outside the router, then all requirements for the
      interface must be followed.  For example, if a router provides a
      telnet function, then it will be generating traffic, likely to be
      routed in the external networks.  Therefore, it must be able to
      set the type of service correctly or else the telnet traffic may
      not get through.

7. APPLICATION LAYER - ROUTING PROTOCOLS

7.1 INTRODUCTION

   For technical, managerial, and sometimes political reasons, the
   Internet routing system consists of two components - interior routing
   and exterior routing.  The concept of an Autonomous System (AS), as
   define in Section 2.2.4 of this document, plays a key role in
   separating interior from an exterior routing, as this concept allows
   to deliniate the set of routers where a change from interior to
   exterior routing occurs.  An IP datagram may have to traverse the
   routers of two or more Autonomous Systems to reach its destination,
   and the Autonomous Systems must provide each other with topology
   information to allow such forwarding.  Interior gateway protocols
   (IGPs) are used to distribute routing information within an AS (i.e.,
   intra-AS routing).  Exterior gateway protocols are used to exchange
   routing information among ASs (i.e., inter-AS routing).

7.1.1 Routing Security Considerations

   Routing is one of the few places where the Robustness Principle (be
   liberal in what you accept) does not apply.  Routers should be
   relatively suspicious in accepting routing data from other routing
   systems.

   A router SHOULD provide the ability to rank routing information
   sources from most trustworthy to least trustworthy and to accept
   routing information about any particular destination from the most
   trustworthy sources first.  This was implicit in the original
   core/stub autonomous system routing model using EGP and various
   interior routing protocols.  It is even more important with the
   demise of a central, trusted core.

   A router SHOULD provide a mechanism to filter out obviously invalid
   routes (such as those for net 127).

   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.

   Routers must be at least a little paranoid about accepting routing
   data from anyone, and must be especially careful when they distribute
   routing information provided to them by another party.  See below for
   specific guidelines.

7.1.2 Precedence

   Except where the specification for a particular routing protocol
   specifies otherwise, a router SHOULD set the IP Precedence value for
   IP datagrams carrying routing traffic it originates to 6
   (INTERNETWORK CONTROL).

   DISCUSSION
      Routing traffic with VERY FEW exceptions should be the highest
      precedence traffic on any network.  If a system's routing traffic
      can't get through, chances are nothing else will.

7.1.3 Message Validation

   Peer-to-peer authentication involves several tests.  The application
   of message passwords and explicit acceptable neighbor lists has in
   the past improved the robustness of the route database.  Routers
   SHOULD IMPLEMENT management controls that enable explicit listing of
   valid routing neighbors.  Routers SHOULD IMPLEMENT peer-to-peer
   authentication for those routing protocols that support them.

   Routers SHOULD validate routing neighbors based on their source
   address and the interface a message is received on; neighbors in a
   directly attached subnet SHOULD be restricted to communicate with the
   router via the interface that subnet is posited on or via unnumbered
   interfaces.  Messages received on other interfaces SHOULD be silently
   discarded.

   DISCUSSION
      Security breaches and numerous routing problems are avoided by
      this basic testing.

7.2 INTERIOR GATEWAY PROTOCOLS

7.2.1 INTRODUCTION

   An Interior Gateway Protocol (IGP) is used to distribute routing
   information between the various routers in a particular AS.
   Independent of the algorithm used to implement a particular IGP, it
   should perform the following functions:

   (1) Respond quickly to changes in the internal topology of an AS

   (2) Provide a mechanism such that circuit flapping does not cause
        continuous routing updates

   (3) Provide quick convergence to loop-free routing

   (4) Utilize minimal bandwidth

   (5) Provide equal cost routes to enable load-splitting

   (6) Provide a means for authentication of routing updates

   Current IGPs used in the internet today are characterized as either
   being based on a distance-vector or a link-state algorithm.

   Several IGPs are detailed in this section, including those most
   commonly used and some recently developed protocols that may be
   widely used in the future.  Numerous other protocols intended for use
   in intra-AS routing exist in the Internet community.

   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.

7.2.2 OPEN SHORTEST PATH FIRST - OSPF

   Shortest Path First (SPF) based routing protocols are a class of
   link-state algorithms that are based on the shortest-path algorithm
   of Dijkstra.  Although SPF based algorithms have been around since
   the inception of the ARPANET, it is only recently that they have
   achieved popularity both inside both the IP and the OSI communities.
   In an SPF based system, each router obtains the entire topology
   database through a process known as flooding.  Flooding insures a
   reliable transfer of the information.  Each router then runs the SPF
   algorithm on its database to build the IP routing table.  The OSPF
   routing protocol is an implementation of an SPF algorithm.  The
   current version, OSPF version 2, is specified in [ROUTE:1].  Note
   that RFC-1131, which describes OSPF version 1, is obsolete.

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

7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS

   The American National Standards Institute (ANSI) X3S3.3 committee has
   defined an intra-domain routing protocol.  This protocol is titled
   Intermediate System to Intermediate System Routeing Exchange
   Protocol.

   Its application to an IP network has been defined in [ROUTE:2], and
   is referred to as Dual IS-IS (or sometimes as Integrated IS-IS).
   IS-IS is based on a link-state (SPF) routing algorithm and shares all
   the advantages for this class of protocols.