into a major problem on an operational network. The supposed
operational benefits are not matched by the potential problems.
11. REFERENCES
Implementors should be aware that Internet protocol standards are
occasionally updated. These references are current as of this
writing, but a cautious implementor will always check a recent
version of the RFCindex to ensure that an RFChas not been updated
or superseded by another, more recent RFC. Reference [INTRO:6]
explains various ways to obtain a current RFCindex.
APPL:1.
Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC
951, Stanford University, Sun Microsystems, September 1985.
APPL:2.
Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC1533, Lachman Technology, Inc., Bucknell
University, October 1993.
APPL:3.
Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC1542, Carnegie Mellon University, October 1993.
ARCH:1.
DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three
volumes), DDN Network Information Center, SRI International,
Menlo Park, California, USA, December 1985.
ARCH:2.
V. Cerf and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on Communication, May
1974. Also included in [ARCH:1].
ARCH:3.
J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet
Protocol", Computer Networks, volume 5, number 4, July 1981.
Also included in [ARCH:1].
ARCH:4.
B. Leiner, J. Postel, R. Cole, and D. Mills, :The DARPA
Internet Protocol Suite", Proceedings of INFOCOM '85, IEEE,
Washington, DC, March 1985. Also in: IEEE Communications
Magazine, March 1985. Also available from the Information
Sciences Institute, University of Southern California as
Technical Report ISI-RS-85-153.
ARCH:5.
D. Comer, "Internetworking With TCP/IP Volume 1: Principles,
Protocols, and Architecture", Prentice Hall, Englewood Cliffs,
NJ, 1991.
ARCH:6.
W. Stallings, "Handbook of Computer-Communications Standards
Volume 3: The TCP/IP Protocol Suite", Macmillan, New York, NY,
1990.
ARCH:7.
Postel, J., "Internet Official Protocol Standards", STD 1, RFC
1780, Internet Architecture Board, March 1995.
ARCH:8.
Information processing systems - Open Systems Interconnection -
Basic Reference Model, ISO 7489, International Standards
Organization, 1984.
ARCH:9
R. Braden, J. Postel, Y. Rekhter, "Internet Architecture
Extensions for Shared Media", 05/20/1994
FORWARD:1.
IETF CIP Working Group (C. Topolcic, Editor), "Experimental
Internet Stream Protocol", Version 2 (ST-II), RFC1190, October
1990.
FORWARD:2.
Mankin, A., and K. Ramakrishnan, Editors, "Gateway Congestion
Control Survey", RFC1254, MITRE, Digital Equipment Corporation,
August 1991.
FORWARD:3.
J. Nagle, "On Packet Switches with Infinite Storage", IEEE
Transactions on Communications, volume COM-35, number 4, April
1987.
FORWARD:4.
R. Jain, K. Ramakrishnan, and D. Chiu, "Congestion Avoidance
in Computer Networks With a Connectionless Network Layer",
Technical Report DEC-TR-506, Digital Equipment Corporation.
FORWARD:5.
V. Jacobson, "Congestion Avoidance and Control", Proceedings of
SIGCOMM '88, Association for Computing Machinery, August 1988.
FORWARD:6.
W. Barns, "Precedence and Priority Access Implementation for
Department of Defense Data Networks", Technical Report MTR-
91W00029, The Mitre Corporation, McLean, Virginia, USA, July
1991.
FORWARD:7
Fang, Chen, Hutchins, "Simulation Results of TCP Performance
over ATM with and without Flow Control", presentation to the ATM
Forum, November 15, 1993.
FORWARD:8
V. Paxson, S. Floyd "Wide Area Traffic: the Failure of Poisson
Modeling", short version in SIGCOMM '94.
FORWARD:9
Leland, Taqqu, Willinger and Wilson, "On the Self-Similar Nature
of Ethernet Traffic", Proceedings of SIGCOMM '93, September,
1993.
FORWARD:10
S. Keshav "A Control Theoretic Approach to Flow Control",
SIGCOMM 91, pages 3-16
FORWARD:11
K.K. Ramakrishnan and R. Jain, "A Binary Feedback Scheme for
Congestion Avoidance in Computer Networks", ACM Transactions of
Computer Systems, volume 8, number 2, 1980.
FORWARD:12
H. Kanakia, P. Mishara, and A. Reibman]. "An adaptive
congestion control scheme for real-time packet video transport",
In Proceedings of ACM SIGCOMM 1994, pages 20-31, San Francisco,
California, September 1993.
FORWARD:13
A. Demers, S. Keshav, S. Shenker, "Analysis and Simulation of
a Fair Queuing Algorithm",
93 pages 1-12
FORWARD:14
Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network:
Architecture and Mechanism", 92 pages 14-26
INTERNET:1.
Postel, J., "Internet Protocol", STD 5, RFC791, USC/Information
Sciences Institute, September 1981.
INTERNET:2.
Mogul, J., and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC950, Stanford, USC/Information Sciences
Institute, August 1985.
INTERNET:3.
Mogul, J., "Broadcasting Internet Datagrams in the Presence of
Subnets", STD 5, RFC922, Stanford University, October 1984.
INTERNET:4.
Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, Stanford University, August 1989.
INTERNET:5.
Kent, S., "U.S. Department of Defense Security Options for the
Internet Protocol", RFC1108, BBN Communications, November 1991.
INTERNET:6.
Braden, R., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC1071, USC/Information Sciences
Institute, Cray Research, BBN Communications, September 1988.
INTERNET:7.
Mallory T., and A. Kullberg, "Incremental Updating of the
Internet Checksum", RFC1141, BBN Communications, January 1990.
INTERNET:8.
Postel, J., "Internet Control Message Protocol", STD 5, RFC792,
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, volume 19, number 5, Association
for Computing Machinery, October 1989.
INTERNET:11.
Prue, W., and J. Postel, "The Source Quench Introduced Delay
(SQuID)", RFC1016, USC/Information Sciences Institute, August
1987.
INTERNET:12.
McKenzie, A., "Some comments on SQuID", RFC1018, BBN Labs,
August 1987.
INTERNET:13.
Deering, S., "ICMP Router Discovery Messages", RFC1256, Xerox
PARC, September 1991.
INTERNET:14.
Mogul J., and S. Deering, "Path MTU Discovery", RFC1191,
DECWRL, Stanford University, November 1990.
INTERNET:15
Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy" RFC1519, BARRNet, cisco, Merit, OARnet, September
1993.
INTERNET:16
St. Johns, M., "Draft Revised IP Security Option", RFC1038,
IETF, January 1988.
INTERNET:17
Prue, W., and J. Postel, "Queuing Algorithm to Provide Type-
of-service For IP Links", RFC1046, USC/Information Sciences
Institute, February 1988.
INTERNET:18
Postel, J., "Address Mappings", RFC796, USC/Information
Sciences Institute, September 1981.
INTRO:1.
Braden, R., and J. Postel, "Requirements for Internet
Gateways", STD 4, RFC1009, USC/Information Sciences Institute,
June 1987.
INTRO:2.
Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts - Communication Layers", STD 3,
RFC1122, USC/Information Sciences Institute, October 1989.
INTRO:3.
Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts - Application and Support", STD
3, RFC1123, USC/Information Sciences Institute, October 1989.
INTRO:4.
Clark, D., "Modularity and Efficiency in Protocol
Implementations", RFC817, MIT Laboratory for Computer Science,
July 1982.
INTRO:5.
Clark, D., "The Structuring of Systems Using Upcalls",
Proceedings of 10th ACM SOSP, December 1985.
INTRO:6.
Jacobsen, O., and J. Postel, "Protocol Document Order
Information", RFC980, SRI, USC/Information Sciences Institute,
March 1986.
INTRO:7.
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, 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
Malkin, G., and T. LaQuey Parker, Editors, "Internet Users'
Glossary", FYI 18, RFC1392, Xylogics, Inc., UTexas, January
1993.
LINK:1.
Leffler, S., and M. Karels, "Trailer Encapsulations", RFC893,
University of California at Berkeley, April 1984.
LINK:2
Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, Daydreamer July 1994.
LINK:3
McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC1332, Merit May 1992.
LINK:4
Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC
1334, L&A, Daydreamer, May 1992.
LINK:5
Simpson, W., "PPP Link Quality Monitoring", RFC1333,
Daydreamer, May 1992.
MGT:1.
Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information of TCP/IP-based Internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
MGT:2.
McCloghrie, K., and M. Rose (Editors), "Management Information
Base of TCP/IP-Based Internets: MIB-II", STD 16, RFC1213,
Hughes LAN Systems, Inc., Performance Systems International,
March 1991.
MGT:3.
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
MGT:4.
Rose, M., and K. McCloghrie (Editors), "Towards Concise MIB
Definitions", STD 16, RFC1212, Performance Systems
International, Hughes LAN Systems, March 1991.
MGT:5.
Steinberg, L., "Techniques for Managing Asynchronously Generated
Alerts", RFC1224, IBM Corporation, May 1991.
MGT:6.
Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC1398, FTP Software, Inc.,
January 1993.
MGT:7.
McCloghrie, K., and R. Fox "IEEE 802.4 Token Bus MIB", RFC1230,
Hughes LAN Systems, Inc., Synoptics, Inc., May 1991.
MGT:8.
McCloghrie, K., Fox R., and E. Decker, "IEEE 802.5 Token Ring
MIB", RFC1231, Hughes LAN Systems, Inc., Synoptics, Inc., cisco
Systems, Inc., February 1993.
MGT:9.
Case, J., and A. Rijsinghani, "FDDI Management Information
Base", RFC1512, The University of Tennesse and SNMP Research,
Digital Equipment Corporation, September 1993.
MGT:10.
Stewart, B., Editor "Definitions of Managed Objects for RS-232-
like Hardware Devices", RFC1317, Xyplex, Inc., April 1992.
MGT:11.
Kastenholz, F., "Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol", RFC1471, FTP
Software, Inc., June 1992.
MGT:12.
Kastenholz, F., "The Definitions of Managed Objects for the
Security Protocols of the Point-to-Point Protocol", RFC1472,
FTP Software, Inc., June 1992.
MGT:13.
Kastenholz, F., "The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point Protocol", RFC
1473, FTP Software, Inc., June 1992.
MGT:14.
Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC1253, ACC, Computer Science Center,
August 1991.
MGT:15.
Willis, S., and J. Burruss, "Definitions of Managed Objects for
the Border Gateway Protocol (Version 3)", RFC1269, Wellfleet
Communications Inc., October 1991.
MGT:16.
Baker, F., and J. Watt, "Definitions of Managed Objects for the
DS1 and E1 Interface Types", RFC1406, Advanced Computer
Communications, Newbridge Networks Corporation, January 1993.
MGT:17.
Cox, T., and K. Tesink, Editors "Definitions of Managed Objects
for the DS3/E3 Interface Types", RFC1407, Bell Communications
Research, January 1993.
MGT:18.
McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
1229, Hughes LAN Systems, August 1992.
MGT:19.
Cox, T., and K. Tesink, "Definitions of Managed Objects for the
SIP Interface Type", RFC1304, Bell Communications Research,
February 1992.
MGT:20
Baker, F., "IP Forwarding Table MIB", RFC1354, ACC, July 1992.
MGT:21.
Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1724, Xylogics, Inc., Cisco Systems, November 1994
MGT:22.
Throop, D., "SNMP MIB Extension for the X.25 Packet Layer", RFC
1382, Data General Corporation, November 1992.
MGT:23.
Throop, D., and F. Baker, "SNMP MIB Extension for X.25 LAPB",
RFC1381, Data General Corporation, ACC, November 1992.
MGT:24.
Throop, D., and F. Baker, "SNMP MIB Extension for MultiProtocol
Interconnect over X.25", RFC1461, Data General Corporation, May
1993.
MGT:25.
Rose, M., "SNMP over OSI", RFC1418, Dover Beach Consulting,
Inc., March 1993.
MGT:26.
Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC1419,
Novell, Inc., Apple Computer, Inc., March 1993.
MGT:27.
Bostock, S., "SNMP over IPX", RFC1420, Novell, Inc., March
1993.
MGT:28.
Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
Ethernet", RFC1089, Rensselaer Polytechnic Institute, MIT
Laboratory for Computer Science, NYSERNet, Inc., University of
Tennessee at Knoxville, February 1989.
MGT:29.
Case, J., "FDDI Management Information Base", RFC1285, SNMP
Research, Incorporated, January 1992.
OPER:1.
Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC
896, FACC, January 1984.
OPER:2.
Sollins, K., "TFTP Protocol (revision 2)", RFC1350, MIT, July
1992.
ROUTE:1.
Moy, J., "OSPF Version 2", RFC1583, Proteon, March 1994.
ROUTE:2.
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC1195, DEC, December 1990.
ROUTE:3.
Hedrick, C., "Routing Information Protocol", RFC1058, Rutgers
University, June 1988.
ROUTE:4.
Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)", RFC1267, cisco, T.J. Watson Research Center, IBM
Corp., October 1991.
ROUTE:5.
Gross, P, and Y. Rekhter, "Application of the Border Gateway
Protocol in the Internet", RFC1772, T.J. Watson Research
Center, IBM Corp., MCI, March 1995.
ROUTE:6.
Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
904, UDEL, April 1984.
ROUTE:7.
Rosen, E., "Exterior Gateway Protocol (EGP)", RFC827, BBN,
October 1982.
ROUTE:8.
Seamonson, L, and E. Rosen, "STUB" "Exterior Gateway Protocol",
RFC888, BBN, January 1984.
ROUTE:9.
Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC1075, BBN, Stanford, November
1988.
ROUTE:10.
Deering, S., Multicast Routing in Internetworks and Extended
LANs, Proceedings of '88, Association for Computing Machinery,
August 1988.
ROUTE:11.
Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC1349, Consultant, July 1992.
ROUTE:12.
Rekhter, Y., "Experience with the BGP Protocol", RFC1266, T.J.
Watson Research Center, IBM Corp., October 1991.
ROUTE:13.
Rekhter, Y., "BGP Protocol Analysis", RFC1265, T.J. Watson
Research Center, IBM Corp., October 1991.
TRANS:1.
Postel, J., "User Datagram Protocol", STD 6, RFC768,
USC/Information Sciences Institute, August 1980.
TRANS:2.
Postel, J., "Transmission Control Protocol", STD 7, RFC793,
USC/Information Sciences Institute, 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.
Autonomous System (AS)
An Autonomous System (AS) is a connected segment of a network
topology that consists of a collection of subnetworks (with
hosts attached) interconnected by a set of routes. The
subnetworks and the routers are expected to be under the control
of a single operations and maintenance (O&M) organization.
Within an AS routers may use one or more interior routing
protocols, and sometimes several sets of metrics. An AS is
expected to present to other ASs an appearence of a coherent
interior routing plan, and a consistent picture of the
destinations reachable through the AS. An AS is identified by
an Autonomous System number.
Connected Network
A network prefix to which a router is interfaced is often known
as a local network or the subnetwork of 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 that is used to direct any data addressed
to any network prefixes not explicitly listed in the routing
table.
Dense Mode
In multicast forwarding, two paradigms are possible: in Dense
Mode forwarding, a network multicast is forwarded as a data link
layer multicast to all interfaces except that on which it was
received, unless and until the router is instructed not to by a
multicast routing neighbor. See Sparse Mode.
EGP
Exterior Gateway Protocol A protocol that 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 Autonomous Systems
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.
Forwarding Information Base (FIB)
The table containing the information necessary to forward IP
Datagrams, in this document, is called the Forwarding
Information Base. At minimum, this contains the interface
identifier and next hop information for each reachable
destination network prefix.
Fragment
An IP datagram that represents a portion of a higher layer's
packet that was too large to be sent in its entirety over the
output network.
General Purpose Serial Interface
A physical medium capable of connecting exactly two systems, and
therefore configurable as a point to point line, but also
configurable to support link layer networking using protocols
such as X.25 or Frame Relay. A link layer network connects
another system to a switch, and a higher communication layer
multiplexes virtual circuits on the connection. See Point to
Point Line.
IGP
Interior Gateway Protocol A protocol that distributes routing
information with an Autonomous System (AS). See EGP.
Interface IP Address
The IP Address and network prefix length that is assigned to a
specific interface of a router.
Internet Address
An assigned number that identifies a host in an internet. It
has two parts: an IP address and a prefix length. The prefix
length indicates how many of the most specific bits of the
address constitute the network prefix.
IP
Internet Protocol The network layer protocol for the Internet.
It is a packet switching, datagram protocol defined in RFC791.
IP does not provide a reliable communications facility; that is,
there are no end-to-end of hop-by-hop acknowledgments.
IP Datagram
An IP Datagram is the unit of end-to-end transmission in the
Internet Protocol. An IP Datagram consists of an IP header
followed by all of higher-layer data (such as TCP, UDP, ICMP,
and the like). An IP Datagram is an IP header followed by a
message.
An IP Datagram is a complete IP end-to-end transmission unit.
An IP Datagram is composed of one or more IP Fragments.
In this memo, the unqualified term Datagram should be understood
to refer to an IP Datagram.
IP Fragment
An IP Fragment is a component of an IP Datagram. An IP Fragment
consists of an IP header followed by all or part of the higher-
layer of the original IP Datagram.
One or more IP Fragments comprises a single IP Datagram.
In this memo, the unqualified term Fragment should be understood
to refer to an IP Fragment.
IP Packet
An IP Datagram or an IP Fragment.
In this memo, the unqualified term Packet should generally be
understood to refer to an IP Packet.
Logical [network] interface
We define a logical [network] interface to be a logical path,
distinguished by a unique IP address, to a connected network.
Martian Filtering
A packet that 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 that is destined for multiple hosts. See broadcast.
Multicast Address
A special type of address that is recognizable by multiple
hosts.
A Multicast Address is sometimes known as a Functional Address
or a Group Address.
Network Prefix
The portion of an IP Address that signifies a set of systems.
It is selected from the IP Address by logically ANDing a subnet
mask with the address, or (equivalently) setting the bits of the
address not among the most significant <prefix-length> bits of
the address to zero.
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 that 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 using
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.
Point to Point Line
A physical medium capable of connecting exactly two systems. In
this document, it is only used to refer to such a line when used
to connect IP entities. See General Purpose Serial Interface.
router
A special-purpose dedicated computer that connects several
networks. 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.
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 through some network management protocol, and
discarding, or ignoring, the source of the error. In
particular, the router does NOT generate an ICMP error message.
Sparse Mode
In multicast forwarding, two paradigms are possible: in Sparse
Mode forwarding, a network layer multicast datagram is forwarded
as a data link layer multicast frame to routers and hosts that
have asked for it. The initial forwarding state is the inverse
of dense-mode in that it assumes no part of the network wants
the data. See Dense Mode.
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 that 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 that 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 that 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
(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.
(12) Load Splitting
(13) Sending fragments along different paths
(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
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 network prefixes.
(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
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. Three
experimental multicast routing protocols have been documented for
TCP/IP. Each uses 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.
D.4 Protocol Independent Multicast - PIM
PIM, currently under development, is a multicast routing protocol
that runs over an existing unicast infrastructure. PIM provides for
both dense and sparse group membership. It is different from other
protocols, since it uses an explicit join model for sparse groups.
Joining occurs on a shared tree and can switch to a per-source tree.
Where bandwidth is plentiful and group membership is dense, overhead
can be reduced by flooding data out all links and later pruning
exception cases where there are no group members.
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 Forwarding
Information Base (FIB). The route lookup algorithm is trivial: the
router looks in the FIB for a route whose destination attribute
exactly matches the network prefix 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 that match the same destination cannot
arise.
Over the years, this classic model has been augmented in small ways.
With the deployment 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 deployment of technologies supporting variable length subnet
masks (variable length network prefixes), the general approach
remained the same although its description became a little more
complicated; network prefixes were introduced as a conscious
simplification and regularization of the architecture. We now say
that each route to a network prefix route has a prefix length
associated with it. This prefix length indicates the number of bits
in the prefix. This may also be represented using the classical
subnet mask. A route cannot be used to route a packet unless each
significant bit in the route's network prefix matches the
corresponding bit in the packet's destination address. Routes with
more bits set in their masks are preferred over routes that 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 that spoke EGP to several "BBN Core Gateways" (the
routers that 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 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 that have areas or make a distinction between
internal and external routes divide their routes into classes
by the type of information used to calculate the route. 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 using 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