7.3  EXTERIOR GATEWAY PROTOCOLS

7.3.1  INTRODUCTION

   Exterior Gateway Protocols are utilized for inter-Autonomous System
   routing to exchange reachability information for a set of networks
   internal to a particular autonomous system to a neighboring
   autonomous system.

   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.

7.3.2 BORDER GATEWAY PROTOCOL - BGP

7.3.2.1 Introduction

   The Border Gateway Protocol (BGP-4) is an inter-AS routing protocol
   that exchanges network reachability information with other BGP
   speakers.  The information for a network includes the complete list
   of ASs that traffic must transit to reach that network.  This
   information can then be used to insure loop-free paths.  This
   information is sufficient to construct a graph of AS connectivity
   from which routing loops may be pruned and some policy decisions at
   the AS level may be enforced.

   BGP is defined by [ROUTE:4].  [ROUTE:5] specifies the proper usage of
   BGP in the Internet, and provides some useful implementation hints
   and guidelines.  [ROUTE:12] and [ROUTE:13] provide additional useful
   information.

   To comply with Section [8.3] of this memo, a router that implements
   BGP is required to implement the BGP MIB [MGT:15].

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that an AS advertises to its
   neighbor ASs only those routes that it itself uses.  This rule
   reflects the hop-by-hop routing paradigm generally used throughout
   the current Internet.  Note that some policies cannot be supported by
   the hop-by-hop routing paradigm and thus require techniques such as

   source routing to enforce.  For example, BGP does not enable one AS
   to send traffic to a neighbor AS intending that traffic take a
   different route from that taken by traffic originating in the
   neighbor AS.  On the other hand, BGP can support any policy
   conforming to the hop-by-hop routing paradigm.

   Implementors of BGP are strongly encouraged to follow the
   recommendations outlined in Section 6 of [ROUTE:5].

7.3.2.2 Protocol Walk-through

   While BGP provides support for quite complex routing policies (as an
   example see Section 4.2 in [ROUTE:5]), it is not required for all BGP
   implementors to support such policies.  At a minimum, however, a BGP
   implementation:

   (1) SHOULD allow an AS to control announcements of the BGP learned
        routes to adjacent AS's.  Implementations SHOULD support such
        control with at least the granularity of a single network.
        Implementations SHOULD also support such control with the
        granularity of an autonomous system, where the autonomous system
        may be either the autonomous system that originated the route,
        or the autonomous system that advertised the route to the local
        system (adjacent autonomous system).

   (2) SHOULD allow an AS to prefer a particular path to a destination
        (when more than one path is available).  Such function SHOULD be
        implemented by allowing system administrator to assign weights
        to Autonomous Systems, and making route selection process to
        select a route with the lowest weight (where weight of a route
        is defined as a sum of weights of all AS's in the AS_PATH path
        attribute associated with that route).

   (3) SHOULD allow an AS to ignore routes with certain AS's in the
        AS_PATH path attribute.  Such function can be implemented by
        using technique outlined in (2), and by assigning infinity as
        weights for such AS's.  The route selection process must ignore
        routes that have weight equal to infinity.

7.3.3 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL

   It is possible to exchange routing information between two autonomous
   systems or routing domains without using a standard exterior routing
   protocol between two separate, standard interior routing protocols.
   The most common way of doing this is to run both interior protocols
   independently in one of the border routers with an exchange of route
   information between the two processes.

   As with the exchange of information from an EGP to an IGP, without
   appropriate controls these exchanges of routing information between
   two IGPs in a single router are subject to creation of routing loops.

