RFC 1812
Requirements for IP Version 4 Routers
Pages: 175
Proposed Standard
→ Errata
Obsoletes: 1716 1009
Updated by: 2644 6633
Proposed Standard
→ Errata
Obsoletes: 1716 1009
Updated by: 2644 6633
Part 7 of 8 – Pages 133 to 155
11. REFERENCES Implementors should be aware that Internet protocol standards are occasionally updated. These references are current as of this writing, but a cautious implementor will always check a recent version of the RFC index to ensure that an RFC has not been updated or superseded by another, more recent RFC. Reference [INTRO:6] explains various ways to obtain a current RFC index. 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", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. APPL:3. Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993. ARCH:1. DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three volumes), DDN Network Information Center, SRI International, Menlo Park, California, USA, December 1985. ARCH:2. V. Cerf and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communication, May 1974. Also included in [ARCH:1]. ARCH:3. J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet Protocol", Computer Networks, 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), RFC 1190, October 1990. FORWARD:2. Mankin, A., and K. Ramakrishnan, Editors, "Gateway Congestion Control Survey", RFC 1254, 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, RFC 791, USC/Information Sciences Institute, September 1981. INTERNET:2. Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, Stanford, USC/Information Sciences Institute, August 1985. INTERNET:3. Mogul, J., "Broadcasting Internet Datagrams in the Presence of Subnets", STD 5, RFC 922, 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", RFC 1108, BBN Communications, November 1991. INTERNET:6. Braden, R., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Communications, September 1988. INTERNET:7. Mallory T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN Communications, January 1990. INTERNET:8. Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 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)", RFC 1016, USC/Information Sciences Institute, August 1987. INTERNET:12. McKenzie, A., "Some comments on SQuID", RFC 1018, BBN Labs, August 1987. INTERNET:13. Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. INTERNET:14. Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, 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" RFC 1519, BARRNet, cisco, Merit, OARnet, September 1993. INTERNET:16 St. Johns, M., "Draft Revised IP Security Option", RFC 1038, IETF, January 1988. INTERNET:17 Prue, W., and J. Postel, "Queuing Algorithm to Provide Type- of-service For IP Links", RFC 1046, USC/Information Sciences Institute, February 1988. INTERNET:18 Postel, J., "Address Mappings", RFC 796, USC/Information Sciences Institute, September 1981. INTRO:1. Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987. INTRO:2. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. INTRO:3. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. INTRO:4. Clark, D., "Modularity and Efficiency in Protocol Implementations", RFC 817, 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", RFC 980, 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, RFC 1392, Xylogics, Inc., UTexas, January 1993. LINK:1. Leffler, S., and M. Karels, "Trailer Encapsulations", RFC 893, 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)", RFC 1332, 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", RFC 1333, 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, RFC 1213, 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, RFC 1157, 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, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. MGT:5. Steinberg, L., "Techniques for Managing Asynchronously Generated Alerts", RFC 1224, IBM Corporation, May 1991. MGT:6. Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., January 1993. MGT:7. McCloghrie, K., and R. Fox "IEEE 802.4 Token Bus MIB", RFC 1230, Hughes LAN Systems, Inc., Synoptics, Inc., May 1991. MGT:8. 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. MGT:9. Case, J., and A. Rijsinghani, "FDDI Management Information Base", RFC 1512, 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", RFC 1317, Xyplex, Inc., April 1992. MGT:11. Kastenholz, F., "Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June 1992. MGT:12. Kastenholz, F., "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", RFC 1472, 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", RFC 1253, ACC, Computer Science Center, August 1991. MGT:15. Willis, S., and J. Burruss, "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet Communications Inc., October 1991. MGT:16. 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. MGT:17. Cox, T., and K. Tesink, Editors "Definitions of Managed Objects for the DS3/E3 Interface Types", RFC 1407, 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", RFC 1304, Bell Communications Research, February 1992. MGT:20 Baker, F., "IP Forwarding Table MIB", RFC 1354, 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", RFC 1381, Data General Corporation, ACC, November 1992. MGT:24. Throop, D., and F. Baker, "SNMP MIB Extension for MultiProtocol Interconnect over X.25", RFC 1461, Data General Corporation, May 1993. MGT:25. Rose, M., "SNMP over OSI", RFC 1418, Dover Beach Consulting, Inc., March 1993. MGT:26. Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, Novell, Inc., Apple Computer, Inc., March 1993. MGT:27. Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993. MGT:28. 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. MGT:29. Case, J., "FDDI Management Information Base", RFC 1285, 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)", RFC 1350, MIT, July 1992. ROUTE:1. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994. ROUTE:2. Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, DEC, December 1990.
ROUTE:3. Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988. ROUTE:4. Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, 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", RFC 1772, 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)", RFC 827, BBN, October 1982. ROUTE:8. Seamonson, L, and E. Rosen, "STUB" "Exterior Gateway Protocol", RFC 888, BBN, January 1984. ROUTE:9. Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, 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", RFC 1349, Consultant, July 1992. ROUTE:12. Rekhter, Y., "Experience with the BGP Protocol", RFC 1266, T.J. Watson Research Center, IBM Corp., October 1991. ROUTE:13. 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 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 RFC 791.
IP does not provide a reliable communications facility; that is,
there are no end-to-end of hop-by-hop acknowledgments.
IP Datagram
An IP Datagram is the unit of end-to-end transmission in the
Internet Protocol. An IP Datagram consists of an IP header
followed by all of higher-layer data (such as TCP, UDP, ICMP,
and the like). An IP Datagram is an IP header followed by a
message.
An IP Datagram is a complete IP end-to-end transmission unit.
An IP Datagram is composed of one or more IP Fragments.
In this memo, the unqualified term Datagram should be understood
to refer to an IP Datagram.
IP Fragment
An IP Fragment is a component of an IP Datagram. An IP Fragment
consists of an IP header followed by all or part of the higher-
layer of the original IP Datagram.
One or more IP Fragments comprises a single IP Datagram.
In this memo, the unqualified term Fragment should be understood
to refer to an IP Fragment.
IP Packet
An IP Datagram or an IP Fragment.
In this memo, the unqualified term Packet should generally be
understood to refer to an IP Packet.
Logical [network] interface
We define a logical [network] interface to be a logical path,
distinguished by a unique IP address, to a connected network.
Martian Filtering
A packet 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.
(page 155 continued on part 8)