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
terminal.
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.
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.
DISCUSSION:
This Out-Of-Band access will allow the NOC a way to access
isolated routers during times when network access is not
available.
Out-Of-Band access is an important management tool for the
network administrator. It allows the access of equipment
independent of the network connections. There are many ways to
achieve this access. Whichever one is used it is important
that the access is independent of the network connections. An
example of Out-Of-Band access would be a serial port connected
to a modem that provides dial up access to the router.
It is important that the OOB access provides the same
functionality as in-band access. In-band access, or accessing
equipment through the existing network connection, is limiting,
because most of the time, administrators need to reach
equipment to figure out why it is unreachable. In band access
is still very important for configuring a router, and for
troubleshooting more subtle problems.
10.3.2 Router O&M Functions
10.3.2.1 Maintenance - Hardware Diagnosis
Each router SHOULD operate as a stand-alone device for the
purposes of local hardware maintenance. Means SHOULD be
available to run diagnostic programs at the router site using
only on-site tools. A router SHOULD be able to run diagnostics
in case of a fault. For suggested hardware and software
diagnostics see Section [10.3.3].
10.3.2.2 Control - Dumping and Rebooting
A router MUST include both in-band and out-of-band mechanisms
to allow the network manager to reload, stop, and restart the
router. A router SHOULD also contain a mechanism (such as a
watchdog timer) which will reboot the router automatically if
it hangs due to a software or hardware fault.
A router SHOULD IMPLEMENT a mechanism for dumping the contents
of a router's memory (and/or other state useful for vendor
debugging after a crash), and either saving them on a stable
storage device local to the router or saving them on another
host via an up-line dump mechanism such as TFTP (see [OPER:2],
[INTRO:3]).
10.3.2.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
network.
There SHOULD be a way to configure the router over the network
either manually or automatically. A router SHOULD be able to
upload or download its parameters from a host or another
router, 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.
DISCUSSION:
It is necessary to note here that in the future RARP, ICMP
Address Mask Reply, BOOTP and other mechanisms may be needed
to allow a router to auto-configure. Although routers may
in the future be able to configure automatically, the intent
here is to discourage this practice in a production
environment until 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
up and then ignore them after it has gotten its
configuration.
10.3.2.4 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
network.
DISCUSSION:
It is important that the router be able to come up and run
on its own. NVRAM may be a particular solution for routers
used in large networks, since changing PROMs can be quite
time consuming for a network manager responsible for
numerous or geographically dispersed routers. It is
important to be able to netboot the system image because
there should be an easy way for a router to get a bug fix or
new feature more quickly than getting PROMS installed. Also
if the router has NVRAM instead of PROMs, it will netboot
the image and then put it in NVRAM.
A router MAY also be able to distinguish between different
configurations based on which software it is running. If
configuration commands change from one software version to
another, it would be helpful if the router could use the
configuration that was compatible with the software.
10.3.2.5 Detecting and responding to misconfiguration
There MUST be mechanisms for detecting and responding to
misconfigurations. If a command is executed incorrectly, the
router SHOULD give an error message. The router SHOULD NOT
accept a poorly formed command as if it were correct.
DISCUSSION:
There are cases where it is not possible to detect errors:
the command is correctly formed, but incorrect with respect
to the network. This may be detected by the router, but may
not be possible.
Another form of misconfiguration is misconfiguration of the
network to which the router is attached. A router MAY detect
misconfigurations in the network. The router MAY log these
findings to a file, either on the router or a host, so that the
network manager will see that there are possible problems on
the network.
DISCUSSION:
Examples of such misconfigurations might be another router
with the same address as the one in question or a router
with the wrong 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.
10.3.2.6 Minimizing Disruption
Changing the configuration of a router SHOULD have minimal
affect on the network. Routing tables SHOULD NOT be
unnecessarily flushed when a simple change is made to the
router. If a router is running several routing protocols,
stopping one routing protocol SHOULD NOT disrupt other routing
protocols, except in the case where one network is learned by
more than one routing protocol.
DISCUSSION:
It is the goal of a network manager to run a network so that
users of the network get the best connectivity possible.
Reloading a router for simple configuration changes can
cause disruptions in routing and ultimately cause
disruptions to the network and its users. If routing tables
are unnecessarily flushed, for instance, the default route
will be lost as well as specific routes to sites within the
network. This sort of disruption will cause significant
downtime for the users. It is the purpose of this section to
point out that whenever possible, these disruptions should
be avoided.
10.3.2.7 Control - Troubleshooting Problems
(1) A router MUST provide in-band network access, but (except
as required by Section [8.2]) for security considerations
this access SHOULD be disabled by default. Vendors MUST
document the default state of any in-band access.
DISCUSSION:
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
(3) A router SHOULD provide the ability to initiate a
traceroute. If traceroute is provided, then the 3rd party
traceroute SHOULD be implemented.
Each of the above three facilities (if implemented) SHOULD have
access restrictions placed on it to prevent its abuse by
unauthorized persons.
10.4 Security Considerations
10.4.1 Auditing and Audit Trails
Auditing and billing are the bane of the network operator, but are
the two features most requested by those in charge of network
security and those who are responsible for paying the bills. In
the context of security, auditing is desirable if it helps you
keep your network working and protects your resources from abuse,
without costing you more than those resources are worth.
(1) Configuration Changes
Router SHOULD provide a method for auditing a configuration
change of a router, even if it's something as simple as
recording the operator's initials and time of change.
DISCUSSION:
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
town.
(2) Packet Accounting
Vendors should strongly consider providing a system for
tracking traffic levels between pairs of hosts or networks.
A mechanism for limiting the collection of this information
to specific pairs of hosts or networks is also strongly
encouraged.
DISCUSSION:
A host traffic matrix as described above can give the
network operator a glimpse of traffic trends not apparent
from other statistics. It can also identify hosts or
networks 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
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.
DISCUSSION:
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
reconfiguration.
DISCUSSION:
Allowing your properly identified network operator to twiddle
with your routers is necessary; allowing anyone else to do so
is foolhardy.
A router MUST NOT have undocumented back door access and master
passwords. A vendor MUST ensure any such access added for
purposes of debugging or product development are deleted before
the product is distributed to its customers.
DISCUSSION:
A vendor has a responsibility to its customers to ensure they
are aware of the vulnerabilities present in its code by
intention - e.g. in-band access. Trap doors, back doors and
master passwords intentional or unintentional can turn a
relatively secure router into a major problem on an operational
network. The supposed operational benefits are not matched by
the potential problems.
11. REFERENCES
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 RFChas not been updated or superseded by
another, more recent RFC. Reference [INTRO:6] explains various ways to
obtain a current RFCindex.
APPL:1.
B. Croft and J. Gilmore, Bootstrap Protocol (BOOTP), Request For
Comments (RFC) 951, Stanford and SUN Microsystems, September 1985.
APPL:2.
S. Alexander and R. Droms, DHCP Options and BOOTP Vendor
Extensions, Request For Comments (RFC) 1533, Lachman Technology,
Inc., Bucknell University, October 1993.
APPL:3.
W. Wimer, Clarifications and Extensions for the Bootstrap Protocol,
Request For Comments (RFC) 1542, Carnegie Mellon University,
October 1993.
ARCH:1.
DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three
volumes), DDN Network Information Center, SRI International, Menlo
Park, California, USA, December 1985.
ARCH:2.
V. Cerf and R. Kahn, A Protocol for Packet Network
Intercommunication," IEEE Transactions on Communication, May 1974.
Also included in [ARCH:1].
ARCH:3.
J. Postel, C. Sunshine, and D. Cohen, The ARPA Internet Protocol,"
Computer Networks, vol. 5, no. 4, July 1981. Also included in
[ARCH:1].
ARCH:4.
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.
ARCH:5.
D. Comer, Internetworking With TCP/IP Volume 1: Principles,
Protocols, and Architecture, Prentice Hall, Englewood Cliffs, NJ,
1991.
ARCH:6.
W. Stallings, Handbook of Computer-Communications Standards Volume
3: The TCP/IP Protocol Suite, Macmillan, New York, NY, 1990.
ARCH:7.
J. Postel, Internet Official Protocol Standards, Request For
Comments (RFC) 1610, STD 1, USC/Information Sciences Institute,
July 1994.
ARCH:8.
Information processing systems - Open Systems Interconnection -
Basic Reference Model, ISO 7489, International Standards
Organization, 1984.
FORWARD:1.
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.
FORWARD:2.
A. Mankin and K. Ramakrishnan, Editors, Gateway Congestion Control
Survey, Request For Comments (RFC) 1254, MITRE, Digital Equipment
Corporation, August 1991.
FORWARD:3.
J. Nagle, On Packet Switches with Infinite Storage, IEEE
Transactions on Communications, vol. COM-35, no. 4, April 1987.
FORWARD:4.
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.
FORWARD:5.
V. Jacobson, Congestion Avoidance and Control, Proceedings of
SIGCOMM '88, Association for Computing Machinery, August 1988.
FORWARD:6.
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.
INTERNET:1.
J. Postel, Internet Protocol, Request For Comments (RFC) 791, STD
5, USC/Information Sciences Institute, September 1981.
INTERNET:2.
J. Mogul and J. Postel, Internet Standard Subnetting Procedure,
Request For Comments (RFC) 950, STD 5, USC/Information Sciences
Institute, August 1985.
INTERNET:3.
J. Mogul, Broadcasting Internet Datagrams in the Presence of
Subnets, Request For Comments (RFC) 922, STD 5, Stanford, October
1984.
INTERNET:4.
S. Deering, Host Extensions for IP Multicasting, Request For
Comments (RFC) 1112, STD 5, Stanford University, August 1989.
INTERNET:5.
S. Kent, U.S. Department of Defense Security Options for the
Internet Protocol, Request for Comments (RFC) 1108, BBN
Communications, November 1991.
INTERNET:6.
R. Braden, D. Borman, and C. Partridge, Computing the Internet
Checksum, Request For Comments (RFC) 1071, USC/Information Sciences
Institute, Cray Researc, BBN, September 1988.
INTERNET:7.
T. Mallory and A. Kullberg, Incremental Updating of the Internet
Checksum, Request For Comments (RFC) 1141, BBN, January 1990.
INTERNET:8.
J. Postel, Internet Control Message Protocol, Request For Comments
(RFC) 792, STD 5, USC/Information Sciences Institute, September
1981.
INTERNET:9.
A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder,
and R. Zahavi, Evaluation of Internet Performance - FY89, Technical
Report MTR-89W00216, MITRE Corporation, February, 1990.
INTERNET:10.
G. Finn, A Connectionless Congestion Control Algorithm, Computer
Communications Review, vol. 19, no. 5, Association for Computing
Machinery, October 1989.
INTERNET:11.
W. Prue, J. Postel, The Source Quench Introduced Delay (SQuID),
Request For Comments (RFC) 1016, USC/Information Sciences
Institute, August 1987.
INTERNET:12.
A. McKenzie, Some comments on SQuID, Request For Comments (RFC)
1018, BBN, August 1987.
INTERNET:13.
S. Deering, ICMP Router Discovery Messages, Request For Comments
(RFC) 1256, Xerox PARC, September 1991.
INTERNET:14.
J. Mogul and S. Deering, Path MTU Discovery, Request For Comments
(RFC) 1191, DECWRL, Stanford University, November 1990.
INTERNET:15
V. Fuller, T. Li, J. Yi, and K. Varadhan, Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy
Request For Comments (RFC) 1519, BARRNet, cisco, Merit, OARnet,
September 1993.
INTERNET:16
M. St. Johns, Draft Revised IP Security Option, Request for
Comments 1038, IETF, January 1988.
INTERNET:17
W. Prue and J. Postel, Queuing Algorithm to Provide Type-of-service
For IP Links, Request for Comments 1046, USC/Information Sciences
Institute, February 1988.
INTRO:1.
R. Braden and J. Postel, Requirements for Internet Gateways,
Request For Comments (RFC) 1009, STD 4, USC/Information Sciences
Institute, June 1987.
INTRO:2.
Internet Engineering Task Force (R. Braden, Editor), Requirements
for Internet Hosts - Communication Layers, Request For Comments
(RFC) 1122, STD 3, USC/Information Sciences Institute, October
1989.
INTRO:3.
Internet Engineering Task Force (R. Braden, Editor), Requirements
for Internet Hosts - Application and Support, Request For Comments
(RFC) 1123, STD 3, USC/Information Sciences Institute, October
1989.
INTRO:4.
D. Clark, Modularity and Efficiency in Protocol Implementations,
Request For Comments (RFC) 817, MIT, July 1982.
INTRO:5.
D. Clark, The Structuring of Systems Using Upcalls, Proceedings of
10th ACM SOSP, December 1985.
INTRO:6.
O. Jacobsen and J. Postel, Protocol Document Order Information,
Request For Comments (RFC) 980, SRI, USC/Information Sciences
Institute, March 1986.
INTRO:7.
J. Reynolds and J. Postel, Assigned Numbers, Request For Comments
(RFC) 1700, STD 2, USC/Information Sciences Institute, October
1994. This document is periodically updated and reissued with a
new number. It is wise to verify occasionally that the version you
have is still current.
INTRO:8.
DoD Trusted Computer System Evaluation Criteria, DoD publication
5200.28-STD, U.S. Department of Defense, December 1985.
INTRO:9
G. Malkin and T. LaQuey Parker, Internet Users' Glossary, Request
for Comments (RFC) 1392 (also FYI 0018), Xylogics, Inc., UTexas,
January 1993.
LINK:1.
S. Leffler and M. Karels, Trailer Encapsulations, Request For
Comments (RFC) 893, U. C. Berkeley, April 1984.
LINK:2
W. Simpson, The Point-to-Point Protocol (PPP) for the Transmission
of Multi-protocol Datagrams over Point-to-Point Links, Daydreamer,
Request For Comments (RFC) 1331, May 1992.
LINK:3
G. McGregor, The PPP Internet Protocol Control Protocol (IPCP),
Request For Comments (RFC) 1332, Merit, May 1992.
LINK:4
B. Lloyd, W. Simpson, PPP Authentication Protocols, Request For
Comments (RFC) 1334, Daydreamer, May 1992.
LINK:5
W. Simpson, PPP Link Quality Monitoring, Daydreamer, Request For
Comments (RFC) 1333, May 1992.
MGT:1.
M. Rose and K. McCloghrie, Structure and Identification of
Management Information of TCP/IP-based Internets, Request For
Comments (RFC) 1155, STD 16, Performance Systems International,
Hughes LAN Systems, May 1990.
MGT:2.
K. McCloghrie and M. Rose (Editors), Management Information Base of
TCP/IP-Based Internets: MIB-II, Request For Comments (RFC) 1213,
STD 16, Hughes LAN Systems, Performance Systems International,
March 1991.
MGT:3.
J. Case, M. Fedor, M. Schoffstall, and J. Davin, Simple Network
Management Protocol, Request For Comments (RFC) 1157, STD 15, SNMP
Research, Performance Systems International, MIT Laboratory for
Computer Science, May 1990.
MGT:4.
M. Rose and K. McCloghrie (Editors), Towards Concise MIB
Definitions, Request For Comments (RFC) 1212, STD 16, Performance
Systems International, Hughes LAN Systems, March 1991.
MGT:5.
L. Steinberg, Techniques for Managing Asynchronously Generated
Alerts, Request for Comments (RFC) 1224, IBM, May 1991.
MGT:6.
F. Kastenholz, Definitions of Managed Objects for the Ethernet-like
Interface Types, Request for Comments (RFC) 1398, FTP Software
January 1993.
MGT:7.
R. Fox and K. McCloghrie, IEEE 802.4 Token Bus MIB, Request for
Comments (RFC) 1230, Hughes LAN Systems, Synoptics, Inc., May 1991.
MGT:8.
K. McCloghrie, R. Fox and E. Decker, IEEE 802.5 Token Ring MIB,
Request for Comments (RFC) 1231, Hughes LAN Systems, Synoptics,
Inc., cisco Systems, Inc., February 1993.
MGT:9.
J. Case and A. Rijsinghani, FDDI Management Information Base,
Request for Comments (RFC) 1512, SNMP Research, Digital Equipment
Corporation, September 1993.
MGT:10.
B. Stewart, Definitions of Managed Objects for RS-232-like Hardware
Devices, Request for Comments (RFC) 1317, Xyplex, Inc., April 1992.
MGT:11.
F. Kastenholz, Definitions of Managed Objects for the Link Control
Protocol of the Point-to-Point Protocol, Request For Comments (RFC)
1471, FTP Software, June 1992.
MGT:12.
F. Kastenholz, The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol, Request For Comments
(RFC) 1472, FTP Software, June 1992.
MGT:13.
F. Kastenholz, The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point Protocol, Request
For Comments (RFC) 1473, FTP Software, June 1992.
MGT:14.
F. Baker and R. Coltun, OSPF Version 2 Management Information Base,
Request For Comments (RFC) 1253, ACC, Computer Science Center,
August 1991.
MGT:15.
S. Willis and J. Burruss, Definitions of Managed Objects for the
Border Gateway Protocol (Version 3), Request For Comments (RFC)
1269, Wellfleet Communications Inc., October 1991.
MGT:16.
F. Baker, J. Watt, Definitions of Managed Objects for the DS1 and
E1 Interface Types, Request For Comments (RFC) 1406, Advanced
Computer Communications, Newbridge Networks Corporation, January
1993.
MGT:17.
T. Cox and K. Tesink, Definitions of Managed Objects for the DS3/E3
Interface Types, Request For Comments (RFC) 1407, Bell
Communications Research, January 1993.
MGT:18.
K. McCloghrie, Extensions to the Generic-Interface MIB, Request For
Comments (RFC) 1229, Hughes LAN Systems, August 1992.
MGT:19.
T. Cox and K. Tesink, Definitions of Managed Objects for the SIP
Interface Type, Request For Comments (RFC) 1304, Bell
Communications Research, February 1992.
MGT:20
F. Baker, IP Forwarding Table MIB, Request For Comments (RFC) 1354,
ACC, July 1992.
MGT:21.
G. Malkin and F. Baker, RIP Version 2 MIB Extension, Request For
Comments (RFC) 1389, Xylogics, Inc., Advanced Computer
Communications, January 1993.
MGT:22.
D. Throop, SNMP MIB Extension for the X.25 Packet Layer, Request
For Comments (RFC) 1382, Data General Corporation, November 1992.
MGT:23.
D. Throop and F. Baker, SNMP MIB Extension for X.25 LAPB, Request
For Comments (RFC) 1381, Data General Corporation, Advanced
Computer Communications, November 1992.
MGT:24.
D. Throop and F. Baker, SNMP MIB Extension for MultiProtocol
Interconnect over X.25, Request For Comments (RFC) 1461, Data
General Corporation, May 1993.
MGT:25.
M. Rose, SNMP over OSI, Request For Comments (RFC) 1418, Dover
Beach Consulting, Inc., March 1993.
MGT:26.
G. Minshall and M. Ritter, SNMP over AppleTalk, Request For
Comments (RFC) 1419, Novell, Inc., Apple Computer, Inc., March
1993.
MGT:27.
S. Bostock, SNMP over IPX, Request For Comments (RFC) 1420, Novell,
Inc., March 1993.
MGT:28.
M. Schoffstall, C. Davin, M. Fedor, J. Case, SNMP over Ethernet,
Request For Comments (RFC) 1089, Rensselaer Polytechnic Institute,
MIT Laboratory for Computer Science, NYSERNet, Inc., University of
Tennessee at Knoxville, February 1989.
MGT:29.
J. Case, FDDI Management Information Base, Request For Comments
(RFC) 1285, SNMP Research, Incorporated, January 1992.
OPER:1.
J. Nagle, Congestion Control in IP/TCP Internetworks, Request For
Comments (RFC) 896, FACC, January 1984.
OPER:2.
K.R. Sollins, TFTP Protocol (revision 2), Request For Comments
(RFC) 1350, MIT, July 1992.
ROUTE:1.
J. Moy, OSPF Version 2, Request For Comments (RFC) 1247, Proteon,
July 1991.
ROUTE:2.
R. Callon, Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments, Request For Comments (RFC) 1195, DEC, December 1990.
ROUTE:3.
C. L. Hedrick, Routing Information Protocol, Request For Comments
(RFC) 1058, Rutgers University, June 1988.
ROUTE:4.
K. Lougheed and Y. Rekhter, A Border Gateway Protocol 3 (BGP-3),
Request For Comments (RFC) 1267, cisco, T.J. Watson Research
Center, IBM Corp., October 1991.
ROUTE:5.
Y. Rekhter and P. Gross Application of the Border Gateway Protocol
in the Internet, Request For Comments (RFC) 1268, T.J. Watson
Research Center, IBM Corp., ANS, October 1991.
ROUTE:6.
D. Mills, Exterior Gateway Protocol Formal Specification, Request
For Comments (RFC) 904, UDEL, April 1984.
ROUTE:7.
E. Rosen, Exterior Gateway Protocol (EGP), Request For Comments
(RFC) 827, BBN, October 1982.
ROUTE:8.
L. Seamonson and E. Rosen, "STUB" Exterior Gateway Protocol,
Request For Comments (RFC) 888, BBN, January 1984.
ROUTE:9.
D. Waitzman, C. Partridge, and S. Deering, Distance Vector
Multicast Routing Protocol, Request For Comments (RFC) 1075, BBN,
Stanford, November 1988.
ROUTE:10.
S. Deering, Multicast Routing in Internetworks and Extended LANs,
Proceedings of SIGCOMM '88, Association for Computing Machinery,
August 1988.
ROUTE:11.
P. Almquist, Type of Service in the Internet Protocol Suite,
Request for Comments (RFC) 1349, Consultant, July 1992.
ROUTE:12.
Y. Rekhter, Experience with the BGP Protocol, Request For Comments
(RFC) 1266, T.J. Watson Research Center, IBM Corp., October 1991.
ROUTE:13.
Y. Rekhter, BGP Protocol Analysis, Request For Comments (RFC) 1265,
T.J. Watson Research Center, IBM Corp., October 1991.
TRANS:1.
J. Postel, User Datagram Protocol, Request For Comments (RFC) 768,
STD 6, USC/Information Sciences Institute, August 1980.
TRANS:2.
J. Postel, Transmission Control Protocol, Request For Comments
(RFC) 793, STD 7, T.J. Watson Research Center, IBM Corp., September
1981.
APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS
Subject to restrictions given below, a host MAY be able to act as an
intermediate hop in a source route, forwarding a source-routed datagram
to the next specified hop.
However, in performing this router-like function, the host MUST obey all
the relevant rules for a router forwarding source-routed datagrams
[INTRO:2]. This includes the following specific provisions:
(A) TTL
The TTL field MUST be decremented and the datagram perhaps
discarded as specified for a router in [INTRO:2].
(B) ICMP Destination Unreachable
A host MUST be able to generate Destination Unreachable messages
with the following codes:
4 (Fragmentation Required but DF Set) when a source-routed datagram
cannot be fragmented to fit into the target network;
5 (Source Route Failed) when a source-routed datagram cannot be
forwarded, e.g., because of a routing problem or because the next
hop of a strict source route is not on a connected network.
(C) IP Source Address
A source-routed datagram being forwarded MAY (and normally will)
have a source address that is not one of the IP addresses of the
forwarding host.
(D) Record Route Option
A host that is forwarding a source-routed datagram containing a
Record Route option MUST update that option, if it has room.
(E) Timestamp Option
A host that is forwarding a source-routed datagram containing a
Timestamp Option MUST add the current timestamp to that option,
according to the rules for this option.
To define the rules restricting host forwarding of source-routed
datagrams, we use the term local source-routing if the next hop will be
through the same physical interface through which the datagram arrived;
otherwise, it is non-local source-routing.
A host is permitted to perform local source-routing without restriction.
A host that supports non-local source-routing MUST have a configurable
switch to disable forwarding, and this switch MUST default to disabled.
The host MUST satisfy all router requirements for configurable policy
filters [INTRO:2] restricting non-local forwarding.
If a host receives a datagram with an incomplete source route but does
not forward it for some reason, the host SHOULD return an ICMP
Destination Unreachable (code 5, Source Route Failed) message, unless
the datagram was itself an ICMP error message.
APPENDIX B. GLOSSARY
This Appendix defines specific terms used in this memo. It also defines
some general purpose terms that may be of interest. See also [INTRO:9]
for a more general set of definitions.
AS
Autonomous System A collection of routers under a single
administrative authority using a common Interior Gateway Protocol
for routing packets.
Connected Network
A network to which a router is interfaced is often known as the
local network or the subnetwork relative to that router. However,
these terms can cause confusion, and therefore we use the term
Connected Network in this memo.
Connected (Sub)Network
A Connected (Sub)Network is an IP subnetwork to which a router is
interfaced, or a connected network if the connected network is not
subnetted. See also Connected Network.
Datagram
The unit transmitted between a pair of internet modules. data,
called datagrams, from sources to destinations. The Internet
Protocol does not provide a reliable communication facility. There
are no acknowledgments either end-to-end or hop-by-hop. There is
no error no retransmissions. There is no flow control. See IP.
Default Route
A routing table entry which is used to direct any data addressed to
any network numbers not explicitly listed in the routing table.
EGP
Exterior Gateway Protocol A protocol which distributes routing
information to the gateways (routers) which connect autonomous
systems. See IGP.
EGP-2
Exterior Gateway Protocol version 2 This is an EGP routing protocol
developed to handle traffic between AS's in the Internet.
Forwarder
The logical entity within a router that is responsible for
switching packets among the router's interfaces. The Forwarder
also makes the decisions to queue a packet for local delivery, to
queue a packet for transmission out another interface, or both.
Forwarding
Forwarding is the process a router goes through for each packet
received by the router. The packet may be consumed by the router,
it may be output on one or more interfaces of the router, or both.
Forwarding includes the process of deciding what to do with the
packet as well as queuing it up for (possible) output or internal
consumption.
Fragment
An IP datagram which represents a portion of a higher layer's
packet which was too large to be sent in its entirety over the
output network.
IGP
Interior Gateway Protocol A protocol which distributes routing
information with an Autonomous System (AS). See EGP.
Interface IP Address
The IP Address and subnet mask that is assigned to a specific
interface of a router.
Internet Address
An assigned number which identifies a host in an internet. It has
two or three parts: network number, optional subnet number, and
host number.
IP
Internet Protocol The network layer protocol for the Internet. It
is a packet switching, datagram protocol defined in RFC791. IP
does not provide a reliable communications facility; that is, there
are no end-to-end of hop-by-hop acknowledgments.
IP Datagram
An IP Datagram is the unit of end-to-end transmission in the
Internet Protocol. An IP Datagram consists of an IP header
followed by all of higher-layer data (such as TCP, UDP, ICMP, and
the like). An IP Datagram is an IP header followed by a message.
An IP Datagram is a complete IP end-to-end transmission unit. An
IP Datagram is composed of one or more IP Fragments.
In this memo, the unqualified term Datagram should be understood to
refer to an IP Datagram.
IP Fragment
An IP Fragment is a component of an IP Datagram. An IP Fragment
consists of an IP header followed by all or part of the higher-
layer of the original IP Datagram.
One or more IP Fragments comprises a single IP Datagram.
In this memo, the unqualified term Fragment should be understood to
refer to an IP Fragment.
IP Packet
An IP Datagram or an IP Fragment.
In this memo, the unqualified term Packet should generally be
understood to refer to an IP Packet.
Logical [network] interface
We define a logical [network] interface to be a logical path,
distinguished by a unique IP address, to a connected network.
Martian Filtering
A packet which contains an invalid source or destination address is
considered to be martian and discarded.
MTU (Maximum Transmission Unit)
The size of the largest packet that can be transmitted or received
through a logical interface. This size includes the IP header but
does not include the size of any Link Layer headers or framing.
Multicast
A packet which is destined for multiple hosts. See broadcast.
Multicast Address
A special type of address which is recognized by multiple hosts.
A Multicast Address is sometimes known as a Functional Address or a
Group Address.
Originate
Packets can be transmitted by a router for one of two reasons: 1)
the packet was received and is being forwarded or 2) the router
itself created the packet for transmission (such as route
advertisements). Packets that the router creates for transmission
are said to originate at the router.
Packet
A packet is the unit of data passed across the interface between
the Internet Layer and the Link Layer. It includes an IP header
and data. A packet may be a complete IP datagram or a fragment of
an IP datagram.
Path
The sequence of routers and (sub-)networks which a packet traverses
from a particular router to a particular destination host. Note
that a path is uni-directional; it is not unusual to have different
paths in the two directions between a given host pair.
Physical Network
A Physical Network is a network (or a piece of an internet) which
is contiguous at the Link Layer. Its internal structure (if any)
is transparent to the Internet Layer.
In this memo, several media components that are connected together
via devices such as bridges or repeaters are considered to be a
single Physical Network since such devices are transparent to the
IP.
Physical Network Interface
This is a physical interface to a Connected Network and has a
(possibly unique) Link-Layer address. Multiple Physical Network
Interfaces on a single router may share the same Link-Layer
address, but the address must be unique for different routers on
the same Physical Network.
router
A special-purpose dedicated computer that attaches several networks
together. Routers switch packets between these networks in a
process known as forwarding. This process may be repeated several
times on a single packet by multiple routers until the packet can
be delivered to the final destination - switching the packet from
router to router to router... until the packet gets to its
destination.
RPF
Reverse Path Forwarding A method used to deduce the next hops for
broadcast and multicast packets.
serial line
A physical medium which we cannot define, but we recognize one when
we see one. See the U.S. Supreme Court's definitions on
pornography.
Silently Discard
This memo specifies several cases where a router is to Silently
Discard a received packet (or datagram). This means that the
router should discard the packet without further processing, and
that the router will not send any ICMP error message (see Section
[4.3.2]) as a result. However, for diagnosis of problems, the
router should provide the capability of logging the error (see
Section [1.3.3]), including the contents of the silently-discarded
packet, and should record the event in a statistics counter.
Silently Ignore
A router is said to Silently Ignore an error or condition if it
takes no action other than possibly generating an error report in
an error log or via some network management protocol, and
discarding, or ignoring, the source of the error. In particular,
the router does NOT generate an ICMP error message.
Specific-destination address
This is defined to be the destination address in the IP header
unless the header contains an IP broadcast or IP multicast address,
in which case the specific-destination is an IP address assigned to
the physical interface on which the packet arrived.
subnet
A portion of a network, which may be a physically independent
network, which shares a network address with other portions of the
network and is distinguished by a subnet number. A subnet is to a
network what a network is to an internet.
subnet number
A part of the internet address which designates a subnet. It is
ignored for the purposes internet routing, but is used for intranet
routing.
TOS
Type Of Service A field in the IP header which represents the
degree of reliability expected from the network layer by the
transport layer or application.
TTL
Time To Live A field in the IP header which represents how long a
packet is considered valid. It is a combination hop count and
timer value.
APPENDIX C. FUTURE DIRECTIONS
This appendix lists work that future revisions of this document may wish
to address.
In the preparation of Router Requirements, we stumbled across several
other architectural issues. Each of these is dealt with somewhat in the
document, but still ought to be classified as an open issue in the IP
architecture.
Most of the he topics presented here generally indicate areas where the
technology is still relatively new and it is not appropriate to develop
specific requirements since the community is still gaining operational
experience.
Other topics represent areas of ongoing research and indicate areas that
the prudent developer would closely monitor.
(1) SNMP Version 2
(2) Additional SNMP MIBs
(3) IDPR
(4) CIPSO
(5) IP Next Generation research
(6) More detailed requirements for next-hop selection
(7) More detailed requirements for leaking routes between routing
protocols
(8) Router system security
(9) Routing protocol security
(10) Internetwork Protocol layer security. There has been extensive
work refining the security of IP since the original work writing
this document. This security work should be included in here.
(11) Route caching
(12) Load Splitting
(13) Sending fragments along different paths
(14) Variable width subnet masks (i.e., not all subnets of a particular
net use the same subnet mask). Routers are required (MUST) support
them, but are not required to detect ambiguous configurations.
(15) Multiple logical (sub)nets on the same wire. Router Requirements
does not require support for this. We made some attempt to
identify pieces of the architecture (e.g. forwarding of directed
broadcasts and issuing of Redirects) where the wording of the rules
has to be done carefully to make the right thing happen, and tried
to clearly distinguish logical interfaces from physical interfaces.
However, we did not study this issue in detail, and we are not at
all confident that all of the rules in the document are correct in
the presence of multiple logical (sub)nets on the same wire.
(15) Congestion control and resource management. On the advice of the
IETF's experts (Mankin and Ramakrishnan) we deprecated (SHOULD NOT)
Source Quench and said little else concrete (Section 5.3.6).
(16) Developing a Link-Layer requirements document that would be common
for both routers and hosts.
(17) Developing a common PPP LQM algorithm.
(18) Investigate of other information (above and beyond section [3.2])
that passes between the layers, such as physical network MTU,
mappings of IP precedence to Link Layer priority values, etc.
(19) Should the Link Layer notify IP if address resolution failed (just
like it notifies IP when there is a Link Layer priority value
problem)?
(20) Should all routers be required to implement a DNS resolver?
(21) Should a human user be able to use a host name anywhere you can use
an IP address when configuring the router? Even in ping and
traceroute?
(22) Almquist's draft ruminations on the next hop and ruminations on
route leaking need to be reviewed, brought up to date, and
published.
(23) Investigation is needed to determine if a redirect message for
precedence is needed or not. If not, are the type-of-service
redirects acceptable?
(24) RIPv2 and RIP+CIDR and variable length subnet masks.
(25) BGP-4 CIDR is going to be important, and everyone is betting on
BGP-4. We can't avoid mentioning it. Probably need to describe the
differences between BGP-3 and BGP-4, and explore upgrade issues...
(26) Loose Source Route Mobile IP and some multicasting may require
this. Perhaps it should be elevated to a SHOULD (per Fred Baker's
Suggestion).
APPENDIX D. Multicast Routing Protocols
Multicasting is a relatively new technology within the Internet Protocol
family. It is not widely deployed or commonly in use yet. Its
importance, however, is expected to grow over the coming years.
This Appendix describes some of the technologies being investigated for
routing multicasts through the Internet.
A diligent implementor will keep abreast of developments in this area in
order to properly develop multicast facilities.
This Appendix does not specify any standards or requirements.
D.1 Introduction
Multicast routing protocols enable the forwarding of IP multicast
datagrams throughout a TCP/IP internet. Generally these algorithms
forward the datagram based on its source and destination addresses.
Additionally, the datagram may need to be forwarded to several
multicast group members, at times requiring the datagram to be
replicated and sent out multiple interfaces.
The state of multicast routing protocols is less developed than the
protocols available for the forwarding of IP unicasts. Two multicast
routing protocols have been documented for TCP/IP; both are currently
considered to be experimental. Both also use the IGMP protocol