tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 1716


Towards Requirements for IP Routers

Part 5 of 6, p. 130 to 159
Prev RFC Part       Next RFC Part


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

         Cease command received in Idle state: RFC-904, pp. 13

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

         Hello Polling Mode: RFC-904, pp. 11

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

         Neighbor Acquisition Messages: RFC-904, pp. 18

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

         Sequence Numbers: RFC-904, pp. 10

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


      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

Top      Up      ToC       Page 131 
      appropriate controls these exchanges of routing information
      between two IGPs in a single router are subject to creation of
      routing loops.


   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 an address and an address mask.  The
   mechanism SHOULD also allow for a metric to be specified for each
   static route.

   A router which 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 which may or may not be propagated via 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  A metric specific to a given routing protocol that can import the

      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 via rip metric 3

        route via ospf inter-area
        metric 27

Top      Up      ToC       Page 132 
        route via egp 123 metric 99

        route via igrp 47 metric 1 2
        3 4 5

      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.

Top      Up      ToC       Page 133 

   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 statically configured.
   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 to network zero, subnet zero, or subnet -1, 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

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

      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

      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

Top      Up      ToC       Page 135 
      does not prefer.

         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


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

      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

      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

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

Top      Up      ToC       Page 137 

Note that this chapter supersedes any requirements stated in section 6.3
of [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.

         This wording is intended to allow management either by proxy,
         where the proxy device responds to SNMP packets which 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 via the
      algorithms for asynchronous alert management described in [MGT:5].

         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.

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

      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.  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
   traps are sent for each community.  These addresses MUST be definable
   on a per-community basis.  Traps MUST be enablable or disablable on a
   per-community 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.

      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,

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

      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

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

   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] MAY
      be implemented.

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

Top      Up      ToC       Page 140 
   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 RS-232 interfaces 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,
   never the less, 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

   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.

Top      Up      ToC       Page 141 
      The intent of this requirement is to provide the ability to do
      anything on the router via SNMP that can be done via a console.  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 via SNMP. However, once the
      initial configuration is done, full capabilities ought to be
      available via 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

      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.

      The format of the MIB specification is also specified.  Parsers
      which 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.

      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 that this information
         is in a file that is retrieved via 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

Top      Up      ToC       Page 142 
         server, so much more that its probably unsafe for a vendor to
         assume that any potential customer will have a suitable host

      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.

Top      Up      ToC       Page 143 

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 which
      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 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 network or subnet.  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, in order to avoid confusion
      with the IP forwarding function of a router, the name BOOTP relay
      agent has been adopted instead.

         A BOOTP relay agent performs a task which 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 which interconnect the clients and servers (although it
      may alternatively be located in a host which is directly connected
      to the client subnet).

      A router MAY provide BOOTP relay-agent capability.  If it does, it

Top      Up      ToC       Page 144 
      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 [] 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
      However, routers which support a BOOTP relay agent MUST accept for
      local delivery to the relay agent BOOTREQUEST messages whose IP
      source address is

Top      Up      ToC       Page 145 

This chapter supersedes any requirements stated in section 6.2 of

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

Top      Up      ToC       Page 146 
   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 via an
   alternative means, often dialup 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

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 of
           at least one logical interface associated with that physical
           interface, or

Top      Up      ToC       Page 147 
      (2)  The router knows that the interface is an unnumbered
           interface and also knows its router-id.

      These parameters MUST be explicitly configured:

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

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

         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 Address Mask Initialization

      A router MUST allow its IP addresses and their subnet masks to be
      statically configured and saved in permanent storage.

      A router MAY obtain its IP addresses and their corresponding
      subnet 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 [], IP addresses are not
      permitted to have the value 0 or -1 for any of the <Host-number>,
      <Network-number>, or <Subnet-number> fields.  Therefore, a router
      SHOULD NOT allow an IP address or subnet mask to be set to a value
      which would make any of the the three fields above have the value
      zero or -1.

         It is possible using variable length subnet 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).  We suspect that a router could, when
         setting a subnet mask, check whether the mask would cause
         routing to be ambiguous, and that implementors might be able to
         decrease their customer support costs by having routers
         prohibit or log such erroneous configurations.  However, at
         this time we do not require routers to make such checks because

Top      Up      ToC       Page 148 
         we know of no published method for accurately making this

      A router SHOULD make the following checks on any subnet mask it

      o  The mask is not all 1-bits.

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

         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 a lot of discussion on how routers can and should
      be booted from the network.  In general, these discussions have
      centered 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.

      In general, 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 sync
      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
      via BOOTP into local stable 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

Top      Up      ToC       Page 149 
      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 which
      can also be invoked locally.  The local-only model may be adequate
      in a few router installations, but in general remote operation
      from a NOC will be 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

      It is desirable that a control agent and any other NOC software
      tools which 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 which must be addressed.

Top      Up      ToC       Page 150 
      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 Out-Of-Band access will allow the NOC a way to access
         isolated routers during times when network access is not

         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.2  Router O&M Functions  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].