7.4 STATIC ROUTING

   Static routing provides a means of explicitly defining the next hop
   from a router for a particular destination.  A router SHOULD provide
   a means for defining a static route to a destination, where the
   destination is defined by a network prefix.  The mechanism SHOULD
   also allow for a metric to be specified for each static route.

   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:

   o TOS,

   o Subnet Mask, or

   o Prefix Length, or

   o A metric specific to a given routing protocol that can import the
      route.

   DISCUSSION
      We intend that one needs to support only the things useful to the
      given routing protocol.  The need for TOS should not require the
      vendor to implement the other parts if they are not used.

      Whether a router prefers a static route over a dynamic route (or
      vice versa) or whether the associated metrics are used to choose
      between conflicting static and dynamic routes SHOULD be
      configurable for each static route.

      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:

           route 10.0.0.0/8 via 192.0.2.3 rip metric 3

           route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27

           route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99

   DISCUSSION
      It has been suggested that, ideally, static routes should have
      preference values rather than metrics (since metrics can only be
      compared with metrics of other routes in the same routing domain,
      the metric of a static route could only be compared with metrics
      of other static routes).  This is contrary to some current
      implementations, where static routes really do have metrics, and
      those metrics are used to determine whether a particular dynamic
      route overrides the static route to the same destination.  Thus,
      this document uses the term metric rather than preference.

      This technique essentially makes the static route into a RIP
      route, or an OSPF route (or whatever, depending on the domain of
      the metric).  Thus, the route lookup algorithm of that domain
      applies.  However, this is NOT route leaking, in that coercing a
      static route into a dynamic routing domain does not authorize the
      router to redistribute the route into the dynamic routing domain.

      For static routes not put into a specific routing domain, the
      route lookup algorithm is:

      (1) Basic match

      (2) Longest match

      (3) Weak TOS (if TOS supported)

      (4) Best metric (where metric are implementation-defined)

      The last step may not be necessary, but it's useful in the case
      where you want to have a primary static route over one interface
      and a secondary static route over an alternate interface, with
      failover to the alternate path if the interface for the primary
      route fails.

7.5 FILTERING OF ROUTING INFORMATION

   Each router within a network makes forwarding decisions based upon
   information contained within its forwarding database.  In a simple
   network the contents of the database may be configured statically.
   As the network grows more complex, the need for dynamic updating of
   the forwarding database becomes critical to the efficient operation
   of the network.

   If the data flow through a network is to be as efficient as possible,
   it is necessary to provide a mechanism for controlling the
   propagation of the information a router uses to build its forwarding
   database.  This control takes the form of choosing which sources of

   routing information should be trusted and selecting which pieces of
   the information to believe.  The resulting forwarding database is a
   filtered version of the available routing information.

   In addition to efficiency, controlling the propagation of routing
   information can reduce instability by preventing the spread of
   incorrect or bad routing information.

   In some cases local policy may require that complete routing
   information not be widely propagated.

   These filtering requirements apply only to non-SPF-based protocols
   (and therefore not at all to routers which don't implement any
   distance vector protocols).

7.5.1 Route Validation

   A router SHOULD log as an error any routing update advertising a
   route that violates the specifications of this memo, unless the
   routing protocol from which the update was received uses those values
   to encode special routes (such as default routes).

7.5.2 Basic Route Filtering

   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:

   o On which logical interfaces routing information will be accepted
      and which routes will be accepted from each logical interface.

   o Whether all routes or only a default route is advertised on a
      logical interface.

   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

   o from which other routers routing information will be accepted.

   For example, assume a router connecting one or more leaf networks to
   the main portion or backbone of a larger network.  Since each of the
   leaf networks has only one path in and out, the router can simply
   send a default route to them.  It advertises the leaf networks to the
   main network.

7.5.3 Advanced Route Filtering

   As the topology of a network grows more complex, the need for more
   complex route filtering arises.  Therefore, a router SHOULD provide
   the ability to specify independently for each routing protocol:

   o Which logical interfaces or routers routing information (routes)
      will be accepted from and which routes will be believed from each
      other router or logical interface,

   o Which routes will be sent via which logical interface(s), and

   o Which routers routing information will be sent to, if this is
      supported by the routing protocol in use.

   In many situations it is desirable to assign a reliability ordering
   to routing information received from another router instead of the
   simple believe or don't believe choice listed in the first bullet
   above.  A router MAY provide the ability to specify:

   o A reliability or preference to be assigned to each route received.
      A route with higher reliability will be chosen over one with lower
      reliability regardless of the routing metric associated with each
      route.

   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.

   DISCUSSION
      For example, assume a router receives a route to network C from
      router R and a route to the same network from router S.  If router
      R is considered more reliable than router S traffic destined for
      network C will be forwarded to router R regardless of the route
      received from router S.

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

