Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1812

Requirements for IP Version 4 Routers

Pages: 175
Proposed Standard
Obsoletes:  17161009
Updated by:  26446633
Part 7 of 8 – Pages 133 to 155
First   Prev   Next

Top   ToC   RFC1812 - Page 133   prevText

   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.
Top   ToC   RFC1812 - Page 134
        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,
        NJ, 1991.

        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.
Top   ToC   RFC1812 - Page 135
        Information processing systems - Open Systems Interconnection -
        Basic Reference Model, ISO 7489, International Standards
        Organization, 1984.

        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,
        August 1991.

        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.
Top   ToC   RFC1812 - Page 136
        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.
Top   ToC   RFC1812 - Page 137
        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,
        February, 1990.

        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,
        August 1987.

        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.
Top   ToC   RFC1812 - Page 138
        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,
        June 1987.

        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", STD
        3, RFC 1123, USC/Information Sciences Institute, October 1989.

        Clark, D., "Modularity and Efficiency in Protocol
        Implementations", RFC 817, MIT Laboratory for Computer Science,
        July 1982.

        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,
        March 1986.
Top   ToC   RFC1812 - Page 139
        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.

        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,
        March 1991.
Top   ToC   RFC1812 - Page 140
        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.,
        January 1993.

        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.
Top   ToC   RFC1812 - Page 141
        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,
        August 1991.

        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,
        February 1992.

        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.
Top   ToC   RFC1812 - Page 142
        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.
Top   ToC   RFC1812 - Page 143
        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,
        October 1982.

        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,
        August 1988.

        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.
Top   ToC   RFC1812 - Page 144
        Postel, J., "User Datagram Protocol", STD 6, RFC 768,
        USC/Information Sciences Institute, August 1980.

        Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        USC/Information Sciences Institute, September 1981.
Top   ToC   RFC1812 - Page 145

   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

   (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

   (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
Top   ToC   RFC1812 - Page 146
   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.


   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.

        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.
Top   ToC   RFC1812 - Page 147
   Default Route
        A routing table entry that is used to direct any data addressed
        to any network prefixes not explicitly listed in the routing

   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.

        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
        output network.
Top   ToC   RFC1812 - Page 148
   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.

        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.

        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

        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.
Top   ToC   RFC1812 - Page 149
        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.

        A packet that is destined for multiple hosts.  See broadcast.

   Multicast Address
        A special type of address that is recognizable by multiple

        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.

        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.
Top   ToC   RFC1812 - Page 150
        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

   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.

        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.
Top   ToC   RFC1812 - Page 151
   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.

        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.

        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.
Top   ToC   RFC1812 - Page 152
        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.


   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

   (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
Top   ToC   RFC1812 - Page 153
        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,

   (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

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

   (23) Investigation is needed to determine if a redirect message for
        precedence is needed or not.  If not, are the type-of-service
        redirects acceptable?

   (24) RIPv2 and RIP+CIDR and variable length 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
Top   ToC   RFC1812 - Page 154
        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.
Top   ToC   RFC1812 - Page 155
   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)

Next Section