Implementors should be aware that Internet protocol standards are
occasionally updated. These references are current as of this
writing, but a cautious implementor will always check a recent
version of the RFC index to ensure that an RFC has not been updated
or superseded by another, more recent RFC. Reference [INTRO:6]
explains various ways to obtain a current RFC index.
Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC
951, Stanford University, Sun Microsystems, September 1985.
Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three
volumes), DDN Network Information Center, SRI International,
Menlo Park, California, USA, December 1985.
V. Cerf and R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Transactions on Communication, May
1974. Also included in [ARCH:1].
J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet
Protocol", Computer Networks, volume 5, number 4, July 1981.
Also included in [ARCH:1].
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.
D. Comer, "Internetworking With TCP/IP Volume 1: Principles,
Protocols, and Architecture", Prentice Hall, Englewood Cliffs,
W. Stallings, "Handbook of Computer-Communications Standards
Volume 3: The TCP/IP Protocol Suite", Macmillan, New York, NY,
Postel, J., "Internet Official Protocol Standards", STD 1, RFC
1780, Internet Architecture Board, March 1995.
Information processing systems - Open Systems Interconnection -
Basic Reference Model, ISO 7489, International Standards
R. Braden, J. Postel, Y. Rekhter, "Internet Architecture
Extensions for Shared Media", 05/20/1994
IETF CIP Working Group (C. Topolcic, Editor), "Experimental
Internet Stream Protocol", Version 2 (ST-II), RFC 1190, October
Mankin, A., and K. Ramakrishnan, Editors, "Gateway Congestion
Control Survey", RFC 1254, MITRE, Digital Equipment Corporation,
J. Nagle, "On Packet Switches with Infinite Storage", IEEE
Transactions on Communications, volume COM-35, number 4, April
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.
V. Jacobson, "Congestion Avoidance and Control", Proceedings of
SIGCOMM '88, Association for Computing Machinery, August 1988.
W. Barns, "Precedence and Priority Access Implementation for
Department of Defense Data Networks", Technical Report MTR-
91W00029, The Mitre Corporation, McLean, Virginia, USA, July
Fang, Chen, Hutchins, "Simulation Results of TCP Performance
over ATM with and without Flow Control", presentation to the ATM
Forum, November 15, 1993.
V. Paxson, S. Floyd "Wide Area Traffic: the Failure of Poisson
Modeling", short version in SIGCOMM '94.
Leland, Taqqu, Willinger and Wilson, "On the Self-Similar Nature
of Ethernet Traffic", Proceedings of SIGCOMM '93, September,
S. Keshav "A Control Theoretic Approach to Flow Control",
SIGCOMM 91, pages 3-16
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.
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.
A. Demers, S. Keshav, S. Shenker, "Analysis and Simulation of
a Fair Queuing Algorithm",
93 pages 1-12
Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time
Applications in an Integrated Services Packet Network:
Architecture and Mechanism", 92 pages 14-26
Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
Mogul, J., and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, Stanford, USC/Information Sciences
Institute, August 1985.
Mogul, J., "Broadcasting Internet Datagrams in the Presence of
Subnets", STD 5, RFC 922, Stanford University, October 1984.
Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, Stanford University, August 1989.
Kent, S., "U.S. Department of Defense Security Options for the
Internet Protocol", RFC 1108, BBN Communications, November 1991.
Braden, R., Borman, D., and C. Partridge, "Computing the
Internet Checksum", RFC 1071, USC/Information Sciences
Institute, Cray Research, BBN Communications, September 1988.
Mallory T., and A. Kullberg, "Incremental Updating of the
Internet Checksum", RFC 1141, BBN Communications, January 1990.
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R.
Wilder, and R. Zahavi, "Evaluation of Internet Performance -
FY89", Technical Report MTR-89W00216, MITRE Corporation,
G. Finn, A "Connectionless Congestion Control Algorithm",
Computer Communications Review, volume 19, number 5, Association
for Computing Machinery, October 1989.
Prue, W., and J. Postel, "The Source Quench Introduced Delay
(SQuID)", RFC 1016, USC/Information Sciences Institute, August
McKenzie, A., "Some comments on SQuID", RFC 1018, BBN Labs,
Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy" RFC 1519, BARRNet, cisco, Merit, OARnet, September
St. Johns, M., "Draft Revised IP Security Option", RFC 1038,
IETF, January 1988.
Prue, W., and J. Postel, "Queuing Algorithm to Provide Type-
of-service For IP Links", RFC 1046, USC/Information Sciences
Institute, February 1988.
Postel, J., "Address Mappings", RFC 796, USC/Information
Sciences Institute, September 1981.
Braden, R., and J. Postel, "Requirements for Internet
Gateways", STD 4, RFC 1009, USC/Information Sciences Institute,
Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts - Communication Layers", STD 3,
RFC 1122, USC/Information Sciences Institute, October 1989.
Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts - Application and Support", STD3, RFC 1123, USC/Information Sciences Institute, October 1989.
Clark, D., "Modularity and Efficiency in Protocol
Implementations", RFC 817, MIT Laboratory for Computer Science,
Clark, D., "The Structuring of Systems Using Upcalls",
Proceedings of 10th ACM SOSP, December 1985.
Jacobsen, O., and J. Postel, "Protocol Document Order
Information", RFC 980, SRI, USC/Information Sciences Institute,
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
DoD Trusted Computer System Evaluation Criteria, DoD publication
5200.28-STD, U.S. Department of Defense, December 1985.
Malkin, G., and T. LaQuey Parker, Editors, "Internet Users'
Glossary", FYI 18, RFC 1392, Xylogics, Inc., UTexas, January
Leffler, S., and M. Karels, "Trailer Encapsulations", RFC 893,
University of California at Berkeley, April 1984.
Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, Daydreamer July 1994.
McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, Merit May 1992.
Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC
1334, L&A, Daydreamer, May 1992.
Simpson, W., "PPP Link Quality Monitoring", RFC 1333,
Daydreamer, May 1992.
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
McCloghrie, K., and M. Rose (Editors), "Management Information
Base of TCP/IP-Based Internets: MIB-II", STD 16, RFC 1213,
Hughes LAN Systems, Inc., Performance Systems International,
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
Rose, M., and K. McCloghrie (Editors), "Towards Concise MIB
Definitions", STD 16, RFC 1212, Performance Systems
International, Hughes LAN Systems, March 1991.
Steinberg, L., "Techniques for Managing Asynchronously Generated
Alerts", RFC 1224, IBM Corporation, May 1991.
Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 1398, FTP Software, Inc.,
McCloghrie, K., and R. Fox "IEEE 802.4 Token Bus MIB", RFC 1230,
Hughes LAN Systems, Inc., Synoptics, Inc., May 1991.
McCloghrie, K., Fox R., and E. Decker, "IEEE 802.5 Token Ring
MIB", RFC 1231, Hughes LAN Systems, Inc., Synoptics, Inc., cisco
Systems, Inc., February 1993.
Case, J., and A. Rijsinghani, "FDDI Management Information
Base", RFC 1512, The University of Tennesse and SNMP Research,
Digital Equipment Corporation, September 1993.
Stewart, B., Editor "Definitions of Managed Objects for RS-232-
like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992.
Kastenholz, F., "Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP
Software, Inc., June 1992.
Kastenholz, F., "The Definitions of Managed Objects for the
Security Protocols of the Point-to-Point Protocol", RFC 1472,
FTP Software, Inc., June 1992.
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.
Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC 1253, ACC, Computer Science Center,
Willis, S., and J. Burruss, "Definitions of Managed Objects for
the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet
Communications Inc., October 1991.
Baker, F., and J. Watt, "Definitions of Managed Objects for the
DS1 and E1 Interface Types", RFC 1406, Advanced Computer
Communications, Newbridge Networks Corporation, January 1993.
Cox, T., and K. Tesink, Editors "Definitions of Managed Objects
for the DS3/E3 Interface Types", RFC 1407, Bell Communications
Research, January 1993.
McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
1229, Hughes LAN Systems, August 1992.
Cox, T., and K. Tesink, "Definitions of Managed Objects for the
SIP Interface Type", RFC 1304, Bell Communications Research,
Baker, F., "IP Forwarding Table MIB", RFC 1354, ACC, July 1992.
Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1724, Xylogics, Inc., Cisco Systems, November 1994
Throop, D., "SNMP MIB Extension for the X.25 Packet Layer", RFC
1382, Data General Corporation, November 1992.
Throop, D., and F. Baker, "SNMP MIB Extension for X.25 LAPB",
RFC 1381, Data General Corporation, ACC, November 1992.
Throop, D., and F. Baker, "SNMP MIB Extension for MultiProtocol
Interconnect over X.25", RFC 1461, Data General Corporation, May
Rose, M., "SNMP over OSI", RFC 1418, Dover Beach Consulting,
Inc., March 1993.
Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419,
Novell, Inc., Apple Computer, Inc., March 1993.
Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March
Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
Laboratory for Computer Science, NYSERNet, Inc., University of
Tennessee at Knoxville, February 1989.
Case, J., "FDDI Management Information Base", RFC 1285, SNMP
Research, Incorporated, January 1992.
Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC
896, FACC, January 1984.
Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC 1195, DEC, December 1990.
Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM
Corp., October 1991.
Gross, P, and Y. Rekhter, "Application of the Border Gateway
Protocol in the Internet", RFC 1772, T.J. Watson Research
Center, IBM Corp., MCI, March 1995.
Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
904, UDEL, April 1984.
Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827, BBN,
Seamonson, L, and E. Rosen, "STUB" "Exterior Gateway Protocol",
RFC 888, BBN, January 1984.
Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, BBN, Stanford, November
Deering, S., Multicast Routing in Internetworks and Extended
LANs, Proceedings of '88, Association for Computing Machinery,
Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, Consultant, July 1992.
Rekhter, Y., "Experience with the BGP Protocol", RFC 1266, T.J.
Watson Research Center, IBM Corp., October 1991.
Rekhter, Y., "BGP Protocol Analysis", RFC 1265, T.J. Watson
Research Center, IBM Corp., October 1991.
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
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
(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
(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
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.
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.
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.
A routing table entry that is used to direct any data addressed
to any network prefixes not explicitly listed in the routing
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.
Exterior Gateway Protocol A protocol that 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 Autonomous Systems
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 queue a packet for transmission out another interface, or
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.
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
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
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.
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.
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.
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
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.
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.
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.
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
A packet that is destined for multiple hosts. See broadcast.
A special type of address that is recognizable by multiple
A Multicast Address is sometimes known as a Functional Address
or a Group Address.
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.
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
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 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
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
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.
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.
Reverse Path Forwarding - A method used to deduce the next hops
for broadcast and multicast packets.
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
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.
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.
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.
A part of the internet address that designates a subnet. It is
ignored for the purposes internet routing, but is used for
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.
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
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
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
(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
(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,
(19) Should the Link Layer notify IP if address resolution failed
(just like it notifies IP when there is a Link Layer priority
(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
(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
(26) Loose Source Route Mobile IP and some multicasting may require
this. Perhaps it should be elevated to a SHOULD (per Fred
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.
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.