7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE

   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

   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.

   Routers SHOULD provide some mechanism for translating or transforming
   metrics on a per network basis.  Routers (or routing protocols) MAY
   allow for global preference of exterior routes imported into an IGP.

   DISCUSSION
      Different IGPs use different metrics, requiring some translation
      technique when introducing information from one protocol into
      another protocol with a different form of metric.  Some IGPs can
      run multiple instances within the same router or set of routers.
      In this case metric information can be preserved exactly or
      translated.

      There are at least two techniques for translation between
      different routing processes.  The static (or reachability)
      approach uses the existence of a route advertisement in one IGP to
      generate a route advertisement in the other IGP with a given
      metric.  The translation or tabular approach uses the metric in
      one IGP to create a metric in the other IGP through use of either
      a function (such as adding a constant) or a table lookup.

      Bi-directional exchange of routing information is dangerous
      without control mechanisms to limit feedback.  This is the same
      problem that distance vector routing protocols must address with
      the split horizon technique and that EGP addresses with the
      third-party rule.  Routing loops can be avoided explicitly through
      use of tables or lists of permitted/denied routes or implicitly
      through use of a split horizon rule, a no-third-party rule, or a
      route tagging mechanism.  Vendors are encouraged to use implicit
      techniques where possible to make administration easier for
      network operators.

8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS

   Note that this chapter supersedes any requirements stated under
   "REMOTE MANAGEMENT" in [INTRO:3].

8.1 The Simple Network Management Protocol - SNMP

8.1.1 SNMP Protocol Elements

   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

   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.

   DISCUSSION
      This wording is intended to allow management either by proxy,
      where the proxy device responds to SNMP packets that have one of
      the router's IP addresses in the packets destination address
      field, or the SNMP is implemented directly in the router itself
      and receives packets and responds to them in the proper manner.

      It is important that management operations can be sent to one of
      the router's IP Addresses.  In diagnosing network problems the
      only thing identifying the router that is available may be one of
      the router's IP address; obtained perhaps by looking through
      another router's routing table.

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

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

   DISCUSSION
      Although there is general agreement about the need to rate-limit
      traps, there is not yet consensus on how this is best achieved.
      The reference cited is considered experimental.

