mechanism for immediately notifying a router's
neighbors when the router adds or deletes routes or
changes their metrics. A router MUST send a triggered
update when routes are deleted or their metrics are
increased. A router MAY send a triggered update when
routes are added or their metrics decreased.
Since triggered updates can cause excessive routing
overhead, implementations MUST use the following
mechanism to limit the frequency of triggered updates:
(1) When a router sends a triggered update, it sets a
timer to a random time between one and five
seconds in the future. The router must not
generate additional triggered updates before this
timer expires.
(2) If the router would generate a triggered update
during this interval it sets a flag indicating
that a triggered update is desired. The router
also logs the desired triggered update.
(3) When the triggered update timer expires, the
router checks the triggered update flag. If the
flag is set then the router sends a single
triggered update which includes all of the changes
that were logged. The router then clears the flag
and, since a triggered update was sent, restarts
this algorithm.
(4) The flag is also cleared whenever a regular update
is sent.
Triggered updates SHOULD include all routes that have
changed since the most recent regular (non-triggered)
update. Triggered updates MUST NOT include routes that
have not changed since the most recent regular update.
DISCUSSION:
Sending all routes, whether they have changed
recently or not, is unacceptable in triggered
updates because the tremendous size of many Internet
routing tables could otherwise result in
considerable bandwidth being wasted on triggered
updates.
Use of UDP: [ROUTE:3], pp. 18-19.
RIP packets sent to an IP broadcast address SHOULD have
their initial TTL set to one.
Note that to comply with Section [6.1] of this memo, a
router MUST use UDP checksums in RIP packets which it
originates, MUST discard RIP packets received with
invalid UDP checksums, but MUST not discard received
RIP packets simply because they do not contain UDP
checksums.
Addressing Considerations: [ROUTE:3], pp. 22
A RIP implementation SHOULD support host routes. If it
does not, it MUST (as described on page 27 of
[ROUTE:3]) ignore host routes in received updates. A
router MAY log ignored hosts routes.
The special address 0.0.0.0 is used to describe a
default route. A default route is used as the route of
last resort (i.e. when a route to the specific net does
not exist in the routing table). The router MUST be
able to create a RIP entry for the address 0.0.0.0.
Input Processing - Response: [ROUTE:3], pp. 26
When processing an update, the following validity
checks MUST be performed:
o The response MUST be from UDP port 520.
o The source address MUST be on a directly connected
subnet (or on a directly connected, non-subnetted
network) to be considered valid.
o The source address MUST NOT be one of the router's
addresses.
DISCUSSION:
Some networks, media, and interfaces allow a
sending node to receive packets that it
broadcasts. A router must not accept its own
packets as valid routing updates and process
them. The last requirement prevents a router
from accepting its own routing updates and
processing them (on the assumption that they were
sent by some other router on the network).
An implementation MUST NOT replace an existing route if
the metric received is equal to the existing metric
except in accordance with the following heuristic.
An implementation MAY choose to implement the following
heuristic to deal with the above situation. Normally,
it is useless to change the route to a network from one
router to another if both are advertised at the same
metric. However, the route being advertised by one of
the routers may be in the process of timing out.
Instead of waiting for the route to timeout, the new
route can be used after a specified amount of time has
elapsed. If this heuristic is implemented, it MUST wait
at least halfway to the expiration point before the new
route is installed.
7.2.4.3 Specific Issues
RIP Shutdown
An implementation of RIP SHOULD provide for a graceful
shutdown using the following steps:
(1) Input processing is terminated,
(2) Four updates are generated at random intervals of
between two and four seconds, These updates contain
all routes that were previously announced, but with
some metric changes. Routes that were being
announced at a metric of infinity should continue to
use this metric. Routes that had been announced with
a non-infinite metric should be announced with a
metric of 15 (infinity - 1).
DISCUSSION:
The metric used for the above really ought to be
16 (infinity); setting it to 15 is a kludge to
avoid breaking certain old hosts which wiretap the
RIP protocol. Such a host will (erroneously)
abort a TCP connection if it tries to send a
datagram on the connection while the host has no
route to the destination (even if the period when
the host has no route lasts only a few seconds
while RIP chooses an alternate path to the
destination).
RIP Split Horizon and Static Routes
Split horizon SHOULD be applied to static routes by
default. An implementation SHOULD provide a way to
specify, per static route, that split horizon should not
be applied to this route.
7.2.5 GATEWAY TO GATEWAY PROTOCOL - GGP
The Gateway to Gateway protocol is considered obsolete and SHOULD
NOT be implemented.
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 [7.3.3] has traditionally been
the inter-AS protocol of choice. 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) is an inter-AS routing
protocol which 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 which
implements BGP MUST also 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 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 EXTERIOR GATEWAY PROTOCOL - EGP
7.3.3.1 Introduction
The Exterior Gateway Protocol (EGP) specifies an EGP which is
used to exchange reachability information between routers of
the same or differing autonomous systems. EGP is not considered
a routing protocol since there is no standard interpretation
(i.e. metric) for the distance fields in the EGP update
message, so distances are comparable only among routers of the
same AS. It is however designed to provide high-quality
reachability information, both about neighbor routers and about
routes to non-neighbor routers.
EGP is defined by [ROUTE:6]. An implementor almost certainly
wants to read [ROUTE:7] and [ROUTE:8] as well, for they contain
useful explanations and background material.
DISCUSSION:
The present EGP specification has serious limitations, most
importantly a restriction which limits routers to
advertising only those networks which are reachable from
within the router's autonomous system. This restriction
against propagating third party EGP information is to
prevent long-lived routing loops. This effectively limits
EGP to a two-level hierarchy.
RFC-975 is not a part of the EGP specification, and should
be ignored.
7.3.3.2 Protocol Walk-through
Indirect Neighbors: RFC-888, pp. 26
An implementation of EGP MUST include indirect neighbor
support.
Polling Intervals: RFC-904, pp. 10
The interval between Hello command retransmissions and the
interval between Poll retransmissions SHOULD be configurable
but there MUST be a minimum value defined.
The interval at which an implementation will respond to
Hello commands and Poll commands SHOULD be configurable but
there MUST be a minimum value defined.
Network Reachability: RFC-904, pp. 15
An implementation MUST default to not providing the external
list of routers in other autonomous systems; only the
internal list of routers together with the nets which are
reachable via those routers should be included in an Update
Response/Indication packet. However, an implementation MAY
elect to provide a configuration option enabling the
external list to be provided. An implementation MUST NOT
include in the external list routers which were learned via
the external list provided by a router in another autonomous
system. An implementation MUST NOT send a network back to
the autonomous system from which it is learned, i.e. it MUST
do split-horizon on an autonomous system level.
If more than 255 internal or 255 external routers need to be
specified in a Network Reachability update, the networks
reachable from routers that can not be listed MUST be merged
into the list for one of the listed routers. Which of the
listed routers is chosen for this purpose SHOULD be user
configurable, but SHOULD default to the source address of
the EGP update being generated.
An EGP update contains a series of blocks of network
numbers, where each block contains a list of network numbers
reachable at a particular distance via a particular router.
If more than 255 networks are reachable at a particular
distance via a particular router, they are split into
multiple blocks (all of which have the same distance).
Similarly, if more than 255 blocks are required to list the
networks reachable via a particular router, the router's
address is listed as many times as necessary to include all
of the blocks in the update.
Unsolicited Updates: RFC-904, pp. 16
If a network is shared with the peer, an implementation MUST
send an unsolicited update upon entry to the Up state
assuming that the source network is the shared network.
Neighbor Reachability: RFC-904, pp. 6, 13-15
The table on page 6 which describes the values of j and k
(the neighbor up and down thresholds) is incorrect. It is
reproduced correctly here:
Name Active Passive Description
-----------------------------------------------
j 3 1 neighbor-up threshold
k 1 0 neighbor-down threshold
The value for k in passive mode also specified incorrectly
in RFC-904, pp. 14 The values in parenthesis should read:
(j = 1, k = 0, and T3/T1 = 4)
As an optimization, an implementation can refrain from
sending a Hello command when a Poll is due. If an
implementation does so, it SHOULD provide a user
configurable option to disable this optimization.
Abort timer: RFC-904, pp. 6, 12, 13
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.
7.3.4 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 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
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 36.0.0.0 255.0.0.0 via 192.19.200.3 rip metric 3
route 36.21.0.0 255.255.0.0 via 192.19.200.4 ospf inter-area
metric 27
route 36.22.0.0 255.255.0.0 via 192.19.200.5 egp 123 metric 99
route 36.23.0.0 255.255.0.0 via 192.19.200.6 igrp 47 metric 1 2
3 4 5
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 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
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 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.
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 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.
DISCUSSION:
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].
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. 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.
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] MAY
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 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
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 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
[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.
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.
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 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
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 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.
DISCUSSION:
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
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 which 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 stated in section 6.2 of
[INTRO:3].
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 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
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 of
at least one logical interface associated with that physical
interface, or
(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.
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 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 [4.2.2.11], 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.
DISCUSSION:
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
we know of no published method for accurately making this
check.
A router SHOULD make the following checks on any subnet mask it
installs:
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.
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 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
made between getting the new boot image from one of three
locations: the one included in the request, from the last boot