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.