tech-invite   World Map     

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

RFC 1716


Towards Requirements for IP Routers

Part 6 of 6, p. 160 to 192
Prev RFC Part


prevText      Top      Up      ToC       Page 160 
     J. Postel, Internet Protocol, Request For Comments (RFC) 791, STD
     5, USC/Information Sciences Institute, September 1981.

     J. Mogul and J. Postel, Internet Standard Subnetting Procedure,
     Request For Comments (RFC) 950, STD 5, USC/Information Sciences
     Institute, August 1985.

     J. Mogul, Broadcasting Internet Datagrams in the Presence of
     Subnets, Request For Comments (RFC) 922, STD 5, Stanford, October

     S. Deering, Host Extensions for IP Multicasting, Request For
     Comments (RFC) 1112, STD 5, Stanford University, August 1989.

     S. Kent, U.S. Department of Defense Security Options for the
     Internet Protocol, Request for Comments (RFC) 1108, BBN
     Communications, November 1991.

     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.

     T. Mallory and A. Kullberg, Incremental Updating of the Internet
     Checksum, Request For Comments (RFC) 1141, BBN, January 1990.

     J. Postel, Internet Control Message Protocol, Request For Comments
     (RFC) 792, STD 5, USC/Information Sciences Institute, September

     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.

     G. Finn, A Connectionless Congestion Control Algorithm, Computer
     Communications Review, vol. 19, no. 5, Association for Computing
     Machinery, October 1989.

Top      Up      ToC       Page 161 
     W. Prue, J. Postel, The Source Quench Introduced Delay (SQuID),
     Request For Comments (RFC) 1016, USC/Information Sciences
     Institute, August 1987.

     A. McKenzie, Some comments on SQuID, Request For Comments (RFC)
     1018, BBN, August 1987.

     S. Deering, ICMP Router Discovery Messages, Request For Comments
     (RFC) 1256, Xerox PARC, September 1991.

     J. Mogul and S. Deering, Path MTU Discovery, Request For Comments
     (RFC) 1191, DECWRL, Stanford University, November 1990.

     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.

     M. St. Johns, Draft Revised IP Security Option, Request for
     Comments 1038, IETF, January 1988.

     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.

     R. Braden and J. Postel, Requirements for Internet Gateways,
     Request For Comments (RFC) 1009, STD 4, USC/Information Sciences
     Institute, June 1987.

     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

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

     D. Clark, Modularity and Efficiency in Protocol Implementations,
     Request For Comments (RFC) 817, MIT, July 1982.

     D. Clark, The Structuring of Systems Using Upcalls, Proceedings of
     10th ACM SOSP, December 1985.

     O. Jacobsen and J. Postel, Protocol Document Order Information,
     Request For Comments (RFC) 980, SRI, USC/Information Sciences
     Institute, March 1986.

     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.

     DoD Trusted Computer System Evaluation Criteria, DoD publication
     5200.28-STD, U.S. Department of Defense, December 1985.

     G. Malkin and T. LaQuey Parker, Internet Users' Glossary, Request
     for Comments (RFC) 1392 (also FYI 0018), Xylogics, Inc., UTexas,
     January 1993.

     S. Leffler and M. Karels, Trailer Encapsulations, Request For
     Comments (RFC) 893, U. C. Berkeley, April 1984.

     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.

Top      Up      ToC       Page 163 
     G. McGregor, The PPP Internet Protocol Control Protocol (IPCP),
     Request For Comments (RFC) 1332, Merit, May 1992.

     B. Lloyd, W. Simpson, PPP Authentication Protocols, Request For
     Comments (RFC) 1334, Daydreamer, May 1992.

     W. Simpson, PPP Link Quality Monitoring, Daydreamer, Request For
     Comments (RFC) 1333, May 1992.

     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.

     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.

     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.

     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.

     L. Steinberg, Techniques for Managing Asynchronously Generated
     Alerts, Request for Comments (RFC) 1224, IBM, May 1991.

     F. Kastenholz, Definitions of Managed Objects for the Ethernet-like
     Interface Types, Request for Comments (RFC) 1398, FTP Software
     January 1993.

Top      Up      ToC       Page 164 
     R. Fox and K. McCloghrie, IEEE 802.4 Token Bus MIB, Request for
     Comments (RFC) 1230, Hughes LAN Systems, Synoptics, Inc., May 1991.

     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.

     J. Case and A. Rijsinghani, FDDI Management Information Base,
     Request for Comments (RFC) 1512, SNMP Research, Digital Equipment
     Corporation, September 1993.

     B. Stewart, Definitions of Managed Objects for RS-232-like Hardware
     Devices, Request for Comments (RFC) 1317, Xyplex, Inc., April 1992.

     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.

     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.

     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.

     F. Baker and R. Coltun, OSPF Version 2 Management Information Base,
     Request For Comments (RFC) 1253, ACC, Computer Science Center,
     August 1991.

     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.

     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

