RFC 1716
Towards Requirements for IP Routers
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 RFC 791. 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 (discussed in Section [4.4]) to monitor multicast group membership. D.2 Distance Vector Multicast Routing Protocol - DVMRP DVMRP, documented in [ROUTE:9], is based on Distance Vector or Bellman-Ford technology. It routes multicast datagrams only, and does so within a single Autonomous System. DVMRP is an implementation of the Truncated Reverse Path Broadcasting algorithm described in [ROUTE:10]. In addition, it specifies the tunneling of IP multicasts through non-multicast-routing-capable IP domains.
D.3 Multicast Extensions to OSPF - MOSPF MOSPF, currently under development, is a backward-compatible addition to OSPF that allows the forwarding of both IP multicasts and unicasts within an Autonomous System. MOSPF routers can be mixed with OSPF routers within a routing domain, and they will interoperate in the forwarding of unicasts. OSPF is a link-state or SPF-based protocol. By adding link state advertisements that pinpoint group membership, MOSPF routers can calculate the path of a multicast datagram as a tree rooted at the datagram source. Those branches that do not contain group members can then be discarded, eliminating unnecessary datagram forwarding hops.
APPENDIX E Additional Next-Hop Selection Algorithms Section [5.2.4.3] specifies an algorithm that routers ought to use when selecting a next-hop for a packet. This appendix provides historical perspective for the next-hop selection problem. It also presents several additional pruning rules and next-hop selection algorithms that might be found in the Internet. This appendix presents material drawn from an earlier, unpublished, work by Philip Almquist; Ruminations on the Next Hop. This Appendix does not specify any standards or requirements. E.1. Some Historical Perspective It is useful to briefly review the history of the topic, beginning with what is sometimes called the "classic model" of how a router makes routing decisions. This model predates IP. In this model, a router speaks some single routing protocol such as RIP. The protocol completely determines the contents of the router's FIB. The route lookup algorithm is trivial: the router looks in the FIB for a route whose destination attribute exactly matches the network number portion of the destination address in the packet. If one is found, it is used; if none is found, the destination is unreachable. Because the routing protocol keeps at most one route to each destination, the problem of what to do when there are multiple routes which match the same destination cannot arise. Over the years, this classic model has been augmented in small ways. With the advent of default routes, subnets, and host routes, it became possible to have more than one routing table entry which in some sense matched the destination. This was easily resolved by a consensus that there was a hierarchy of routes: host routes should be preferred over subnet routes, subnet routes over net routes, and net routes over default routes. With the advent of variable length subnet masks, the general approach remained the same although its description became a little more complicated. We now say that each route has a bit mask associated with it. If a particular bit in a route's bit mask is set, the corresponding bit in the route's destination attribute is significant. A route cannot be used to route a packet unless each significant bit in the route's destination attribute matches the corresponding bit in the packet's destination address, and routes with more bits set in their masks are preferred over routes which have fewer bits set in their masks. This is simply a generalization
of the hierarchy of routes described above, and will be referred to for the rest of this memo as choosing a route by preferring longest match. Another way the classic model has been augmented is through a small amount of relaxation of the notion that a routing protocol has complete control over the contents of the routing table. First, static routes were introduced. For the first time, it was possible to simultaneously have two routes (one dynamic and one static) to the same destination. When this happened, a router had to have a policy (in some cases configurable, and in other cases chosen by the author of the router's software) which determined whether the static route or the dynamic route was preferred. However, this policy was only used as a tie-breaker when longest match didn't uniquely determine which route to use. Thus, for example, a static default route would never be preferred over a dynamic net route even if the policy preferred static routes over dynamic routes. The classic model had to be further augmented when inter-domain routing protocols were invented. Traditional routing protocols came to be called "interior gateway protocols" (IGPs), and at each Internet site there was a strange new beast called an "exterior gateway", a router which spoke EGP to several "BBN Core Gateways" (the routers which made up the Internet backbone at the time) at the same time as it spoke its IGP to the other routers at its site. Both protocols wanted to determine the contents of the router's routing table. Theoretically, this could result in a router having three routes (EGP, IGP, and static) to the same destination. Because of the Internet topology at the time, it was resolved with little debate that routers would be best served by a policy of preferring IGP routes over EGP routes. However, the sanctity of longest match remained unquestioned: a default route learned from the IGP would never be preferred over a net route from learned EGP. Although the Internet topology, and consequently routing in the Internet, have evolved considerably since then, this slightly augmented version of the classic model has survived pretty much intact to this day in the Internet (except that BGP has replaced EGP). Conceptually (and often in implementation) each router has a routing table and one or more routing protocol processes. Each of these processes can add any entry that it pleases, and can delete or modify any entry that it has created. When routing a packet, the router picks the best route using longest match, augmented with a policy mechanism to break ties. Although this augmented classic model has served us well, it has a number of shortcomings: o It ignores (although it could be augmented to consider) path
characteristics such as quality of service and MTU.
o It doesn't support routing protocols (such as OSPF and Integrated
IS-IS) that require route lookup algorithms different than pure
longest match.
o There has not been a firm consensus on what the tie-breaking
mechanism ought to be. Tie-breaking mechanisms have often been
found to be difficult if not impossible to configure in such a way
that the router will always pick what the network manger considers
to be the "correct" route.
E.2. Additional Pruning Rules
Section [5.2.4.3] defined several pruning rules to use to select
routes from the FIB. There are other rules that could also be used.
o OSPF Route Class
Routing protocols which have areas or make a distinction between
internal and external routes divide their routes into classes,
where classes are rank-ordered in terms of preference. A route is
always chosen from the most preferred class unless none is
available, in which case one is chosen from the second most
preferred class, and so on. In OSPF, the classes (in order from
most preferred to least preferred) are intra-area, inter-area,
type 1 external (external routes with internal metrics), and type
2 external. As an additional wrinkle, a router is configured to
know what addresses ought to be accessible via intra-area routes,
and will not use inter- area or external routes to reach these
destinations even when no intra-area route is available.
More precisely, we assume that each route has a class attribute,
called route.class, which is assigned by the routing protocol.
The set of candidate routes is examined to determine if it
contains any for which route.class = intra-area. If so, all
routes except those for which route.class = intra-area are
discarded. Otherwise, router checks whether the packet's
destination falls within the address ranges configured for the
local area. If so, the entire set of candidate routes is deleted.
Otherwise, the set of candidate routes is examined to determine if
it contains any for which route.class = inter-area. If so, all
routes except those for which route.class = inter-area are
discarded. Otherwise, the set of candidate routes is examined to
determine if it contains any for which route.class = type 1
external. If so, all routes except those for which route.class =
type 1 external are discarded.
o IS-IS Route Class
IS-IS route classes work identically to OSPF's. However, the set
of classes defined by Integrated IS-IS is different, such that
there isn't a one-to-one mapping between IS-IS route classes and
OSPF route classes. The route classes used by Integrated IS-IS are
(in order from most preferred to least preferred) intra-area,
inter-area, and external.
The Integrated IS-IS internal class is equivalent to the OSPF
internal class. Likewise, the Integrated IS-IS external class is
equivalent to OSPF's type 2 external class. However, Integrated
IS-IS does not make a distinction between inter-area routes and
external routes with internal metrics - both are considered to be
inter-area routes. Thus, OSPF prefers true inter-area routes over
external routes with internal metrics, whereas Integrated IS-IS
gives the two types of routes equal preference.
o IDPR Policy
A specific case of Policy. The IETF's Inter-domain Policy Routing
Working Group is devising a routing protocol called Inter-Domain
Policy Routing (IDPR) to support true policy-based routing in the
Internet. Packets with certain combinations of header attributes
(such as specific combinations of source and destination addresses
or special IDPR source route options) are required to use routes
provided by the IDPR protocol. Thus, unlike other Policy pruning
rules, IDPR Policy would have to be applied before any other
pruning rules except Basic Match.
Specifically, IDPR Policy examines the packet being forwarded to
ascertain if its attributes require that it be forwarded using
policy-based routes. If so, IDPR Policy deletes all routes not
provided by the IDPR protocol.
E.3 Some Route Lookup Algorithms
This section examines several route lookup algorithms that are in use
or have been proposed. Each is described by giving the sequence of
pruning rules it uses. The strengths and weaknesses of each
algorithm are presented
E.3.1 The Revised Classic Algorithm
The Revised Classic Algorithm is the form of the traditional
algorithm which was discussed in Section [E.1]. The steps of this
algorithm are:
1. Basic match
2. Longest match
3. Best metric
4. Policy
Some implementations omit the Policy step, since it is needed only
when routes may have metrics that are not comparable (because they
were learned from different routing domains).
The advantages of this algorithm are:
(1) It is widely implemented.
(2) Except for the Policy step (which an implementor can choose
to make arbitrarily complex) the algorithm is simple both to
understand and to implement.
Its disadvantages are:
(1) It does not handle IS-IS or OSPF route classes, and therefore
cannot be used for Integrated IS-IS or OSPF.
(2) It does not handle TOS or other path attributes.
(3) The policy mechanisms are not standardized in any way, and
are therefore are often implementation-specific. This causes
extra work for implementors (who must invent appropriate
policy mechanisms) and for users (who must learn how to use
the mechanisms. This lack of a standardized mechanism also
makes it difficult to build consistent configurations for
routers from different vendors. This presents a significant
practical deterrent to multi-vendor interoperability.
(4) The proprietary policy mechanisms currently provided by
vendors are often inadequate in complex parts of the
Internet.
(5) The algorithm has not been written down in any generally
available document or standard. It is, in effect, a part of
the Internet Folklore.
E.3.2 The Variant Router Requirements Algorithm
Some Router Requirements Working Group members have proposed a
slight variant of the algorithm described in the Section
[5.2.4.3]. In this variant, matching the type of service
requested is considered to be more important, rather than less
important, than matching as much of the destination address as
possible. For example, this algorithm would prefer a default
route which had the correct type of service over a network route
which had the default type of service, whereas the algorithm in
[5.2.4.3] would make the opposite choice.
The steps of the algorithm are:
1. Basic match
2. Weak TOS
3. Longest match
4. Best metric
5. Policy
Debate between the proponents of this algorithm and the regular
Router Requirements Algorithm suggests that each side can show
cases where its algorithm leads to simpler, more intuitive routing
than the other's algorithm does. In general, this variant has the
same set of advantages and disadvantages that the algorithm
specified in [5.2.4.3] does, except that pruning on Weak TOS
before pruning on Longest Match makes this algorithm less
compatible with OSPF and Integrated IS-IS than the standard Router
Requirements Algorithm.
E.3.3 The OSPF Algorithm
OSPF uses an algorithm which is virtually identical to the Router
Requirements Algorithm except for one crucial difference: OSPF
considers OSPF route classes.
The algorithm is:
1. Basic match
2. OSPF route class
3. Longest match
4. Weak TOS
5. Best metric
6. Policy
Type of service support is not always present. If it is not
present then, of course, the fourth step would be omitted
This algorithm has some advantages over the Revised Classic
Algorithm:
(1) It supports type of service routing.
(2) Its rules are written down, rather than merely being a part
of the Internet folklore.
(3) It (obviously) works with OSPF.
However, this algorithm also retains some of the disadvantages of
the Revised Classic Algorithm:
(1) Path properties other than type of service (e.g. MTU) are
ignored.
(2) As in the Revised Classic Algorithm, the details (or even the
existence) of the Policy step are left to the discretion of
the implementor.
The OSPF Algorithm also has a further disadvantage (which is not
shared by the Revised Classic Algorithm). OSPF internal (intra-
area or inter-area) routes are always considered to be superior to
routes learned from other routing protocols, even in cases where
the OSPF route matches fewer bits of the destination address.
This is a policy decision that is inappropriate in some networks.
Finally, it is worth noting that the OSPF Algorithm's TOS support
suffers from a deficiency in that routing protocols which support
TOS are implicitly preferred when forwarding packets which have
non-zero TOS values. This may not be appropriate in some cases.
E.3.4 The Integrated IS-IS Algorithm
Integrated IS-IS uses an algorithm which is similar to but not
quite identical to the OSPF Algorithm. Integrated IS-IS uses a
different set of route classes, and also differs slightly in its
handling of type of service. The algorithm is:
1. Basic Match
2. IS-IS Route Classes
3. Longest Match
4. Weak TOS
5. Best Metric
6. Policy
Although Integrated IS-IS uses Weak TOS, the protocol is only
capable of carrying routes for a small specific subset of the
possible values for the TOS field in the IP header. Packets
containing other values in the TOS field are routed using the
default TOS.
Type of service support is optional; if disabled, the fourth step
would be omitted. As in OSPF, the specification does not include
the Policy step.
This algorithm has some advantages over the Revised Classic
Algorithm:
(1) It supports type of service routing.
(2) Its rules are written down, rather than merely being a part
of the Internet folklore.
(3) It (obviously) works with Integrated IS-IS.
However, this algorithm also retains some of the disadvantages of
the Revised Classic Algorithm:
(1) Path properties other than type of service (e.g. MTU) are
ignored.
(2) As in the Revised Classic Algorithm, the details (or even the
existence) of the Policy step are left to the discretion of
the implementor.
(3) It doesn't work with OSPF because of the differences between
IS-IS route classes and OSPF route classes. Also, because
IS-IS supports only a subset of the possible TOS values, some
obvious implementations of the Integrated IS-IS algorithm
would not support OSPF's interpretation of TOS.
The Integrated IS-IS Algorithm also has a further disadvantage
(which is not shared by the Revised Classic Algorithm): IS-IS
internal (intra-area or inter-area) routes are always considered
to be superior to routes learned from other routing protocols,
even in cases where the IS-IS route matches fewer bits of the
destination address and doesn't provide the requested type of
service. This is a policy decision that may not be appropriate in
all cases.
Finally, it is worth noting that the Integrated IS-IS Algorithm's
TOS support suffers from the same deficiency noted for the OSPF
Algorithm.
Security Considerations
Although the focus of this document is interoperability rather than
security, there are obviously many sections of this document which have
some ramifications on network security.
Security means different things to different people. Security from a
router's point of view is anything that helps to keep its own networks
operational and in addition helps to keep the Internet as a whole
healthy. For the purposes of this document, the security services we
are concerned with are denial of service, integrity, and authentication
as it applies to the first two. Privacy as a security service is
important, but only peripherally a concern of a router - at least as of
the date of this document.
In several places in this document there are sections entitled ...
Security Considerations. These sections discuss specific considerations
that apply to the general topic under discussion.
Rarely does this document say do this and your router/network will be
secure. More likely, it says this is a good idea and if you do it, it
*may* improve the security of the Internet and your local system in
general.
Unfortunately, this is the state-of-the-art AT THIS TIME. Few if any of
the network protocols a router is concerned with have reasonable,
built-in security features. Industry and the protocol designers have
been and are continuing to struggle with these issues. There is
progress, but only small baby steps such as the peer-to-peer
authentication available in the BGP and OSPF routing protocols.
In particular, this document notes the current research into developing
and enhancing network security. Specific areas of research,
development, and engineering that are underway as of this writing
(December 1993) are in IP Security, SNMP Security, and common
authentication technologies.
Notwithstanding all of the above, there are things both vendors and
users can do to improve the security of their router. Vendors should
get a copy of Trusted Computer System Interpretation [INTRO:8]. Even if
a vendor decides not to submit their device for formal verification
under these guidelines, the publication provides excellent guidance on
general security design and practices for computing devices.
Acknowledgments
O that we now had here
But one ten thousand of those men in England
That do no work to-day!
What's he that wishes so?
My cousin Westmoreland? No, my fair cousin:
If we are mark'd to die, we are enow
To do our country loss; and if to live,
The fewer men, the greater share of honour.
God's will! I pray thee, wish not one man more.
By Jove, I am not covetous for gold,
Nor care I who doth feed upon my cost;
It yearns me not if men my garments wear;
Such outward things dwell not in my desires:
But if it be a sin to covet honour,
I am the most offending soul alive.
No, faith, my coz, wish not a man from England:
God's peace! I would not lose so great an honour
As one man more, methinks, would share from me
For the best hope I have. O, do not wish one more!
Rather proclaim it, Westmoreland, through my host,
That he which hath no stomach to this fight,
Let him depart; his passport shall be made
And crowns for convoy put into his purse:
We would not die in that man's company
That fears his fellowship to die with us.
This day is called the feast of Crispian:
He that outlives this day, and comes safe home,
Will stand a tip-toe when the day is named,
And rouse him at the name of Crispian.
He that shall live this day, and see old age,
Will yearly on the vigil feast his neighbours,
And say 'To-morrow is Saint Crispian:'
Then will he strip his sleeve and show his scars.
And say 'These wounds I had on Crispin's day.'
Old men forget: yet all shall be forgot,
But he'll remember with advantages
What feats he did that day: then shall our names.
Familiar in his mouth as household words
Harry the king, Bedford and Exeter,
Warwick and Talbot, Salisbury and Gloucester,
Be in their flowing cups freshly remember'd.
This story shall the good man teach his son;
And Crispin Crispian shall ne'er go by,
From this day to the ending of the world, But we in it shall be remember'd; We few, we happy few, we band of brothers; For he to-day that sheds his blood with me Shall be my brother; be he ne'er so vile, This day shall gentle his condition: And gentlemen in England now a-bed Shall think themselves accursed they were not here, And hold their manhoods cheap whiles any speaks That fought with us upon Saint Crispin's day. This memo is a product of the IETF's Router Requirements Working Group. A memo such as this one is of necessity the work of many more people than could be listed here. A wide variety of vendors, network managers, and other experts from the Internet community graciously contributed their time and wisdom to improve the quality of this memo. The editor wishes to extend sincere thanks to all of them. The current editor also wishes to single out and extend his heartfelt gratitude and appreciation to the original editor of this document; Philip Almquist. Without Philip's work, both as the original editor and as the Chair of the working group, this document would not have been produced. Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy Wittbrodt each wrote major chapters of this memo. Others who made major contributions to the document included Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer. Additional text came from Art Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and others who have been inadvertently overlooked. Some of the text in this memo has been (shamelessly) plagiarized from earlier documents, most notably RFC-1122 by Bob Braden and the Host Requirements Working Group, and RFC-1009 by Bob Braden and Jon Postel. The work of these earlier authors is gratefully acknowledged. Jim Forster was a co-chair of the Router Requirements Working Group during its early meetings, and was instrumental in getting the group off to a good start. Jon Postel, Bob Braden, and Walt Prue also contributed to the success by providing a wealth of good advice prior to the group's first meeting. Later on, Phill Gross, Vint Cerf, and Noel Chiappa all provided valuable advice and support.
Mike St. Johns coordinated the Working Group's interactions with the security community, and Frank Kastenholz coordinated the Working Group's interactions with the network management area. Allison Mankin and K.K. Ramakrishnan provided expertise on the issues of congestion control and resource allocation. Many more people than could possibly be listed or credited here participated in the deliberations of the Router Requirements Working Group, either through electronic mail or by attending meetings. However, the efforts of Ross Callon and Vince Fuller in sorting out the difficult issues of route choice and route leaking are especially acknowledged. The previous editor, Philip Almquist, wishes to extend his thanks and appreciation to his former employers, Stanford University and BARRNet, for allowing him to spend a large fraction (probably far more than they ever imagined when he started on this) of his time working on this project. The current editor wishes to thank his employer, FTP Software, for allowing him to spend the time necessary to finish this document.
Editor's Address
The address of the current editor of this document is
Frank J. Kastenholz
FTP Software
2 High Street
North Andover, MA, 01845-2620
USA
Phone: +1 508-685-4000
EMail: kasten@ftp.com