8.2 Community Table

   For the purposes of this specification, we assume that there is an
   abstract `community table' in the router.  This table contains
   several entries, each entry for a specific community and containing
   the parameters necessary to completely define the attributes of that
   community.  The actual implementation method of the abstract
   community table is, of course, implementation specific.

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

   DISCUSSION
      A community table with zero capacity is useless.  It means that
      the router will not recognize any communities and, therefore, all
      SNMP operations will be rejected.

      Therefore, one entry is the minimal useful size of the table.
      Having two entries allows one entry to be limited to read-only
      access while the other would have write capabilities.

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

   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.

   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.

   DISCUSSION
      This is a rather limited authentication system, but coupled with
      various forms of packet filtering may provide some small measure
      of increased security.

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

   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.

   DISCUSSION
      By default, traps are not sent to this community.  Trap PDUs are
      sent to unicast IP addresses.  This address must be configured
      into the router in some manner.  Before the configuration occurs,
      there is no such address, so to whom should the trap be sent?
      Therefore trap sending to the public community defaults to be
      disabled.  This can, of course, be changed by an administrative
      operation once the router is operational.

8.3 Standard MIBS

   All MIBS relevant to a router's configuration are to be implemented.
   To wit:

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

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

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

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

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

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

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

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

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

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

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

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

   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.

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

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

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

   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.

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

   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.

8.4 Vendor Specific MIBS

   The Internet Standard and Experimental MIBs do not cover the entire
   range of statistical, state, configuration and control information
   that may be available in a network element.  This information is,
   nevertheless, extremely useful.  Vendors of routers (and other
   network devices) generally have developed MIB extensions that cover
   this information.  These MIB extensions are called Vendor Specific
   MIBs.

   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.

   DISCUSSION
      The intent of this requirement is to provide the ability to do
      anything on the router through SNMP that can be done through a
      console, and vice versa.  A certain minimal amount of
      configuration is necessary before SNMP can operate (e.g., the
      router must have an IP address).  This initial configuration can
      not be done through SNMP.  However, once the initial configuration
      is done, full capabilities ought to be available through network
      management.

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

   DISCUSSION
      Making the Vendor Specific MIB available to the user is necessary.
      Without this information the users would not be able to configure
      their network management systems to be able to access the Vendor
      Specific parameters.  These parameters would then be useless.

      ne 2 The format of the MIB specification is also specified.
      Parsers that read MIB specifications and generate the needed
      tables for the network management station are available.  These
      parsers generally understand only the standard MIB specification
      format.

8.5 Saving Changes

   Parameters altered by SNMP MAY be saved to non-volatile storage.

   DISCUSSION
      Reasons why this requirement is a MAY:

      o The exact physical nature of non-volatile storage is not
         specified in this document.  Hence, parameters may be saved in
         NVRAM/EEPROM, local floppy or hard disk, or in some TFTP file
         server or BOOTP server, etc.  Suppose that this information is
         in a file that is retrieved through TFTP.  In that case, a
         change made to a configuration parameter on the router would
         need to be propagated back to the file server holding the
         configuration file.  Alternatively, the SNMP operation would
         need to be directed to the file server, and then the change
         somehow propagated to the router.  The answer to this problem
         does not seem obvious.

         This also places more requirements on the host holding the
         configuration information than just having an available TFTP
         server, so much more that its probably unsafe for a vendor to
         assume that any potential customer will have a suitable host
         available.

      o The timing of committing changed parameters to non-volatile
         storage is still an issue for debate.  Some prefer to commit
         all changes immediately.  Others prefer to commit changes to
         non-volatile storage only upon an explicit command.

9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS

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

9.1 BOOTP

9.1.1 Introduction

   The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows
   a booting host to configure itself dynamically and without user

   supervision.  BOOTP provides a means to notify a host of its assigned
   IP address, the IP address of a boot server host, and the name of a
   file to be loaded into memory and executed ([APPL:1]).  Other
   configuration information such as the local prefix length or subnet
   mask, the local time offset, the addresses of default routers, and
   the addresses of various Internet servers can also be communicated to
   a host using BOOTP ([APPL:2]).

9.1.2 BOOTP Relay Agents

   In many cases, BOOTP clients and their associated BOOTP server(s) do
   not reside on the same IP (sub)network.  In such cases, a third-party
   agent is required to transfer BOOTP messages between clients and
   servers.  Such an agent was originally referred to as a BOOTP
   forwarding agent.  However, to avoid confusion with the IP forwarding
   function of a router, the name BOOTP relay agent has been adopted
   instead.

   DISCUSSION
      A BOOTP relay agent performs a task that is distinct from a
      router's normal IP forwarding function.  While a router normally
      switches IP datagrams between networks more-or-less transparently,
      a BOOTP relay agent may more properly be thought to receive BOOTP
      messages as a final destination and then generate new BOOTP
      messages as a result.  One should resist the notion of simply
      forwarding a BOOTP message straight through like a regular packet.

   This relay-agent functionality is most conveniently located in the
   routers that interconnect the clients and servers (although it may
   alternatively be located in a host that is directly connected to the
   client (sub)net).

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

   Section [5.2.3] discussed the circumstances under which a packet is
   delivered locally (to the router).  All locally delivered UDP
   messages whose UDP destination port number is BOOTPS (67) are
   considered for special processing by the router's logical BOOTP relay
   agent.

   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.

10. OPERATIONS AND MAINTENANCE

   This chapter supersedes any requirements of [INTRO:3] relating to
   "Extensions to the IP Module."

   Facilities to support operation and maintenance (O&M) activities form
   an essential part of any router implementation.  Although these
   functions do not seem to relate directly to interoperability, they
   are essential to the network manager who must make the router
   interoperate and must track down problems when it doesn't.  This
   chapter also includes some discussion of router initialization and of
   facilities to assist network managers in securing and accounting for
   their networks.

10.1 Introduction

   The following kinds of activities are included under router O&M:

   o Diagnosing hardware problems in the router's processor, in its
      network interfaces, or in its connected networks, modems, or
      communication lines.

   o Installing new hardware

   o Installing new software.

   o Restarting or rebooting the router after a crash.

   o Configuring (or reconfiguring) the router.

   o Detecting and diagnosing Internet problems such as congestion,
      routing loops, bad IP addresses, black holes, packet avalanches,
      and misbehaved hosts.

   o Changing network topology, either temporarily (e.g., to bypass a
      communication line problem) or permanently.

   o Monitoring the status and performance of the routers and the
      connected networks.

   o Collecting traffic statistics for use in (Inter-)network planning.

   o Coordinating the above activities with appropriate vendors and
      telecommunications specialists.

   Routers and their connected communication lines are often operated as
   a system by a centralized O&M organization.  This organization may
   maintain a (Inter-)network operation center, or NOC, to carry out its

   O&M functions.  It is essential that routers support remote control
   and monitoring from such a NOC through an Internet path, since
   routers might not be connected to the same network as their NOC.
   Since a network failure may temporarily preclude network access, many
   NOCs insist that routers be accessible for network management through
   an alternative means, often dial-up modems attached to console ports
   on the routers.

   Since an IP packet traversing an internet will often use routers
   under the control of more than one NOC, Internet problem diagnosis
   will often involve cooperation of personnel of more than one NOC.  In
   some cases, the same router may need to be monitored by more than one
   NOC, but only if necessary, because excessive monitoring could impact
   a router's performance.

   The tools available for monitoring at a NOC may cover a wide range of
   sophistication.  Current implementations include multi-window,
   dynamic displays of the entire router system.  The use of AI
   techniques for automatic problem diagnosis is proposed for the
   future.

   Router O&M facilities discussed here are only a part of the large and
   difficult problem of Internet management.  These problems encompass
   not only multiple management organizations, but also multiple
   protocol layers.  For example, at the current stage of evolution of
   the Internet architecture, there is a strong coupling between host
   TCP implementations and eventual IP-level congestion in the router
   system [OPER:1].  Therefore, diagnosis of congestion problems will
   sometimes require the monitoring of TCP statistics in hosts.  There
   are currently a number of R&D efforts in progress in the area of
   Internet management and more specifically router O&M.  These R&D
   efforts have already produced standards for router O&M.  This is also
   an area in which vendor creativity can make a significant
   contribution.

10.2 Router Initialization

10.2.1 Minimum Router Configuration

   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:

   (1) The router knows the IP address and associated subnet mask or
        network prefix length of at least one logical interface
        associated with that physical interface, or

   (2) The router knows that the interface is an unnumbered interface
        and knows its router-id.

   These parameters MUST be explicitly configured:

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

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

   DISCUSSION
      There have been instances in which routers have been shipped with
      vendor-installed default addresses for interfaces.  In a few
      cases, this has resulted in routers advertising these default
      addresses into active networks.

10.2.2 Address and Prefix Initialization

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

   A router MAY obtain its IP addresses and their corresponding address
   masks dynamically as a side effect of the system initialization
   process (see Section 10.2.3]);

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

   As was described in Section [4.2.2.11], IP addresses are not
   permitted to have the value 0 or -1 in the <Host-number> or
   <Network-prefix> fields.  Therefore, a router SHOULD NOT allow an IP
   address or address mask to be set to a value that would make any of
   the these fields above have the value zero or -1.

   DISCUSSION
      It is possible using arbitrary address masks to create situations
      in which routing is ambiguous (i.e., two routes with different but
      equally specific subnet masks match a particular destination
      address).  This is one of the strongest arguments for the use of
      network prefixes, and the reason the use of discontiguous subnet
      masks is not permitted.

   A router SHOULD make the following checks on any address mask it
   installs:

   o The mask is neither all ones nor all zeroes (the prefix length is
      neither zero nor 32).

   o The bits which correspond to the network prefix part of the address
      are all set to 1.

   o The bits that correspond to the network prefix are contiguous.

   DISCUSSION
      The masks associated with routes are also sometimes called subnet
      masks, this test should not be applied to them.

10.2.3 Network Booting using BOOTP and TFTP

   There has been much discussion of how routers can and should be
   booted from the network.  These discussions have revolved around
   BOOTP and TFTP.  Currently, there are routers that boot with TFTP
   from the network.  There is no reason that BOOTP could not be used
   for locating the server that the boot image should be loaded from.

   BOOTP is a protocol used to boot end systems, and requires some
   stretching to accommodate its use with routers.  If a router is using
   BOOTP to locate the current boot host, it should send a BOOTP Request
   with its hardware address for its first interface, or, if it has been
   previously configured otherwise, with either another interface's
   hardware address, or another number to put in the hardware address
   field of the BOOTP packet.  This is to allow routers without hardware
   addresses (like synchronous line only routers) to use BOOTP for
   bootload discovery.  TFTP can then be used to retrieve the image
   found in the BOOTP Reply.  If there are no configured interfaces or
   numbers to use, a router MAY cycle through the interface hardware
   addresses it has until a match is found by the BOOTP server.

   A router SHOULD IMPLEMENT the ability to store parameters learned
   through BOOTP into local non-volatile storage.  A router MAY
   implement the ability to store a system image loaded over the network
   into local stable storage.

   A router MAY have a facility to allow a remote user to request that
   the router get a new boot image.  Differentiation should be made
   between getting the new boot image from one of three locations: the
   one included in the request, from the last boot image server, and
   using BOOTP to locate a server.

10.3 Operation and Maintenance

10.3.1 Introduction

   There is a range of possible models for performing O&M functions on a
   router.  At one extreme is the local-only model, under which the O&M
   functions can only be executed locally (e.g., from a terminal plugged
   into the router machine).  At the other extreme, the fully remote
   model allows only an absolute minimum of functions to be performed
   locally (e.g., forcing a boot), with most O&M being done remotely
   from the NOC.  There are intermediate models, such as one in which
   NOC personnel can log into the router as a host, using the Telnet
   protocol, to perform functions that can also be invoked locally.  The
   local-only model may be adequate in a few router installations, but
   remote operation from a NOC is normally required, and therefore
   remote O&M provisions are required for most routers.

   Remote O&M functions may be exercised through a control agent
   (program).  In the direct approach, the router would support remote
   O&M functions directly from the NOC using standard Internet protocols
   (e.g., SNMP, UDP or TCP); in the indirect approach, the control agent
   would support these protocols and control the router itself using
   proprietary protocols.  The direct approach is preferred, although
   either approach is acceptable.  The use of specialized host hardware
   and/or software requiring significant additional investment is
   discouraged; nevertheless, some vendors may elect to provide the
   control agent as an integrated part of the network in which the
   routers are a part.  If this is the case, it is required that a means
   be available to operate the control agent from a remote site using
   Internet protocols and paths and with equivalent functionality with
   respect to a local agent terminal.

   It is desirable that a control agent and any other NOC software tools
   that a vendor provides operate as user programs in a standard
   operating system.  The use of the standard Internet protocols UDP and
   TCP for communicating with the routers should facilitate this.

   Remote router monitoring and (especially) remote router control
   present important access control problems that must be addressed.
   Care must also be taken to ensure control of the use of router
   resources for these functions.  It is not desirable to let router
   monitoring take more than some limited fraction of the router CPU
   time, for example.  On the other hand, O&M functions must receive
   priority so they can be exercised when the router is congested, since
   often that is when O&M is most needed.

10.3.2 Out Of Band Access

   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.

   DISCUSSION
      This Out-Of-Band access will allow the NOC a way to access
      isolated routers during times when network access is not
      available.

      Out-Of-Band access is an important management tool for the network
      administrator.  It allows the access of equipment independent of
      the network connections.  There are many ways to achieve this
      access.  Whichever one is used it is important that the access is
      independent of the network connections.  An example of Out-Of-Band
      access would be a serial port connected to a modem that provides
      dial up access to the router.

      It is important that the OOB access provides the same
      functionality as in-band access.  In-band access, or accessing
      equipment through the existing network connection, is limiting,
      because most of the time, administrators need to reach equipment
      to figure out why it is unreachable.  In band access is still very
      important for configuring a router, and for troubleshooting more
      subtle problems.

10.3.3 Router O&M Functions

10.3.3.1 Maintenance - Hardware Diagnosis

   Each router SHOULD operate as a stand-alone device for the purposes
   of local hardware maintenance.  Means SHOULD be available to run
   diagnostic programs at the router site using only on-site tools.  A
   router SHOULD be able to run diagnostics in case of a fault.  For
   suggested hardware and software diagnostics see Section [10.3.3].

10.3.3.2 Control - Dumping and Rebooting

   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.

   A router SHOULD IMPLEMENT a mechanism for dumping the contents of a
   router's memory (and/or other state useful for vendor debugging after
   a crash), and either saving them on a stable storage device local to

   the router or saving them on another host via an up-line dump
   mechanism such as TFTP (see [OPER:2], [INTRO:3]).

10.3.3.3 Control - Configuring the Router

   Every router has configuration parameters that may need to be set.
   It SHOULD be possible to update the parameters without rebooting the
   router; at worst, a restart MAY be required.  There may be cases when
   it is not possible to change parameters without rebooting the router
   (for instance, changing the IP address of an interface).  In these
   cases, care should be taken to minimize disruption to the router and
   the surrounding network.

   There SHOULD be a way to configure the router over the network either
   manually or automatically.  A router SHOULD be able to upload or
   download its parameters from a host or another router.  A means
   SHOULD be provided, either as an application program or a router
   function, to convert between the parameter format and a human-
   editable format.  A router SHOULD have some sort of stable storage
   for its configuration.  A router SHOULD NOT believe protocols such as
   RARP, ICMP Address Mask Reply, and MAY not believe BOOTP.

   DISCUSSION
      It is necessary to note here that in the future RARP, ICMP Address
      Mask Reply, BOOTP and other mechanisms may be needed to allow a
      router to auto-configure.  Although routers may in the future be
      able to configure automatically, the intent here is to discourage
      this practice in a production environment until auto-configuration
      has been tested more thoroughly.  The intent is NOT to discourage
      auto-configuration all together.  In cases where a router is
      expected to get its configuration automatically it may be wise to
      allow the router to believe these things as it comes up and then
      ignore them after it has gotten its configuration.

10.3.3.4 Net Booting of System Software

      A router SHOULD keep its system image in local non-volatile
      storage such as PROM, NVRAM, or disk.  It MAY also be able to load
      its system software over the network from a host or another
      router.

      A router that can keep its system image in local non-volatile
      storage MAY be configurable to boot its system image over the
      network.  A router that offers this option SHOULD be configurable
      to boot the system image in its non-volatile local storage if it
      is unable to boot its system image over the network.

   DISCUSSION
      It is important that the router be able to come up and run on its
      own.  NVRAM may be a particular solution for routers used in large
      networks, since changing PROMs can be quite time consuming for a
      network manager responsible for numerous or geographically
      dispersed routers.  It is important to be able to netboot the
      system image because there should be an easy way for a router to
      get a bug fix or new feature more quickly than getting PROMs
      installed.  Also if the router has NVRAM instead of PROMs, it will
      netboot the image and then put it in NVRAM.

      Routers SHOULD perform some basic consistency check on any image
      loaded, to detect and perhaps prevent incorrect images.

   A router MAY also be able to distinguish between different
   configurations based on which software it is running.  If
   configuration commands change from one software version to another,
   it would be helpful if the router could use the configuration that
   was compatible with the software.

10.3.3.5 Detecting and responding to misconfiguration

   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.

   DISCUSSION
      There are cases where it is not possible to detect errors: the
      command is correctly formed, but incorrect with respect to the
      network.  This may be detected by the router, but may not be
      possible.

   Another form of misconfiguration is misconfiguration of the network
   to which the router is attached.  A router MAY detect
   misconfigurations in the network.  The router MAY log these findings
   to a file, either on the router or a host, so that the network
   manager will see that there are possible problems on the network.

   DISCUSSION
      Examples of such misconfigurations might be another router with
      the same address as the one in question or a router with the wrong
      address mask.  If a router detects such problems it is probably
      not the best idea for the router to try to fix the situation.
      That could cause more harm than good.

10.3.3.6 Minimizing Disruption

   Changing the configuration of a router SHOULD have minimal affect on
   the network.  Routing tables SHOULD NOT be unnecessarily flushed when
   a simple change is made to the router.  If a router is running
   several routing protocols, stopping one routing protocol SHOULD NOT
   disrupt other routing protocols, except in the case where one network
   is learned by more than one routing protocol.

   DISCUSSION
      It is the goal of a network manager to run a network so that users
      of the network get the best connectivity possible.  Reloading a
      router for simple configuration changes can cause disruptions in
      routing and ultimately cause disruptions to the network and its
      users.  If routing tables are unnecessarily flushed, for instance,
      the default route will be lost as well as specific routes to sites
      within the network.  This sort of disruption will cause
      significant downtime for the users.  It is the purpose of this
      section to point out that whenever possible, these disruptions
      should be avoided.

10.3.3.7 Control - Troubleshooting Problems

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

   DISCUSSION
      In-band access primarily refers to access through the normal
      network protocols that may or may not affect the permanent
      operational state of the router.  This includes, but is not
      limited to Telnet/RLOGIN console access and SNMP operations.

      This was a point of contention between the operational out of the
      box and secure out of The box contingents.  Any automagic access
      to the router may introduce insecurities, but it may be more
      important for the customer to have a router that is accessible
      over the network as soon as it is plugged in.  At least one vendor
      supplies routers without any external console access and depends
      on being able to access the router through the network to complete
      its configuration.

      It is the vendors call whether in-band access is enabled by
      default; but it is also the vendor's responsibility to make its
      customers aware of possible insecurities.

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

           o Choice of data patterns

           o Choice of packet size

           o Record route

           and the following additional options MAY be implemented:

           o Loose source route

           o Strict source route

           o Timestamps

      (3) A router SHOULD provide the ability to initiate a traceroute.
           If traceroute is provided, then the 3rd party traceroute
           SHOULD be implemented.

   Each of the above three facilities (if implemented) SHOULD have
   access restrictions placed on it to prevent its abuse by unauthorized
   persons.

10.4 Security Considerations

10.4.1 Auditing and Audit Trails

   Auditing and billing are the bane of the network operator, but are
   the two features most requested by those in charge of network
   security and those who are responsible for paying the bills.  In the
   context of security, auditing is desirable if it helps you keep your
   network working and protects your resources from abuse, without
   costing you more than those resources are worth.

   (1) Configuration Changes

        Router SHOULD provide a method for auditing a configuration
        change of a router, even if it's something as simple as
        recording the operator's initials and time of change.

   DISCUSSION
      Configuration change logging (who made a configuration change,
      what was changed, and when) is very useful, especially when
      traffic is suddenly routed through Alaska on its way across town.
      So is the ability to revert to a previous configuration.

      (2) Packet Accounting

           Vendors should strongly consider providing a system for
           tracking traffic levels between pairs of hosts or networks.
           A mechanism for limiting the collection of this information
           to specific pairs of hosts or networks is also strongly
           encouraged.

   DISCUSSION
      A host traffic matrix as described above can give the network
      operator a glimpse of traffic trends not apparent from other
      statistics.  It can also identify hosts or networks that are
      probing the structure of the attached networks - e.g., a single
      external host that tries to send packets to every IP address in
      the network address range for a connected network.

      (3) Security Auditing

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

           o Authorization Failures: bad passwords, invalid SNMP
              communities, invalid authorization tokens,

           o Violations of Policy Controls: Prohibited Source Routes,
              Filtered Destinations, and

           o Authorization Approvals: good passwords - Telnet in-band
              access, console access.

           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.

10.4.2 Configuration Control

   A vendor has a responsibility to use good configuration control
   practices in the creation of the software/firmware loads for their
   routers.  In particular, if a vendor makes updates and loads
   available for retrieval over the Internet, the vendor should also
   provide a way for the customer to confirm the load is a valid one,
   perhaps by the verification of a checksum over the load.

   DISCUSSION
      Many vendors currently provide short notice updates of their
      software products through the Internet.  This a good trend and
      should be encouraged, but provides a point of vulnerability in the
      configuration control process.

   If a vendor provides the ability for the customer to change the
   configuration parameters of a router remotely, for example through a
   Telnet session, the ability to do so SHOULD be configurable and
   SHOULD default to off.  The router SHOULD require  valid
   authentication before permitting remote reconfiguration.  This
   authentication procedure SHOULD NOT transmit the authentication
   secret over the network.  For example, if telnet is implemented, the
   vendor SHOULD IMPLEMENT Kerberos, S-Key, or a similar authentication
   procedure.

   DISCUSSION
      Allowing your properly identified network operator to twiddle with
      your routers is necessary; allowing anyone else to do so is
      foolhardy.

   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.

   DISCUSSION
      A vendor has a responsibility to its customers to ensure they are
      aware of the vulnerabilities present in its code by intention -
      e.g., in-band access.  Trap doors, back doors and master passwords
      intentional or unintentional can turn a relatively secure router
      into a major problem on an operational network.  The supposed
      operational benefits are not matched by the potential problems.