Top      Up      ToC       Page 151  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]).  Control - Configuring the Router

         Every router has configuration parameters which 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

         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, and these parameters SHOULD be convertible into some
         sort of text format for making changes and then back to the
         form the router can read.  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.

            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 such time as 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

Top      Up      ToC       Page 152 
            up and then ignore them after it has gotten its
            configuration.  Netbooting 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 which can keep its system image in local non-volatile
         storage MAY be configurable to boot its system image over the
         network.  A router which 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

            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.

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

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

            Examples of such misconfigurations might be another router
            with the same address as the one in question or a router
            with the wrong subnet 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.  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.

            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.

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

                 In-band access primarily refers to access via the
                 normal network protocols which 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 which 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
                 via the network to complete its configuration.

                 Basically, it is the vendors call whether or not in-
                 band access is enabled by default; but it is also the
                 vendors 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

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

              Having the ability to track who made changes and when is
              highly desirable, especially if your packets suddenly
              start getting routed through Alaska on their way across

      (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

              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 which are probing the structure of the attached
              networks - e.g., a single external host which tries to
              send packets to every IP address in the network address

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

         Many vendors currently provide short notice updates of their
         software products via 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 via a
      Telnet session, the ability to do so SHOULD be configurable and
      SHOULD default to off.  The router SHOULD require a password or
      other valid authentication before permitting remote

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

         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.

Top      Up      ToC       Page 158 

Implementors should be aware that Internet protocol standards are
occasionally updated.  These references are current as of this writing,
but a cautious implementor will always check a recent version of the RFC
index to ensure that an RFC has not been updated or superseded by
another, more recent RFC.  Reference [INTRO:6] explains various ways to
obtain a current RFC index.

     B. Croft and J. Gilmore, Bootstrap Protocol (BOOTP), Request For
     Comments (RFC) 951, Stanford and SUN Microsystems, September 1985.

     S. Alexander and R. Droms, DHCP Options and BOOTP Vendor
     Extensions, Request For Comments (RFC) 1533, Lachman Technology,
     Inc., Bucknell University, October 1993.

     W. Wimer, Clarifications and Extensions for the Bootstrap Protocol,
     Request For Comments (RFC) 1542, Carnegie Mellon University,
     October 1993.

     DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three
     volumes), DDN Network Information Center, SRI International, Menlo
     Park, California, USA, December 1985.

     V. Cerf and R. Kahn, A Protocol for Packet Network
     Intercommunication," IEEE Transactions on Communication, May 1974.
     Also included in [ARCH:1].

     J. Postel, C. Sunshine, and D. Cohen, The ARPA Internet Protocol,"
     Computer Networks, vol. 5, no. 4, July 1981.  Also included in

     B. Leiner, J. Postel, R. Cole, and D. Mills, The DARPA Internet
     Protocol Suite, Proceedings of INFOCOM '85, IEEE, Washington, DC,
     March 1985.  Also in: IEEE Communications Magazine, March 1985.
     Also available from the Information Sciences Institute, University
     of Southern California as Technical Report ISI-RS-85-153.

Top      Up      ToC       Page 159 
     D. Comer, Internetworking With TCP/IP Volume 1: Principles,
     Protocols, and Architecture, Prentice Hall, Englewood Cliffs, NJ,

     W. Stallings, Handbook of Computer-Communications Standards Volume
     3: The TCP/IP Protocol Suite, Macmillan, New York, NY, 1990.

     J. Postel, Internet Official Protocol Standards, Request For
     Comments (RFC) 1610, STD 1, USC/Information Sciences Institute,
     July 1994.

     Information processing systems - Open Systems Interconnection -
     Basic Reference Model, ISO 7489, International Standards
     Organization, 1984.

     IETF CIP Working Group (C. Topolcic, Editor), Experimental Internet
     Stream Protocol, Version 2 (ST-II), Request For Comments (RFC)
     1190, CIP Working Group, October 1990.

     A. Mankin and K. Ramakrishnan, Editors, Gateway Congestion Control
     Survey, Request For Comments (RFC) 1254, MITRE, Digital Equipment
     Corporation, August 1991.

     J. Nagle, On Packet Switches with Infinite Storage, IEEE
     Transactions on Communications, vol. COM-35, no. 4, April 1987.

     R. Jain, K. Ramakrishnan, and D. Chiu, Congestion Avoidance in
     Computer Networks With a Connectionless Network Layer, Technical
     Report DEC-TR-506, Digital Equipment Corporation.

     V. Jacobson, Congestion Avoidance and Control, Proceedings of
     SIGCOMM '88, Association for Computing Machinery, August 1988.

     W. Barns, Precedence and Priority Access Implementation for
     Department of Defense Data Networks, Technical Report MTR-91W00029,
     The Mitre Corporation, McLean, Virginia, USA, July 1991.

Next RFC Part