Top      Up      ToC       Page 165 

     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.

     K. McCloghrie, Extensions to the Generic-Interface MIB, Request For
     Comments (RFC) 1229,  Hughes LAN Systems, August 1992.

     T. Cox and K. Tesink, Definitions of Managed Objects for the SIP
     Interface Type, Request For Comments (RFC) 1304, Bell
     Communications Research, February 1992.

     F. Baker, IP Forwarding Table MIB, Request For Comments (RFC) 1354,
     ACC, July 1992.

     G. Malkin and F. Baker, RIP Version 2 MIB Extension, Request For
     Comments (RFC) 1389, Xylogics, Inc., Advanced Computer
     Communications, January 1993.

     D. Throop, SNMP MIB Extension for the X.25 Packet Layer, Request
     For Comments (RFC) 1382, Data General Corporation, November 1992.

     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.

     D. Throop and F. Baker, SNMP MIB Extension for MultiProtocol
     Interconnect over X.25, Request For Comments (RFC) 1461, Data
     General Corporation, May 1993.

     M. Rose, SNMP over OSI, Request For Comments (RFC) 1418, Dover
     Beach Consulting, Inc., March 1993.

     G. Minshall and M. Ritter, SNMP over AppleTalk, Request For
     Comments (RFC) 1419, Novell, Inc., Apple Computer, Inc., March

Top      Up      ToC       Page 166 
     S. Bostock, SNMP over IPX, Request For Comments (RFC) 1420, Novell,
     Inc., March 1993.

     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.

     J. Case, FDDI Management Information Base, Request For Comments
     (RFC) 1285, SNMP Research, Incorporated, January 1992.

     J. Nagle, Congestion Control in IP/TCP Internetworks, Request For
     Comments (RFC) 896, FACC, January 1984.

     K.R. Sollins, TFTP Protocol (revision 2), Request For Comments
     (RFC) 1350, MIT, July 1992.

     J. Moy, OSPF Version 2, Request For Comments (RFC) 1247, Proteon,
     July 1991.

     R. Callon, Use of OSI IS-IS for Routing in TCP/IP and Dual
     Environments, Request For Comments (RFC) 1195, DEC, December 1990.

     C. L. Hedrick, Routing Information Protocol, Request For Comments
     (RFC) 1058, Rutgers University, June 1988.

     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.

     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.

Top      Up      ToC       Page 167 
     D. Mills, Exterior Gateway Protocol Formal Specification, Request
     For Comments (RFC) 904, UDEL, April 1984.

     E. Rosen, Exterior Gateway Protocol (EGP), Request For Comments
     (RFC) 827, BBN, October 1982.

     L. Seamonson and E. Rosen, "STUB" Exterior Gateway Protocol,
     Request For Comments (RFC) 888, BBN, January 1984.

     D. Waitzman, C. Partridge, and S. Deering, Distance Vector
     Multicast Routing Protocol, Request For Comments (RFC) 1075, BBN,
     Stanford, November 1988.

     S. Deering, Multicast Routing in Internetworks and Extended LANs,
     Proceedings of SIGCOMM '88, Association for Computing Machinery,
     August 1988.

     P. Almquist, Type of Service in the Internet Protocol Suite,
     Request for Comments (RFC) 1349, Consultant, July 1992.

     Y. Rekhter, Experience with the BGP Protocol, Request For Comments
     (RFC) 1266, T.J. Watson Research Center, IBM Corp., October 1991.

     Y. Rekhter, BGP Protocol Analysis, Request For Comments (RFC) 1265,
     T.J. Watson Research Center, IBM Corp., October 1991.

     J. Postel, User Datagram Protocol, Request For Comments (RFC) 768,
     STD 6, USC/Information Sciences Institute, August 1980.

     J. Postel, Transmission Control Protocol, Request For Comments
     (RFC) 793, STD 7, T.J. Watson Research Center, IBM Corp., September

Top      Up      ToC       Page 168 

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.

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

Top      Up      ToC       Page 170 

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.

     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.

     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.

     Exterior Gateway Protocol A protocol which distributes routing
     information to the gateways (routers) which connect autonomous
     systems.  See IGP.

     Exterior Gateway Protocol version 2 This is an EGP routing protocol
     developed to handle traffic between AS's in the Internet.

     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

Top      Up      ToC       Page 171 
     queue a packet for transmission out another interface, or both.

     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

     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.

     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.

     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.

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

     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.

     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.

     A packet is the unit of data passed across the interface between

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

     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

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.

     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

     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

Silently Discard
     This memo specifies several cases where a router is to Silently

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

     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

     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.

     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.

Top      Up      ToC       Page 175 

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

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

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

(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

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

(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

(22) Almquist's draft ruminations on the next hop and ruminations on
     route leaking need to be reviewed, brought up to date, and

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

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

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

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

Top      Up      ToC       Page 180 
APPENDIX E  Additional Next-Hop Selection Algorithms

Section [] 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

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

   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

Top      Up      ToC       Page 182 
      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 [] 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.

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

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

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

Top      Up      ToC       Page 185 
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
      [].  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
      [] 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 [] 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

Top      Up      ToC       Page 186 

      (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

      (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

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

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

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.

Top      Up      ToC       Page 189 

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,

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

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

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.

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

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

The current editor wishes to thank his employer, FTP Software, for
allowing him to spend the time necessary to finish this document.

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

   Phone: +1 508-685-4000