doc: Add RFC documents

1 files changed, 3134 insertions, 0 deletions

diff --git a/doc/rfc/rfc1009.txt b/doc/rfc/rfc1009.txt
new file mode 100644
index 0000000..2cd7072
--- /dev/null
+++ b/doc/rfc/rfc1009.txt
@@ -0,0 +1,3134 @@
+
+
+Network Working Group                                          R. Braden
+Request for Comments: 1009                                     J. Postel
+Obsoletes: 985                                                       ISI
+                                                               June 1987
+
+                   Requirements for Internet Gateways
+
+
+Status of this Memo
+
+   This document is a formal statement of the requirements to be met by
+   gateways used in the Internet system.  As such, it is an official
+   specification for the Internet community.  Distribution of this memo
+   is unlimited.
+
+   This RFC summarizes the requirements for gateways to be used between
+   networks supporting the Internet protocols.  While it was written
+   specifically to support National Science Foundation research
+   programs, the requirements are stated in a general context and are
+   applicable throughout the Internet community.
+
+   The purpose of this document is to present guidance for vendors
+   offering gateway products that might be used or adapted for use in an
+   Internet application.  It enumerates the protocols required and gives
+   references to RFCs and other documents describing the current
+   specifications.  In a number of cases the specifications are evolving
+   and may contain ambiguous or incomplete information.  In these cases
+   further discussion giving specific guidance is included in this
+   document.  Specific policy issues relevant to the NSF scientific
+   networking community are summarized in an Appendix.  As other
+   specifications are updated this document will be revised.  Vendors
+   are encouraged to maintain contact with the Internet research
+   community.
+
+1.  Introduction
+
+   The following material is intended as an introduction and background
+   for those unfamiliar with the Internet architecture and the Internet
+   gateway model.  General background and discussion on the Internet
+   architecture and supporting protocol suite can be found in the DDN
+   Protocol Handbook [25] and ARPANET Information Brochure [26], see
+   also [19, 28, 30, 31].
+
+   The Internet protocol architecture was originally developed under
+   DARPA sponsorship to meet both military and civilian communication
+   requirements [32].  The Internet system presently supports a variety
+   of government and government-sponsored operational and research
+   activities.  In particular, the National Science Foundation (NSF) is
+   building a major extension to the Internet to provide user access to
+
+
+
+
+Braden & Postel                                                 [Page 1]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   national supercomputer centers and other national scientific
+   resources, and to provide a computer networking capability to a large
+   number of universities and colleges.
+
+   In this document there are many terms that may be obscure to one
+   unfamiliar with the Internet protocols.  There is not much to be done
+   about that but to learn, so dive in.  There are a few terms that are
+   much abused in general discussion but are carefully and intentionally
+   used in this document.  These few terms are defined here.
+
+      Packet      A packet is the unit of transmission on a physical
+                  network.
+
+      Datagram    A datagram is the unit of transmission in the IP
+                  protocol.  To cross a particular network a datagram is
+                  encapsulated inside a packet.
+
+      Router      A router is a switch that receives data transmission
+                  units from input interfaces and, depending on the
+                  addresses in those units, routes them to the
+                  appropriate output interfaces.  There can be routers
+                  at different levels of protocol.  For example,
+                  Interface Message Processors (IMPs) are packet-level
+                  routers.
+
+      Gateway     In the Internet documentation generally, and in this
+                  document specifically, a gateway is an IP-level
+                  router.  In the Internet community the term has a long
+                  history of this usage [32].
+
+   1.1.  The DARPA Internet Architecture
+
+      1.1.1.  Internet Protocols
+
+         The Internet system consists of a number of interconnected
+         packet networks supporting communication among host computers
+         using the Internet protocols.  These protocols include the
+         Internet Protocol (IP), the Internet Control Message Protocol
+         (ICMP), the Transmission Control Protocol (TCP), and
+         application protocols depending upon them [22].
+
+         All Internet protocols use IP as the basic data transport
+         mechanism.  IP [1,31] is a datagram, or connectionless,
+         internetwork service and includes provision for addressing,
+         type-of-service specification, fragmentation and reassembly,
+         and security information.  ICMP [2] is considered an integral
+
+
+
+
+Braden & Postel                                                 [Page 2]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         part of IP, although it is architecturally layered upon IP.
+         ICMP provides error reporting, flow control and first-hop
+         gateway redirection.
+
+         Reliable data delivery is provided in the Internet protocol
+         suite by transport-level protocols such as the Transmission
+         Control Protocol (TCP), which provides end-end retransmission,
+         resequencing and connection control.  Transport-level
+         connectionless service is provided by the User Datagram
+         Protocol (UDP).
+
+      1.1.2.  Networks and Gateways
+
+         The constituent networks of the Internet system are required
+         only to provide packet (connectionless) transport.  This
+         requires only delivery of individual packets.  According to the
+         IP service specification, datagrams can be delivered out of
+         order, be lost or duplicated and/or contain errors.  Reasonable
+         performance of the protocols that use IP (e.g., TCP) requires
+         an IP datagram loss rate of less than 5%.  In those networks
+         providing connection-oriented service, the extra reliability
+         provided by virtual circuits enhances the end-end robustness of
+         the system, but is not necessary for Internet operation.
+
+         Constituent networks may generally be divided into two classes:
+
+         *  Local-Area Networks (LANs)
+
+            LANs may have a variety of designs, typically based upon
+            buss, ring, or star topologies.  In general, a LAN will
+            cover a small geographical area (e.g., a single building or
+            plant site) and provide high bandwidth with low delays.
+
+         *  Wide-Area Networks (WANs)
+
+            Geographically-dispersed hosts and LANs are interconnected
+            by wide-area networks, also called long-haul networks.
+            These networks may have a complex internal structure of
+            lines and packet-routers (typified by ARPANET), or they may
+            be as simple as point-to-point lines.
+
+         In the Internet model, constituent networks are connected
+         together by IP datagram forwarders which are called "gateways"
+         or "IP routers".  In this document, every use of the term
+         "gateway" is equivalent to "IP router".  In current practice,
+         gateways are normally realized with packet-switching software
+
+
+
+
+Braden & Postel                                                 [Page 3]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         executing on a general-purpose CPU, but special-purpose
+         hardware may also be used (and may be required for future
+         higher-throughput gateways).
+
+         A gateway is connected to two or more networks, appearing to
+         each of these networks as a connected host.  Thus, it has a
+         physical interface and an IP address on each of the connected
+         networks.  Forwarding an IP datagram generally requires the
+         gateway to choose the address of the next-hop gateway or (for
+         the final hop) the destination host.  This choice, called
+         "routing", depends upon a routing data-base within the gateway.
+         This routing data-base should be maintained dynamically to
+         reflect the current topology of the Internet system; a gateway
+         normally accomplishes this by participating in distributed
+         routing and reachability algorithms with other gateways.
+         Gateways provide datagram transport only, and they seek to
+         minimize the state information necessary to sustain this
+         service in the interest of routing flexibility and robustness.
+
+         Routing devices may also operate at the network level; in this
+         memo we will call such devices MAC routers (informally called
+         "level-2 routers", and also called "bridges").  The name
+         derives from the fact that MAC routers base their routing
+         decision on the addresses in the MAC headers; e.g., in IEEE
+         802.3 networks, a MAC router bases its decision on the 48-bit
+         addresses in the MAC header.  Network segments which are
+         connected by MAC routers share the same IP network number,
+         i.e., they logically form a single IP network.
+
+         Another variation on the simple model of networks connected
+         with gateways sometimes occurs: a set of gateways may be
+         interconnected with only serial lines, to effectively form a
+         network in which the routing is performed at the internetwork
+         (IP) level rather than the network level.
+
+      1.1.3.  Autonomous Systems
+
+         For technical, managerial, and sometimes political reasons, the
+         gateways of the Internet system are grouped into collections
+         called "autonomous systems" [35].  The gateways included in a
+         single autonomous system (AS) are expected to:
+
+            *  Be under the control of a single operations and
+               maintenance (O&M) organization;
+
+            *  Employ common routing protocols among themselves, to
+               maintain their routing data-bases dynamically.
+
+
+
+Braden & Postel                                                 [Page 4]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         A number of different dynamic routing protocols have been
+         developed (see Section 4.1); the particular choice of routing
+         protocol within a single AS is generically called an interior
+         gateway protocol or IGP.
+
+         An IP datagram may have to traverse the gateways of two or more
+         ASs to reach its destination, and the ASs must provide each
+         other with topology information to allow such forwarding.  The
+         Exterior Gateway Protocol (EGP) is used for this purpose,
+         between gateways of different autonomous systems.
+
+      1.1.4.  Addresses and Subnets
+
+         An IP datagram carries 32-bit source and destination addresses,
+         each of which is partitioned into two parts -- a constituent
+         network number and a host number on that network.
+         Symbolically:
+
+            IP-address ::=  { <Network-number>,  <Host-number> }
+
+         To finally deliver the datagram, the last gateway in its path
+         must map the host-number (or "rest") part of an IP address into
+         the physical address of a host connection to the constituent
+         network.
+
+         This simple notion has been extended by the concept of
+         "subnets", which were introduced in order to allow arbitrary
+         complexity of interconnected LAN structures within an
+         organization, while insulating the Internet system against
+         explosive growth in network numbers and routing complexity.
+         Subnets essentially provide a two-level hierarchical routing
+         structure for the Internet system.  The subnet extension,
+         described in RFC-950 [21], is now a required part of the
+         Internet architecture.  The basic idea is to partition the
+         <host number> field into two parts: a subnet number, and a true
+         host number on that subnet.
+
+            IP-address ::=
+                    { <Network-number>, <Subnet-number>, <Host-number> }
+
+         The interconnected LANs of an organization will be given the
+         same network number but different subnet numbers.  The
+         distinction between the subnets of such a subnetted network
+         must not be visible outside that network.  Thus, wide-area
+         routing in the rest of the Internet will be based only upon the
+         <Network-number> part of the IP destination address; gateways
+         outside the network will lump <Subnet-number> and <Host-number>
+
+
+
+Braden & Postel                                                 [Page 5]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         together to form an uninterpreted "rest" part of the 32-bit IP
+         address.  Within the subnetted network, the local gateways must
+         route on the basis of an extended network number:
+
+            { <Network-number>, <Subnet-number> }.
+
+         The bit positions containing this extended network number are
+         indicated by a 32-bit mask called the "subnet mask" [21]; it is
+         recommended but not required that the <Subnet-number> bits be
+         contiguous and fall between the <Network-number> and the
+         <Host-number> fields.  No subnet should be assigned the value
+         zero or -1 (all one bits).
+
+         Flexible use of the available address space will be
+         increasingly important in coping with the anticipated growth of
+         the Internet.  Thus, we allow a particular subnetted network to
+         use more than one subnet mask.  Several campuses with very
+         large LAN configurations are also creating nested hierarchies
+         of subnets, sub-subnets, etc.
+
+         There are special considerations for the gateway when a
+         connected network provides a broadcast or multicast capability;
+         these will be discussed later.
+
+   1.2.  The Internet Gateway Model
+
+      There are two basic models for interconnecting local-area networks
+      and wide-area (or long-haul) networks in the Internet.  In the
+      first, the local-area network is assigned a network number and all
+      gateways in the Internet must know how to route to that network.
+      In the second, the local-area network shares (a small part of) the
+      address space of the wide-area network.  Gateways that support
+      this second model are called "address sharing gateways" or
+      "transparent gateways".  The focus of this memo is on gateways
+      that support the first model, but this is not intended to exclude
+      the use of transparent gateways.
+
+      1.2.1.  Internet Gateways
+
+         An Internet gateway is an IP-level router that performs the
+         following functions:
+
+            1.  Conforms to specific Internet protocols specified in
+                this document, including the Internet Protocol (IP),
+                Internet Control Message Protocol (ICMP), and others as
+                necessary.  See Section 2 (Protocols Required).
+
+            2.  Interfaces to two or more packet networks.  For each
+
+
+Braden & Postel                                                 [Page 6]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+                connected network the gateway must implement the
+                functions required by that network.  These functions
+                typically include:
+
+               a.  encapsulating and decapsulating the IP datagrams with
+                   the connected network framing (e.g., an Ethernet
+                   header and checksum);
+
+               b.  sending and receiving IP datagrams up to the maximum
+                   size supported by that network, this size is the
+                   network's "Maximum Transmission Unit" or "MTU";
+
+               c.  translating the IP destination address into an
+                   appropriate network-level address for the connected
+                   network (e.g., an Ethernet hardware address);
+
+               d.  responding to the network flow control and error
+                   indication, if any.
+
+               See Section 3 (Constituent Network Interface), for
+               details on particular constituent network interfaces.
+
+            3.  Receives and forwards Internet datagrams.  Important
+                issues are buffer management, congestion control, and
+                fairness.  See Section 4 (Gateway Algorithms).
+
+               a.  Recognizes various error conditions and generates
+                   ICMP error and information messages as required.
+
+               b.  Drops datagrams whose time-to-live fields have
+                   reached zero.
+
+               c.  Fragments datagrams when necessary to fit into the
+                   MTU of the next network.
+
+            4.  Chooses a next-hop destination for each IP datagram,
+                based on the information in its routing data-base.  See
+                Section 4 (Gateway Algorithms).
+
+            5.  Supports an interior gateway protocol (IGP) to carry out
+                distributed routing and reachability algorithms with the
+                other gateways in the same autonomous system.  In
+                addition, some gateways will need to support the
+                Exterior Gateway Protocol (EGP) to exchange topological
+                information with other autonomous systems.  See
+                Section 4 (Gateway Algorithms).
+
+
+
+
+Braden & Postel                                                 [Page 7]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+            6.  Provides system support facilities, including loading,
+                debugging, status reporting, exception reporting and
+                control.  See Section 5 (Operation and Maintenance).
+
+      1.2.2.  Embedded Gateways
+
+         A gateway may be a stand-alone computer system, dedicated to
+         its IP router functions.  Alternatively, it is possible to
+         embed gateway functionality within a host operating system
+         which supports connections to two or more networks.  The
+         best-known example of an operating system with embedded gateway
+         code is the Berkeley BSD system.  The embedded gateway feature
+         seems to make internetting easy, but it has a number of hidden
+         pitfalls:
+
+            1.  If a host has only a single constituent-network
+                interface, it should not act as a gateway.
+
+                For example, hosts with embedded gateway code that
+                gratuitously forward broadcast packets or datagrams on
+                the same net often cause packet avalanches.
+
+            2.  If a (multihomed) host acts as a gateway, it must
+                implement ALL the relevant gateway requirements
+                contained in this document.
+
+                For example, the routing protocol issues (see Sections
+                2.6 and 4.1) and the control and monitoring problems are
+                as hard and important for embedded gateways as for
+                stand-alone gateways.
+
+                   Since Internet gateway requirements and
+                   specifications may change independently of operating
+                   system changes, an administration that operates an
+                   embedded gateway in the Internet is strongly advised
+                   to have an ability to maintain and update the gateway
+                   code (e.g., this might require gateway code source).
+
+            3.  Once a host runs embedded gateway code, it becomes part
+                of the Internet system.  Thus, errors in software or
+                configuration of such a host can hinder communication
+                between other hosts.  As a consequence, the host
+                administrator must lose some autonomy.
+
+                In many circumstances, a host administrator will need to
+                disable gateway coded embedded in the operating system,
+                and any embedded gateway code must be organized so it
+                can be easily disabled.
+
+
+Braden & Postel                                                 [Page 8]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+            4.  If a host running embedded gateway code is concurrently
+                used for other services, the O&M (operation and
+                maintenance) requirements for the two modes of use may
+                be in serious conflict.
+
+                For example, gateway O&M will in many cases be performed
+                remotely by an operations center; this may require
+                privileged system access which the host administrator
+                would not normally want to distribute.
+
+      1.2.3.  Transparent Gateways
+
+         The basic idea of a transparent gateway is that the hosts on
+         the local-area network behind such a gateway share the address
+         space of the wide-area network in front of the gateway.  In
+         certain situations this is a very useful approach and the
+         limitations do not present significant drawbacks.
+
+         The words "in front" and "behind" indicate one of the
+         limitations of this approach: this model of interconnection is
+         suitable only for a geographically (and topologically) limited
+         stub environment.  It requires that there be some form of
+         logical addressing in the network level addressing of the
+         wide-area network (that is, all the IP addresses in the local
+         environment map to a few (usually one) physical address in the
+         wide-area network, in a way consistent with the { IP address
+         <-> network address } mapping used throughout the wide-area
+         network).
+
+         Multihoming is possible on one wide-area network, but may
+         present routing problems if the interfaces are geographically
+         or topologically separated.  Multihoming on two (or more)
+         wide-area networks is a problem due to the confusion of
+         addresses.
+
+         The behavior that hosts see from other hosts in what is
+         apparently the same network may differ if the transparent
+         gateway cannot fully emulate the normal wide-area network
+         service.  For example, if there were a transparent gateway
+         between the ARPANET and an Ethernet, a remote host would not
+         receive a Destination Dead message [3] if it sent a datagram to
+         an Ethernet host that was powered off.
+
+
+
+
+
+
+
+
+Braden & Postel                                                 [Page 9]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   1.3.  Gateway Characteristics
+
+      Every Internet gateway must perform the functions listed above.
+      However, a vendor will have many choices on power, complexity, and
+      features for a particular gateway product.  It may be helpful to
+      observe that the Internet system is neither homogeneous nor
+      fully-connected.  For reasons of technology and geography, it is
+      growing into a global-interconnect system plus a "fringe" of LANs
+      around the "edge".
+
+         *  The global-interconnect system is comprised of a number of
+            wide-area networks to which are attached gateways of several
+            ASs; there are relatively few hosts connected directly to
+            it.  The global-interconnect system includes the ARPANET,
+            the NSFNET "backbone", the various NSF regional and
+            consortium networks, other ARPA sponsored networks such as
+            the SATNET and the WBNET, and the DCA sponsored MILNET.  It
+            is anticipated that additional networks sponsored by these
+            and other agencies (such as NASA and DOE) will join the
+            global-interconnect system.
+
+         *  Most hosts are connected to LANs, and many organizations
+            have clusters of LANs interconnected by local gateways.
+            Each such cluster is connected by gateways at one or more
+            points into the global-interconnect system.  If it is
+            connected at only one point, a LAN is known as a "stub"
+            network.
+
+      Gateways in the global-interconnect system generally require:
+
+         *  Advanced routing and forwarding algorithms
+
+            These gateways need routing algorithms which are highly
+            dynamic and also offer type-of-service routing.  Congestion
+            is still not a completely resolved issue [24].  Improvements
+            to the current situation will be implemented soon, as the
+            research community is actively working on these issues.
+
+         *  High availability
+
+            These gateways need to be highly reliable, providing 24 hour
+            a day, 7 days a week service.  In case of failure, they must
+            recover quickly.
+
+         *  Advanced O&M features
+
+            These gateways will typically be operated remotely from a
+            regional or national monitoring center.  In their
+
+
+Braden & Postel                                                [Page 10]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+            interconnect role, they will need to provide sophisticated
+            means for monitoring and measuring traffic and other events
+            and for diagnosing faults.
+
+         *  High performance
+
+            Although long-haul lines in the Internet today are most
+            frequently 56 Kbps, DS1 lines (1.5 Mbps) are of increasing
+            importance, and even higher speeds are likely in the future.
+            Full-duplex operation is provided at any of these speeds.
+
+            The average size of Internet datagrams is rather small, of
+            the order of 100 bytes.  At DS1 line speeds, the
+            per-datagram processing capability of the gateways, rather
+            than the line speed, is likely to be the bottleneck.  To
+            fill a DS1 line with average-sized Internet datagrams, a
+            gateway would need to pass -- receive, route, and send --
+            2,000 datagrams per second per interface.  That is, a
+            gateway which supported 3 DS1 lines and and Ethernet
+            interface would need to be able to pass a dazzling 2,000
+            datagrams per second in each direction on each of the
+            interfaces, or a aggregate throughput of 8,000 datagrams per
+            second, in order to fully utilize DS1 lines.  This is beyond
+            the capability of current gateways.
+
+               Note: some vendors count input and output operations
+               separately in datagrams per second figures; for these
+               vendors, the above example would imply 16,000 datagrams
+               per second !
+
+      Gateways used in the "LAN fringe" (e.g., campus networks) will
+      generally have to meet less stringent requirements for
+      performance, availability, and maintenance.  These may be high or
+      medium-performance devices, probably competitively procured from
+      several different vendors and operated by an internal organization
+      (e.g., a campus computing center).  The design of these gateways
+      should emphasize low average delay and good burst performance,
+      together with delay and type-of-service sensitive resource
+      management.  In this environment, there will be less formal O&M,
+      more hand-crafted static configurations for special cases, and
+      more need for inter-operation with gateways of other vendors.  The
+      routing mechanism will need to be very flexible, but need not be
+      so highly dynamic as in the global-interconnect system.
+
+      It is important to realize that Internet gateways normally operate
+      in an unattended mode, but that equipment and software faults can
+      have a wide-spread (sometimes global) effect.  In any environment,
+
+
+
+Braden & Postel                                                [Page 11]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      a gateway must be highly robust and able to operate, possibly in a
+      degraded state, under conditions of extreme congestion or failure
+      of network resources.
+
+      Even though the Internet system is not fully-interconnected, many
+      parts of the system do need to have redundant connectivity.  A
+      rich connectivity allows reliable service despite failures of
+      communication lines and gateways, and it can also improve service
+      by shortening Internet paths and by providing additional capacity.
+      The engineering tradeoff between cost and reliability must be made
+      for each component of the Internet system.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 12]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+2.  Protocols Required in Gateways
+
+   The Internet architecture uses datagram gateways to interconnect
+   constituent networks.  This section describes the various protocols
+   which a gateway needs to implement.
+
+   2.1.  Internet Protocol (IP)
+
+      IP is the basic datagram protocol used in the Internet system [19,
+      31].  It is described in RFC-791 [1] and also in MIL-STD-1777 [5]
+      as clarified by RFC-963 [36] ([1] and [5] are intended to describe
+      the same standard, but in quite different words).  The subnet
+      extension is described in RFC-950 [21].
+
+      With respect to current gateway requirements the following IP
+      features can be ignored, although they may be required in the
+      future:  Type of Service field, Security option, and Stream ID
+      option.  However, if recognized, the interpretation of these
+      quantities must conform to the standard specification.
+
+      It is important for gateways to implement both the Loose and
+      Strict Source Route options.  The Record Route and Timestamp
+      options are useful diagnostic tools and must be supported in all
+      gateways.
+
+      The Internet model requires that a gateway be able to fragment
+      datagrams as necessary to match the MTU of the network to which
+      they are being forwarded, but reassembly of fragmented datagrams
+      is generally left to the destination hosts.  Therefore, a gateway
+      will not perform reassembly on datagrams it forwards.
+
+      However, a gateway will generally receive some IP datagrams
+      addressed to itself; for example, these may be ICMP Request/Reply
+      messages, routing update messages (see Sections 2.3 and 2.6), or
+      for monitoring and control (see Section 5).  For these datagrams,
+      the gateway will be functioning as a destination host, so it must
+      implement IP reassembly in case the datagrams have been fragmented
+      by some transit gateway.  The destination gateway must have a
+      reassembly buffer which is at least as large as the maximum of the
+      MTU values for its network interfaces and 576.  Note also that it
+      is possible for a particular protocol implemented by a host or
+      gateway to require a lower bound on reassembly buffer size which
+      is larger than 576.  Finally, a datagram which is addressed to a
+      gateway may use any of that gateway's IP addresses as destination
+      address, regardless of which interface the datagram enters.
+
+      There are five classes of IP addresses:  Class A through
+      Class E [23].  Of these, Class D and Class E addresses are
+
+
+Braden & Postel                                                [Page 13]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      reserved for experimental use.  A gateway which is not
+      participating in these experiments must ignore all datagrams with
+      a Class D or Class E destination IP address.  ICMP Destination
+      Unreachable or ICMP Redirect messages must not result from
+      receiving such datagrams.
+
+      There are certain special cases for IP addresses, defined in the
+      latest Assigned Numbers document [23].  These special cases can be
+      concisely summarized using the earlier notation for an IP address:
+
+         IP-address ::=  { <Network-number>, <Host-number> }
+
+            or
+
+         IP-address ::=  { <Network-number>, <Subnet-number>,
+                                                         <Host-number> }
+
+      if we also use the notation "-1" to mean the field contains all 1
+      bits.  Some common special cases are as follows:
+
+         (a)   {0, 0}
+
+            This host on this network.  Can only be used as a source
+            address (see note later).
+
+         (b)   {0, <Host-number>}
+
+            Specified host on this network.  Can only be used as a
+            source address.
+
+         (c)   { -1, -1}
+
+            Limited broadcast.  Can only be used as a destination
+            address, and a datagram with this address must never be
+            forwarded outside the (sub-)net of the source.
+
+         (d)   {<Network-number>, -1}
+
+            Directed broadcast to specified network.  Can only be used
+            as a destination address.
+
+         (e)   {<Network-number>, <Subnet-number>, -1}
+
+            Directed broadcast to specified subnet.  Can only be used as
+            a destination address.
+
+         (f)   {<Network-number>, -1, -1}
+
+
+
+Braden & Postel                                                [Page 14]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+            Directed broadcast to all subnets of specified subnetted
+            network.  Can only be used as a destination address.
+
+         (g)   {127, <any>}
+
+            Internal host loopback address.  Should never appear outside
+            a host.
+
+      The following two are conventional notation for network numbers,
+      and do not really represent IP addresses.  They can never be used
+      in an IP datagram header as an IP source or destination address.
+
+         (h)   {<Network-number>, 0}
+
+            Specified network (no host).
+
+         (i)   {<Network-number>, <Subnet-number>, 0}
+
+            Specified subnet (no host).
+
+      Note also that the IP broadcast address, which has primary
+      application to Ethernets and similar technologies that support an
+      inherent broadcast function, has an all-ones value in the host
+      field of the IP address.  Some early implementations chose the
+      all-zeros value for this purpose, which is not in conformance with
+      the specification [23, 49, 50].
+
+   2.2.  Internet Control Message Protocol (ICMP)
+
+      ICMP is an auxiliary protocol used to convey advice and error
+      messages and is described in RFC-792 [2].
+
+      We will discuss issues arising from gateway handling of particular
+      ICMP messages.  The ICMP messages are grouped into two classes:
+      error messages and information messages.  ICMP error messages are
+      never sent about ICMP error messages, nor about broadcast or
+      multicast datagrams.
+
+         The ICMP error messages are: Destination Unreachable, Redirect,
+         Source Quench, Time Exceeded, and Parameter Problem.
+
+         The ICMP information messages are: Echo, Information,
+         Timestamp, and Address Mask.
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 15]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      2.2.1.  Destination Unreachable
+
+         The distinction between subnets of a subnetted network, which
+         depends on the address mask described in RFC-950 [21], must not
+         be visible outside that network.  This distinction is important
+         in the case of the ICMP Destination Unreachable message.
+
+         The ICMP Destination Unreachable message is sent by a gateway
+         in response to a datagram which it cannot forward because the
+         destination is unreachable or down.  The gateway chooses one of
+         the following two types of Destination Unreachable messages to
+         send:
+
+            *  Net Unreachable
+
+            *  Host Unreachable
+
+         Net unreachable implies that an intermediate gateway was unable
+         to forward a datagram, as its routing data-base gave no next
+         hop for the datagram, or all paths were down.  Host Unreachable
+         implies that the destination network was reachable, but that a
+         gateway on that network was unable to reach the destination
+         host.  This might occur if the particular destination network
+         was able to determine that the desired host was unreachable or
+         down.  It might also occur when the destination host was on a
+         subnetted network and no path was available through the subnets
+         of this network to the destination.  Gateways should send Host
+         Unreachable messages whenever other hosts on the same
+         destination network might be reachable; otherwise, the source
+         host may erroneously conclude that ALL hosts on the network are
+         unreachable, and that may not be the case.
+
+      2.2.2.  Redirect
+
+         The ICMP Redirect message is sent by a gateway to a host on the
+         same network, in order to change the gateway used by the host
+         for routing certain datagrams.  A choice of four types of
+         Redirect messages is available to specify datagrams destined
+         for a particular host or network, and possibly with a
+         particular type-of-service.
+
+         If the directly-connected network is not subnetted, a gateway
+         can normally send a network Redirect which applies to all hosts
+         on a specified remote network.  Using a network rather than a
+         host Redirect may economize slightly on network traffic and on
+         host routing table storage.  However, the saving is not
+         significant, and subnets create an ambiguity about the subnet
+
+
+
+Braden & Postel                                                [Page 16]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         mask to be used to interpret a network Redirect.  In a general
+         subnet environment, it is difficult to specify precisely the
+         cases in which network Redirects can be used.
+
+         Therefore, it is recommended that a gateway send only host (or
+         host and type-of-service) Redirects.
+
+      2.2.3.  Source Quench
+
+         All gateways must contain code for sending ICMP Source Quench
+         messages when they are forced to drop IP datagrams due to
+         congestion.  Although the Source Quench mechanism is known to
+         be an imperfect means for Internet congestion control, and
+         research towards more effective means is in progress, Source
+         Quench is considered to be too valuable to omit from production
+         gateways.
+
+         There is some argument that the Source Quench should be sent
+         before the gateway is forced to drop datagrams [62].  For
+         example, a parameter X could be established and set to have
+         Source Quench sent when only X buffers remain.  Or, a parameter
+         Y could be established and set to have Source Quench sent when
+         only Y per cent of the buffers remain.
+
+         Two problems for a gateway sending Source Quench are: (1) the
+         consumption of bandwidth on the reverse path, and (2) the use
+         of gateway CPU time.  To ameliorate these problems, a gateway
+         must be prepared to limit the frequency with which it sends
+         Source Quench messages.  This may be on the basis of a count
+         (e.g., only send a Source Quench for every N dropped datagrams
+         overall or per given source host), or on the basis of a time
+         (e.g., send a Source Quench to a given source host or overall
+         at most once per T millseconds).  The parameters (e.g., N or T)
+         must be settable as part of the configuration of the gateway;
+         furthermore, there should be some configuration setting which
+         disables sending Source Quenches.  These configuration
+         parameters, including disabling, should ideally be specifiable
+         separately for each network interface.
+
+         Note that a gateway itself may receive a Source Quench as the
+         result of sending a datagram targeted to another gateway.  Such
+         datagrams might be an EGP update, for example.
+
+      2.2.4.  Time Exceeded
+
+         The ICMP Time Exceeded message may be sent when a gateway
+         discards a datagram due to the TTL being reduced to zero.  It
+
+
+
+Braden & Postel                                                [Page 17]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         may also be sent by a gateway if the fragments of a datagram
+         addressed to the gateway itself cannot be reassembled before
+         the time limit.
+
+      2.2.5.  Parameter Problem
+
+         The ICMP Parameter Problem message may be sent to the source
+         host for any problem not specifically covered by another ICMP
+         message.
+
+      2.2.6.  Address Mask
+
+         Host and gateway implementations are expected to support the
+         ICMP Address Mask messages described in RFC-950 [21].
+
+      2.2.7.  Timestamp
+
+         The ICMP Timestamp message has proven to be useful for
+         diagnosing Internet problems.  The preferred form for a
+         timestamp value, the "standard value", is in milliseconds since
+         midnight GMT.  However, it may be difficult to provide this
+         value with millisecond resolution.  For example, many systems
+         use clocks which update only at line frequency, 50 or 60 times
+         per second.  Therefore, some latitude is allowed in a
+         "standard" value:
+
+            *  The value must be updated at a frequency of at least 30
+               times per second (i.e., at most five low-order bits of
+               the value may be undefined).
+
+            *  The origin of the value must be within a few minutes of
+               midnight, i.e., the accuracy with which operators
+               customarily set CPU clocks.
+
+         To meet the second condition for a stand-alone gateway, it will
+         be necessary to query some time server host when the gateway is
+         booted or restarted.  It is recommended that the UDP Time
+         Server Protocol [44] be used for this purpose.  A more advanced
+         implementation would use NTP (Network Time Protocol) [45] to
+         achieve nearly millisecond clock synchronization; however, this
+         is not required.
+
+         Even if a gateway is unable to establish its time origin, it
+         ought to provide a "non-standard" timestamp value (i.e., with
+         the non-standard bit set), as a time in milliseconds from
+         system startup.
+
+
+
+
+Braden & Postel                                                [Page 18]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         New gateways, especially those expecting to operate at T1 or
+         higher speeds, are expected to have at least millisecond
+         clocks.
+
+      2.2.8.  Information Request/Reply
+
+         The Information Request/Reply pair was intended to support
+         self-configuring systems such as diskless workstations, to
+         allow them to discover their IP network numbers at boot time.
+         However, the Reverse ARP (RARP) protocol [15] provides a better
+         mechanism for a host to use to discover its own IP address, and
+         RARP is recommended for this purpose.  Information
+         Request/Reply need not be implemented in a gateway.
+
+      2.2.9.  Echo Request/Reply
+
+         A gateway must implement ICMP Echo, since it has proven to be
+         an extremely useful diagnostic tool.  A gateway must be
+         prepared to receive, reassemble, and echo an ICMP Echo Request
+         datagram at least as large as the maximum of 576 and the MTU's
+         of all of the connected networks.  See the discussion of IP
+         reassembly in gateways, Section 2.1.
+
+         The following rules resolve the question of the use of IP
+         source routes in Echo Request and Reply datagrams.  Suppose a
+         gateway D receives an ICMP Echo Request addressed to itself
+         from host S.
+
+            1.  If the Echo Request contained no source route, D should
+                send an Echo Reply back to S using its normal routing
+                rules.  As a result, the Echo Reply may take a different
+                path than the Request; however, in any case, the pair
+                will sample the complete round-trip path which any other
+                higher-level protocol (e.g., TCP) would use for its data
+                and ACK segments between S and D.
+
+            2.  If the Echo Request did contain a source route, D should
+                send an Echo Reply back to S using as a source route the
+                return route built up in the source-routing option of
+                the Echo Request.
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 19]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   2.3.  Exterior Gateway Protocol (EGP)
+
+      EGP is the protocol used to exchange reachability information
+      between Autonomous Systems of gateways, and is defined in
+      RFC-904 [11].  See also RFC-827 [51], RFC-888 [46], and
+      RFC-975 [27] for background information.  The most widely used EGP
+      implementation is described in RFC-911 [13].
+
+      When a dynamic routing algorithm is operated in the gateways of an
+      Autonomous System (AS), the routing data-base must be coupled to
+      the EGP implementation.  This coupling should ensure that, when a
+      net is determined to be unreachable by the routing algorithm, the
+      net will not be declared reachable to other ASs via EGP.  This
+      requirement is designed to minimize spurious traffic to "black
+      holes" and to ensure fair utilization of the resources on other
+      systems.
+
+      The present EGP specification defines a model with serious
+      limitations, most importantly a restriction against propagating
+      "third party" EGP information in order to prevent long-lived
+      routing loops [27].  This effectively limits EGP to a two-level
+      hierarchy; the top level is formed by the "core" AS, while the
+      lower level is composed of those ASs which are direct neighbor
+      gateways to the core AS.  In practice, in the current Internet,
+      nearly all of the "core gateways" are connected to the ARPANET,
+      while the lower level is composed of those ASs which are directly
+      gatewayed to the ARPANET or MILNET.
+
+      RFC-975 [27] suggested one way to generalize EGP to lessen these
+      topology restrictions;  it has not been adopted as an official
+      specification, although its ideas are finding their way into the
+      new EGP developments.  There are efforts underway in the research
+      community to develop an EGP generalization which will remove these
+      restrictions.
+
+      In EGP, there is no standard interpretation (i.e., metric) for the
+      distance fields in the update messages, so distances are
+      comparable only among gateways of the same AS.  In using EGP data,
+      a gateway should compare the distances among gateways of the same
+      AS and prefer a route to that gateway which has the smallest
+      distance value.
+
+      The values to be announced in the distance fields for particular
+      networks within the local AS should be a gateway configuration
+      parameter; by suitable choice of these values, it will be possible
+      to arrange primary and backup paths from other AS's.  There are
+      other EGP parameters, such as polling intervals, which also need
+      to be set in the gateway configuration.
+
+
+Braden & Postel                                                [Page 20]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      When routing updates become large they must be transmitted in
+      parts.  One strategy is to use IP fragmentation, another is to
+      explicitly send the routing information in sections.  The Internet
+      Engineering Task Force is currently preparing a recommendation on
+      this and other EGP engineering issues.
+
+   2.4.  Address Resolution Protocol (ARP)
+
+      ARP is an auxiliary protocol used to perform dynamic address
+      translation between LAN hardware addresses and Internet addresses,
+      and is described in RFC-826 [4].
+
+      ARP depends upon local network broadcast.  In normal ARP usage,
+      the initiating host broadcasts an ARP Request carrying a target IP
+      address; the corresponding target host, recognizing its own IP
+      address, sends back an ARP Reply containing its own hardware
+      interface address.
+
+      A variation on this procedure, called "proxy ARP", has been used
+      by gateways attached to broadcast LANs [14].  The gateway sends an
+      ARP Reply specifying its interface address in response to an ARP
+      Request for a target IP address which is not on the
+      directly-connected network but for which the gateway offers an
+      appropriate route.  By observing ARP and proxy ARP traffic, a
+      gateway may accumulate a routing data-base [14].
+
+      Proxy ARP (also known in some quarters as "promiscuous ARP" or
+      "the ARP hack") is useful for routing datagrams from hosts which
+      do not implement the standard Internet routing rules fully -- for
+      example, host implementations which predate the introduction of
+      subnetting.  Proxy ARP for subnetting is discussed in detail in
+      RFC-925 [14].
+
+      Reverse ARP (RARP) allows a host to map an Ethernet interface
+      address into an IP address [15].  RARP is intended to allow a
+      self-configuring host to learn its own IP address from a server at
+      boot time.
+
+   2.5.  Constituent Network Access Protocols
+
+      See Section 3.
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 21]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   2.6.  Interior Gateway Protocols
+
+      Distributed routing algorithms continue to be the subject of
+      research and engineering, and it is likely that advances will be
+      made over the next several years.  A good algorithm needs to
+      respond rapidly to real changes in Internet connectivity, yet be
+      stable and insensitive to transients.  It needs to synchronize the
+      distributed data-base across gateways of its Autonomous System
+      rapidly (to avoid routing loops), while consuming only a small
+      fraction of the available bandwidth.
+
+      Distributed routing algorithms are commonly broken down into the
+      following three components:
+
+         A.  An algorithm to assign a "length" to each Internet path.
+
+            The "length" may be a simple count of hops (1, or infinity
+            if the path is broken), or an administratively-assigned
+            cost, or some dynamically-measured cost (usually an average
+            delay).
+
+            In order to determine a path length, each gateway must at
+            least test whether each of its neighbors is reachable; for
+            this purpose, there must be a "reachability" or "neighbor
+            up/down" protocol.
+
+         B.  An algorithm to compute the shortest path(s) to a given
+             destination.
+
+         C.  A gateway-gateway protocol used to exchange path length and
+             routing information among gateways.
+
+      The most commonly-used IGPs in Internet gateways are as follows.
+
+      2.6.1.  Gateway-to-Gateway Protocol (GGP)
+
+         GGP was designed and implemented by BBN for the first
+         experimental Internet gateways [41].  It is still in use in the
+         BBN LSI/11 gateways, but is regarded as having serious
+         drawbacks [58].  GGP is based upon an algorithm used in the
+         early ARPANET IMPs and later replaced by SPF (see below).
+
+         GGP is a "min-hop" algorithm, i.e., its length measure is
+         simply the number of network hops between gateway pairs.  It
+         implements a distributed shortest-path algorithm, which
+         requires global convergence of the routing tables after a
+         change in topology or connectivity.  Each gateway sends a GGP
+
+
+
+Braden & Postel                                                [Page 22]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         routing update only to its neighbors, but each update includes
+         an entry for every known network, where each entry contains the
+         hop count from the gateway sending the update.
+
+      2.6.2.  Shortest-Path-First (SPF) Protocols
+
+         SPF [40] is the name for a class of routing algorithms based on
+         a shortest-path algorithm of Dijkstra.  The current ARPANET
+         routing algorithm is SPF, and the BBN Butterfly gateways also
+         use SPF.  Its characteristics are considered superior to
+         GGP [58].
+
+         Under SPF, the routing data-base is replicated rather than
+         distributed.  Each gateway will have its own copy of the same
+         data-base, containing the entire Internet topology and the
+         lengths of every path.  Since each gateway has all the routing
+         data and runs a shortest-path algorithm locally, there is no
+         problem of global convergence of a distributed algorithm, as in
+         GGP.  To build this replicated data-base, a gateway sends SPF
+         routing updates to ALL other gateways; these updates only list
+         the distances to each of the gateway's neighbors, making them
+         much smaller than GGP updates.  The algorithm used to
+         distribute SPF routing updates involves reliable flooding.
+
+      2.6.3.  Routing Information (RIP)
+
+         RIP is the name often used for a class of routing protocols
+         based upon the Xerox PUP and XNS routing protocols.  These are
+         relatively simple, and are widely available because they are
+         incorporated in the embedded gateway code of Berkeley BSD
+         systems.  Because of this simplicity, RIP protocols have come
+         the closest of any to being an "Open IGP", i.e., a protocol
+         which can be used between different vendors' gateways.
+         Unfortunately, there is no standard, and in fact not even a
+         good document, for RIP.
+
+         As in GGP, gateways using RIP periodically broadcast their
+         routing data-base to their neighbor gateways, and use a
+         hop-count as the metric.
+
+         A fixed value of the hop-count (normally 16) is defined to be
+         "infinity", i.e., network unreachable.  A RIP implementation
+         must include measures to avoid both the slow-convergence
+         phenomen called "counting to infinity" and the formation of
+         routing loops.  One such measure is a "hold-down" rule.  This
+         rule establishes a period of time (typically 60 seconds) during
+         which a gateway will ignore new routing information about a
+         given network, once the gateway has learned that network is
+
+
+Braden & Postel                                                [Page 23]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         unreachable (has hop-count "infinity").  The hold-down period
+         must be settable in the gateway configuration; if gateways with
+         different hold-down periods are using RIP in the same
+         Autonomous System, routing loops are a distinct possibility.
+         In general, the hold-down period is chosen large enough to
+         allow time for unreachable status to propagate to all gateways
+         in the AS.
+
+      2.6.4.  Hello
+
+         The "Fuzzball" software for an LSI/11 developed by Dave Mills
+         incorporated an IGP called the "Hello" protocol [39].  This IGP
+         is mentioned here because the Fuzzballs have been widely used
+         in Internet experimentation, and because they have served as a
+         testbed for many new routing ideas.
+
+   2.7.  Monitoring Protocols
+
+      See Section 5 of this document.
+
+   2.8.  Internet Group Management Protocol (IGMP)
+
+      An extension to the IP protocol has been defined to provide
+      Internet-wide multicasting, i.e., delivery of copies of the same
+      IP datagram to a set of Internet hosts [47, 48].  This delivery is
+      to be performed by processes known as "multicasting agents", which
+      reside either in a host on each net or (preferably) in the
+      gateways.
+
+      The set of hosts to which a datagram is delivered is called a
+      "host group", and there is a host-agent protocol called IGMP,
+      which a host uses to join, leave, or create a group.  Each host
+      group is distinguished by a Class D IP address.
+
+      This multicasting mechanism and its IGMP protocol are currently
+      experimental; implementation in vendor gateways would be premature
+      at this time.  A datagram containing a Class D IP address must be
+      dropped, with no ICMP error message.
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 24]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+3.  Constituent Network Interface
+
+   This section discusses the rules used for transmission of IP
+   datagrams on the most common types of constituent networks.  A
+   gateway must be able to send and receive IP datagrams of any size up
+   to the MTU of any constituent network to which it is connected.
+
+   3.1.  Public data networks via X.25
+
+      The formats specified for public data networks accessed via X.25
+      are described in RFC-877 [8].  Datagrams are transmitted over
+      standard level-3 virtual circuits as complete packet sequences.
+      Virtual circuits are usually established dynamically as required
+      and time-out after a period of no traffic.  Link-level
+      retransmission, resequencing and flow control are performed by the
+      network for each virtual circuit and by the LAPB link-level
+      protocol.  Note that a single X.25 virtual circuit may be used to
+      multiplex all IP traffic between a pair of hosts.  However,
+      multiple parallel virtual circuits may be used in order to improve
+      the utilization of the subscriber access line, in spite of small
+      X.25 window sizes; this can result in random resequencing.
+
+      The correspondence between Internet and X.121 addresses is usually
+      established by table-lookup.  It is expected that this will be
+      replaced by some sort of directory procedure in the future.  The
+      table of the hosts on the Public Data Network is in the Assigned
+      Numbers [23].
+
+      The normal MTU is 576; however, the two DTE's (hosts or gateways)
+      can use X.25 packet size negotiation to increase this value [8].
+
+   3.2.  ARPANET via 1822 LH, DH, or HDH
+
+      The formats specified for ARPANET networks using 1822 access are
+      described in BBN Report 1822 [3], which includes the procedures
+      for several subscriber access methods.  The Distant Host (DH)
+      method is used when the host and IMP (the Defense Communication
+      Agency calls it a Packet Switch Node or PSN) are separated by not
+      more than about 2000 feet of cable, while the HDLC Distant Host
+      (HDH) is used for greater distances where a modem is required.
+      Under HDH, retransmission, resequencing and flow control are
+      performed by the network and by the HDLC link-level protocol.
+
+      The IP encapsulation format is simply to include the IP datagram
+      as the data portion of an 1822 message.  In addition, the
+      high-order 8 bits of the Message Id field (also known as the
+      "link" field") should be set to 155 [23].  The MTU is 1007 octets.
+
+
+
+Braden & Postel                                                [Page 25]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      While the ARPANET 1822 protocols are widely used at present, they
+      are expected to be eventually overtaken by the DDN Standard X.25
+      protocol (see Section 3.3).  The original IP address mapping
+      (RFC-796 [38]) is in the process of being replaced by a new
+      interface specification called AHIP-E; see RFC-1005 [61] for the
+      proposal.
+
+      Gateways connected to ARPANET or MILNET IMPs using 1822 access
+      must incorporate features to avoid host-port blocking (i.e., RFNM
+      counting) and to detect and report as ICMP Unreachable messages
+      the failure of destination hosts or gateways (i.e., convert the
+      1822 error messages to the appropriate ICMP messages).
+
+      In the development of a network interface it will be useful to
+      review the IMP end-to-end protocol described in RFC-979 [29].
+
+   3.3.  ARPANET via DDN Standard X.25
+
+      The formats specified for ARPANET networks via X.25 are described
+      in the Defense Data Network X.25 Host Interface Specification [6],
+      which describes two sets of procedures: the DDN Basic X.25, and
+      the DDN Standard X.25.  Only DDN Standard X.25 provides the
+      functionality required for interoperability assumptions of the
+      Internet protocol.
+
+      The DDN Standard X.25 procedures are similar to the public data
+      network X.25 procedures, except in the address mappings.
+      Retransmission, resequencing and flow control are performed by the
+      network and by the LAPB link-level protocol.  Multiple parallel
+      virtual circuits may be used in order to improve the utilization
+      of the subscriber access line; this can result in random
+      resequencing.
+
+      Gateways connected to ARPANET or MILNET using Standard X.25 access
+      must detect and report as ICMP Unreachable messages the failure of
+      destination hosts or gateways (i.e., convert the X.25 diagnostic
+      codes to the appropriate ICMP messages).
+
+      To achieve compatibility with 1822 interfaces, the effective MTU
+      for a Standard X.25 interface is 1007 octets.
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 26]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   3.4.  Ethernet and IEEE 802
+
+      The formats specified for Ethernet networks are described in
+      RFC-894 [10].  Datagrams are encapsulated as Ethernet packets with
+      48-bit source and destination address fields and a 16-bit type
+      field (the type field values are listed in the Assigned
+      Numbers [23]).  Address translation between Ethernet addresses and
+      Internet addresses is managed by the Address Resolution Protocol,
+      which is required in all Ethernet implementations.  There is no
+      explicit link-level retransmission, resequencing or flow control,
+      although most hardware interfaces will retransmit automatically in
+      case of collisions on the cable.
+
+      The IEEE 802 networks use a Link Service Access Point (LSAP) field
+      in much the same way the ARPANET uses the "link" field.  Further,
+      there is an extension of the LSAP header called the Sub-Network
+      Access Protocol (SNAP).
+
+      The 802.2 encapsulation is used on 802.3, 802.4, and 802.5 network
+      by using the SNAP with an organization code indicating that the
+      following 16 bits specify the Ether-Type code [23].
+
+      Headers:
+
+         ...--------+--------+--------+
+          MAC Header|      Length     |                  802.{3/4/5} MAC
+         ...--------+--------+--------+
+
+         +--------+--------+--------+
+         | DSAP=K1| SSAP=K1| control|                          802.2 SAP
+         +--------+--------+--------+
+
+         +--------+--------+--------+--------+--------+
+         |protocol id or org code=K2|    Ether-Type   |       802.2 SNAP
+         +--------+--------+--------+--------+--------+
+
+      The total length of the SAP Header and the SNAP header is
+      8-octets, making the 802.2 protocol overhead come out on a 64-bit
+      boundary.
+
+      K1 is 170.  The IEEE likes to talk about things in bit
+      transmission order and specifies this value as 01010101.  In
+      big-endian order, as used in the Internet specifications, this
+      becomes 10101010 binary, or AA hex, or 170 decimal.  K2 is 0
+      (zero).
+
+      The use of the IP LSAP (K1 = 6) is reserved for future
+      development.
+
+
+Braden & Postel                                                [Page 27]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      The assigned values for the Ether-Type field are the same for
+      either this IEEE 802 encapsulation or the basic Ethernet
+      encapsulation [10].
+
+      In either Ethernets or IEEE 802 nets, the IP datagram is the data
+      portion of the packet immediately following the Ether-Type.
+
+      The MTU for an Ethernet or its IEEE-standard equivalent (802.3) is
+      1500 octets.
+
+   3.5.  Serial-Line Protocols
+
+      In some configurations, gateways may be interconnected with each
+      other by means of serial asynchronous or synchronous lines, with
+      or without modems.  When justified by the expected error rate and
+      other factors, a link-level protocol may be required on the serial
+      line.  While there is no single Internet standard for this
+      protocol, it is suggested that one of the following protocols be
+      used.
+
+         *  X.25 LAPB  (Synchronous Lines)
+
+            This is the link-level protocol used for X.25 network
+            access.  It includes HDLC "bit-stuffing" as well as
+            rotating-window flow control and reliable delivery.
+
+               A gateway must be configurable to play the role of either
+               the DCE or the DTE.
+
+         *  HDLC Framing  (Synchronous Lines)
+
+            This is just the bit-stuffing and framing rules of LAPB.  It
+            is the simplest choice, although it provides no flow control
+            or reliable delivery; however, it does provide error
+            detection.
+
+         *  Xerox Synchronous Point-to-Point  (Synchronous Lines)
+
+            This Xerox protocol is an elaboration upon HDLC framing that
+            includes negotiation of maximum packet sizes, dial-up or
+            dedicated circuits, and half- or full-duplex operation [12].
+
+         *  Serial Line Framing Protocol  (Asynchronous Lines)
+
+            This protocol is included in the MIT PC/IP package for an
+            IBM PC and is defined in Appendix I to the manual for that
+            system [20].
+
+
+
+Braden & Postel                                                [Page 28]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      It will be important to make efficient use of the bandwidth
+      available on a serial line between gateways.  For example, it is
+      desirable to provide some form of data compression.  One possible
+      standard compression algorithm, "Thinwire II", is described in
+      RFC-914 [42].  This and similar algorithms are tuned to the
+      particular types of redundancy which occur in IP and TCP headers;
+      however, more work is necessary to define a standard serial-line
+      compression protocol for Internet gateways.  Until a standard has
+      been adopted, each vendor is free to choose a compression
+      algorithm; of course, the result will only be useful on a serial
+      line between two gateways using the same compression algorithm.
+
+      Another way to ensure maximum use of the bandwidth is to avoid
+      unnecessary retransmissions at the link level.  For some kinds of
+      IP traffic, low delay is more important than reliable delivery.
+      The serial line driver could distinguish such datagrams by their
+      IP TOS field, and place them on a special high-priority,
+      no-retransmission queue.
+
+      A serial point-to-point line between two gateways may be
+      considered to be a (particularly simple) network, a "null net".
+      Considered in this way, a serial line requires no special
+      considerations in the routing algorithms of the connected
+      gateways, but does need an IP network number.  To avoid the
+      wholesale consumption of Internet routing data-base space by null
+      nets, we strongly recommend that subnetting be used for null net
+      numbering, whenever possible.
+
+         For example, assume that network 128.203 is to be constructed
+         of gateways joined by null nets; these nets are given (sub-)net
+         numbers 128.203.1, 128.203.2, etc., and the two interfaces on
+         each end of null net 128.203.s might have IP addresses
+         128.203.s.1 and 128.203.s.2.
+
+      An alternative model of a serial line is that it is not a network,
+      but rather an internal communication path joining two "half
+      gateways".  It is possible to design an IGP and routing algorithm
+      that treats a serial line in this manner [39, 52].
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 29]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+4.  Gateway Algorithms
+
+   Gateways are general packet-switches that forward packets according
+   to the IP address, i.e., they are IP routers.   While it is beyond
+   the scope of this document to specify the details of the mechanisms
+   used in any particular, perhaps proprietary, gateway architecture,
+   there are a number of basic algorithms which must be provided by any
+   acceptable design.
+
+   4.1.  Routing Algorithm
+
+      The routing mechanism is fundamental to Internet operation.  In
+      all but trivial network topologies, robust Internet service
+      requires some degree of routing dynamics, whether it be effected
+      by manual or automatic means or by some combination of both.  In
+      particular, if routing changes are made manually, it must be
+      possible to make these routing changes from a remote Network
+      Operation Center (NOC) without taking down the gateway for
+      reconfiguration.  If static routes are used, there must be
+      automatic fallback or rerouting features.
+
+      Handling unpredictable changes in Internet connectivity must be
+      considered the normal case, so that systems of gateways will
+      normally be expected to have a routing algorithm with the
+      capability of reacting to link and other gateway failures and
+      changing the routing automatically.
+
+      This document places no restriction on the type of routing
+      algorithm, e.g., node-based, link-based or any other algorithm, or
+      on the routing distance metric, e.g., delay or hop-count.
+      However, the following features are considered necessary for a
+      successful gateway routing algorithm:
+
+         1.  The algorithm must sense the failure or restoration of a
+             link or other gateway and switch to appropriate paths.  A
+             design objective is to switch paths within an interval less
+             than the typical TCP user time-out (one minute is a safe
+             assumption).
+
+         2.  The algorithm must suppress routing loops between neighbor
+             gateways and must contain provisions to avoid or suppress
+             routing loops that may form between non-neighbor gateways.
+             A design objective is for no loop to persist for longer
+             than an interval greater than the typical TCP user
+             time-out.
+
+         3.  The control traffic necessary to operate the routing
+             algorithm must not significantly degrade or disrupt normal
+
+
+Braden & Postel                                                [Page 30]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+             network operation.  Changes in state which might
+             momentarily disrupt normal operation in a local-area must
+             not cause disruption in remote areas of the network.
+
+         4.  As the size of the network increases, the demand on
+             resources must be controlled in an efficient way.  Table
+             lookups should be hashed, for example, and data-base
+             updates handled piecemeal, with only incremental changes
+             broadcast over a wide-area.
+
+         5.  The size of the routing data-base must not be allowed to
+             exceed a constant, independent of network topology, times
+             the number of nodes times the mean connectivity (average
+             number of incident links).  An advanced design might not
+             require that the entire routing data-base be kept in any
+             particular gateway, so that discovery and caching
+             techniques would be necessary.
+
+         6.  Reachability and delay metrics, if used, must not depend on
+             direct connectivity to all other gateways or on the use of
+             network-specific broadcast mechanisms.  Polling procedures
+             (e.g., for consistency checking) must be used only
+             sparingly and in no case introduce an overhead exceeding a
+             constant, independent of network topology, times the
+             longest non-looping path.
+
+         7.  Default routes (generally intended as a means to reduce the
+             size of the routing data-base) must be used with care,
+             because of the many problems with multiple paths, loops,
+             and mis-configurations which routing defaults have caused.
+
+             The most common application of defaults is for routing
+             within an Internet region which is connected in a strictly
+             hierarchical fashion and is a stub from the rest of the
+             Internet system.  In this case, the default is used for
+             routing "up" the tree.  Unfortunately, such restricted
+             topology seldom lasts very long, and defaults cease to
+             work.
+
+             More generally, defaults could be used for initial routing
+             guesses, with final routes to be discovered and cached from
+             external or internal data-bases via the routing algorithm
+             or EGP.
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 31]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   4.2.  Subnets and Routing
+
+      We will call a gateway "subnetted" if at least one of its
+      interfaces is connected to a subnet; the set of gateways directly
+      connected to subnets of the same network will be referred to as a
+      "subnet cluster".  For example, in the following diagram, network
+      2 is subnetted, with subnets 2.1 and 2.2, but network 1 is not;
+      gateways 1, 2, and 3 are subnetted and are members of the same
+      subnet cluster.
+
+         (Net 1) === [Gwy 1] === (Net 2.1) === [Gwy 2] === (Net 2.2)
+            |                                                   |
+            |                                                   |
+             =================== [Gwy 3] =======================
+
+      Subnets have the following effects on gateway routing:
+
+         A.  Non-subnetted gateways are not affected at all.
+
+         B.  The routing data-base in a subnetted gateway must consider
+             the address mask for subnet entries.
+
+         C.  Routing updates among the gateways in the same subnet
+             cluster must include entries for the various subnets.  The
+             corresponding address mask(s) may be implicit, but for full
+             generality the mask needs to be given explicitly for each
+             entry.  Note that if the routing data-base included a full
+             32-bit mask for every IP network, the gateway could deal
+             with networks and subnets in a natural way.  This would
+             also handle the case of multiple subnet masks for the same
+             subnetted network.
+
+         D.  Routing updates from a subnetted gateway to a gateway
+             outside the cluster can contain nets, never subnets.
+
+         E.  If a subnetted gateway (e.g., gateway 2 above) is unable to
+             forward a datagram from one subnet to another subnet of the
+             same network, then it must return a Host Unreachable, not a
+             Net Unreachable, as discussed in Section 2.2.1.
+
+      When considering the choice of routing protocol, a gateway builder
+      must consider how that protocol generalizes for subnets.  For some
+      routing protocols it will be possible to use the same procedures
+      in a regular gateway and a subnetted gateway, with only a change
+      of parameters (e.g., address masks).
+
+      A different subnet address mask must be configurable for each
+
+
+
+Braden & Postel                                                [Page 32]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      interface of a given gateway.  This will allow a subnetted gateway
+      to connect to two different subnetted networks, or to connect two
+      subnets of the same network with different masks.
+
+   4.3   Resource Allocation
+
+      In order to perform its basic datagram-forwarding functions, a
+      gateway must allocate resources; its packet buffers and CPU time
+      must be allocated to packets it receives from connected networks,
+      while the bandwidth to each of the networks must also be allocated
+      for sending packets.  The choice of allocation strategies will be
+      critical when a particular resource is scarce.  The most obvious
+      allocation strategy, first-come-first-served (FCFS), may not be
+      appropriate under overload conditions, for reasons which we will
+      now explore.
+
+      A first example is buffer allocation.  It is important for a
+      gateway to allocate buffers fairly among all of its connected
+      networks, even if these networks have widely varying bandwidths.
+      A high-speed interface must not be allowed to starve slower
+      interfaces of buffers.  For example, consider a gateway with a
+      10 Mbps Ethernet connection and two 56 Kbps serial lines.  A buggy
+      host on the Ethernet may spray that gateway interface with packets
+      at high speed.  Without careful algorithm design in the gateway,
+      this could tie up all the gateway buffers in such a way that
+      transit traffic between the serial lines would be completely
+      stopped.
+
+      Allocation of output bandwidth may also require non-FCFS
+      strategies.  In an advanced gateway design, allocation of output
+      bandwidth may depend upon Type-of-Service bits in the IP headers.
+      A gateway may also want to give priority to datagrams for its own
+      up/down and routing protocols.
+
+      Finally, Nagle [24] has suggested that gateways implement "fair
+      queueing", i.e., sharing output bandwidth equitably among the
+      current traffic sources.  In his scheme, for each network
+      interface there would be a dynamically-built set of output queues,
+      one per IP source address; these queues would be serviced in a
+      round-robin fashion to share the bandwidth.  If subsequent
+      research shows fair queueing to be desirable, it will be added to
+      a future version of this document as a universal requirement.
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 33]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   4.4.  Special Addresses and Filters
+
+      Section 2.1 contained a list of the 32-bit IP addresses which have
+      special meanings.  They do not in general represent unique IP
+      addresses of Internet hosts, and there are restrictions on their
+      use in IP headers.
+
+      We can distinguish two classes of these special cases.  The first
+      class (specifically, cases (a), (b), (c), (g), (h), and (i) in
+      section 2.1) contains addresses which should never appear in the
+      destination address field of any IP datagram, so a gateway should
+      never be asked to route to one of these addresses.  However, in
+      the real world of imperfect implementations and configuration
+      errors, such bad destination addresses do occur.  It is the
+      responsibility of a gateway to avoid propagating such erroneous
+      addresses; this is especially important for gateways included in
+      the global interconnect system.  In particular, a gateway which
+      receives a datagram with one of these forbidden addresses should:
+
+         1.  Avoid inserting that address into its routing database, and
+             avoid including it in routing updates to any other gateway.
+
+         2.  Avoid forwarding a datagram containing that address as a
+             destination.
+
+      To enforce these restrictions, it is suggested that a gateway
+      include a configurable filter for datagrams and routing updates.
+      A typical filter entry might consist of a 32-bit mask and value
+      pair.  If the logical AND of the given address with the mask
+      equals the value, a match has been found.  Since filtering will
+      consume gateway resources, it is vital that the gateway
+      configuration be able to control the degree of filtering in use.
+
+      There is a second class of special case addresses (cases (d), (e),
+      and (f) in section 2.1), the so-called "directed broadcasts".  A
+      directed broadcast is a datagram to be forwarded normally to the
+      specified destination (sub-)net and then broadcast on the final
+      hop.  An Internet gateway is permitted, but not required, to
+      filter out directed broadcasts destined for any of its
+      locally-connected networks.  Hence, it should be possible to
+      configure the filter to block the delivery of directed broadcasts.
+
+      Finally, it will also be useful for Internet O&M to have a
+      configurable filter on the IP source address.  This will allow a
+      network manager to temporarily block traffic from a particular
+      misbehaving host, for example.
+
+
+
+
+Braden & Postel                                                [Page 34]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   4.5.  Redirects
+
+      The ICMP Redirect message is specified only for use by a gateway
+      to update the routing table of a host on the same connected net.
+      However, the Redirect message is sometimes used between gateways,
+      due to the following considerations:
+
+         The routing function in a host is very much like that in a
+         "dumb gateway" (i.e., a gateway having only static routes).  It
+         is desirable to allow the routing tables of a dumb gateway to
+         be changed under the control of a dynamic gateway (i.e., a
+         gateway with full dynamic routing) on the same network.  By
+         analogy, it is natural to let the dynamic gateway send ICMP
+         Redirect messages to dumb gateway.
+
+      The use of ICMP Redirect between gateways in this fashion may be
+      considered to be part of the IGP (in fact, the totality of the
+      IGP, as far as the dumb gateway is concerned!) in the particular
+      Autonomous System.   Specification of an IGP is outside the scope
+      of this document, so we only note the possibility of using
+      Redirect in this fashion.  Gateways are not required to receive
+      and act upon redirects, and in fact dynamic gateways must ignore
+      them.  We also note that considerable experience shows that dumb
+      gateways often create problems resulting in "black holes"; a full
+      routing gateway is always preferable.
+
+      Routing table entries established by redirect messages must be
+      removed automatically, either by a time-out or when a use count
+      goes to zero.
+
+   4.6.  Broadcast and Multicast
+
+      A host which is connected to a network (generally a LAN) with an
+      intrinsic broadcast capability may want to use this capability to
+      effect multidestination delivery of IP datagrams.  The basic
+      Internet model assumes point-to-point messages, and we must take
+      some care when we incorporate broadcasting.  It is important to
+      note that broadcast addresses may occur at two protocol levels:
+      the local network header and the IP header.
+
+      Incorrect handling of broadcasting has often been the cause of
+      packet avalanches (sometimes dubbed "meltdown") in LANs.  These
+      avalanches are generally caused by gratuitous datagram-forwarding
+      by hosts, or by hosts sending ICMP error messages when they
+      discard broadcast datagrams.
+
+      Gateways have a responsibility to prevent avalanches, or datagrams
+      which can trigger avalanches, from escaping into another network.
+
+
+Braden & Postel                                                [Page 35]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      In general, a gateway must not forward a datagram which arrives
+      via local network broadcast, and must not send an ICMP error
+      message when dropping the datagram.  A discussion of the rules
+      will be found in Appendix A; see also [50].
+
+      As noted in Section 4.4, a gateway is permitted to filter out
+      directed broadcasts.  Hence, directed broadcasts will only be
+      useful in limited Internet regions (e.g., the within the subnets
+      of a particular campus) in which delivery is supported by the
+      gateway administrators.  Host group multicasting (see Sections 2.8
+      and 4.6) will soon provide a much more efficient mechanism than
+      directed broadcasting.  Gateway algorithms for host group
+      multicasting will be specified in future RFC's.
+
+   4.7.  Reachability Procedures
+
+      The architecture must provide a robust mechanism to establish the
+      operational status of each link and node in the network, including
+      the gateways, the links connecting them and, where appropriate,
+      the hosts as well.  Ordinarily, this requires at least a
+      link-level reachability protocol involving a periodic exchange of
+      messages across each link.  This function might be intrinsic to
+      the link-level protocols used (e.g., LAPB).  However, it is in
+      general ill-advised to assume a host or gateway is operating
+      correctly even if its link-level reachability protocol is
+      operating correctly.  Additional confirmation is required in the
+      form of an operating routing algorithm or peer-level reachability
+      protocol (such as used in EGP).
+
+      Failure and restoration of a link and/or gateway are considered
+      network events and must be reported to the control center.  It is
+      desirable, although not required, that reporting paths not require
+      correct functioning of the routing algorithm itself.
+
+   4.8.  Time-To-Live
+
+      The Time-to-Live (TTL) field of the IP header is defined to be a
+      timer limiting the lifetime of a datagram in the Internet.  It is
+      an 8-bit field and the units are seconds.  This would imply that
+      for a maximum TTL of 255 a datagram would time-out after about 4
+      and a quarter minutes.  Another aspect of the definition requires
+      each gateway (or other module) that handles a datagram to
+      decrement the TTL by at least one, even if the elapsed time was
+      much less than a second.  Since this is very often the case, the
+      TTL effectively becomes a hop count limit on how far a datagram
+      can propagate through the Internet.
+
+
+
+
+Braden & Postel                                                [Page 36]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      As the Internet grows, the number of hops needed to get from one
+      edge to the opposite edge increases, i.e., the Internet diameter
+      grows.
+
+      If a gateway holds a datagram for more than one second, it must
+      decrement the TTL by one for each second.
+
+      If the TTL is reduced to zero, the datagram must be discarded, and
+      the gateway may send an ICMP Time Exceeded message to the source.
+      A datagram should never be received with a TTL of zero.
+
+      When it originates a datagram, a gateway is acting in the role of
+      a host and must supply a realistic initial value for the TTL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 37]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+5.  Operation and Maintenance
+
+   5.1.  Introduction
+
+      Facilities to support operation and maintenance (O&M) activities
+      form an essential part of any gateway implementation.  The
+      following kinds of activity are included under gateway O&M:
+
+         *  Diagnosing hardware problems in the gateway processor, in
+            its network interfaces, or in the connected networks,
+            modems, or communication lines.
+
+         *  Installing a new version of the gateway software.
+
+         *  Restarting or rebooting a gateway after a crash.
+
+         *  Configuring (or reconfiguring) the gateway.
+
+         *  Detecting and diagnosing Internet problems such as
+            congestion, routing loops, bad IP addresses, black holes,
+            packet avalanches, and misbehaved hosts.
+
+         *  Changing network topology, either temporarily (e.g., to
+            diagnose a communication line problem) or permanently.
+
+         *  Monitoring the status and performance of the gateways and
+            the connected networks.
+
+         *  Collecting traffic statistics for use in (Inter-)network
+            planning.
+
+      Gateways, packet-switches, and their connected communication lines
+      are often operated as a system by a centralized O&M organization.
+      This organization will maintain a (Inter-)network operation
+      center, or NOC, to carry out its O&M functions.  It is essential
+      that gateways support remote control and monitoring from such a
+      NOC, through an Internet path (since gateways might not be
+      connected to the same network as their NOC).  Furthermore, an IP
+      datagram traversing the Internet will often use gateways under the
+      control of more than one NOC; therefore, Internet problem
+      diagnosis will often involve cooperation of personnel of more than
+      one NOC.  In some cases, the same gateway may need to be monitored
+      by more than one NOC.
+
+      The tools available for monitoring at a NOC may cover a wide range
+      of sophistication.  Proposals have included multi-window, dynamic
+      displays of the entire gateway system, and the use of AI
+      techniques for automatic problem diagnosis.
+
+
+Braden & Postel                                                [Page 38]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      Gateway O&M facilities discussed here are only a part of the large
+      and difficult problem of Internet management.  These problems
+      encompass not only multiple management organizations, but also
+      multiple protocol layers.  For example, at the current stage of
+      evolution of the Internet architecture, there is a strong coupling
+      between host TCP implementations and eventual IP-level congestion
+      in the gateway system [9].  Therefore, diagnosis of congestion
+      problems will sometimes require the monitoring of TCP statistics
+      in hosts.  Gateway algorithms also interact with local network
+      performance, especially through handling of broadcast packets and
+      ARP, and again diagnosis will require access to hosts (e.g.,
+      examining ARP caches).  However, consideration of host monitoring
+      is beyond the scope of this RFC.
+
+      There are currently a number of R&D efforts in progress in the
+      area of Internet management and more specifically gateway O&M.  It
+      is hoped that these will lead quickly to Internet standards for
+      the gateway protocols and facilities required in this area.  This
+      is also an area in which vendor creativity can make a significant
+      contribution.
+
+   5.2.   Gateway O&M Models
+
+      There is a range of possible models for performing O&M functions
+      on a gateway.  At one extreme is the local-only model, under which
+      the O&M functions can only be executed locally, e.g., from a
+      terminal plugged into the gateway machine.  At the other extreme,
+      the fully-remote model allows only an absolute minimum of
+      functions to be performed locally (e.g., forcing a boot), with
+      most O&M being done remotely from the NOC.  There intermediate
+      models, e.g., one in which NOC personnel can log into the gateway
+      as a host, using the Telnet protocol, to perform functions which
+      can also be invoked locally.  The local-only model may be adequate
+      in a few gateway installations, but in general remote operation
+      from a NOC will be required, and therefore remote O&M provisions
+      are required for most gateways.
+
+      Remote O&M functions may be exercised through a control agent
+      (program).  In the direct approach, the gateway would support
+      remote O&M functions directly from the NOC using standard Internet
+      protocols (e.g., UDP or TCP); in the indirect approach, the
+      control agent would support these protocols and control the
+      gateway itself using proprietary protocols.  The direct approach
+      is preferred, although either approach is acceptable.  The use of
+      specialized host hardware and/or software requiring significant
+      additional investment is discouraged; nevertheless, some vendors
+      may elect to provide the control agent as an integrated part of
+      the network in which the gateways are a part.  If this is the
+
+
+Braden & Postel                                                [Page 39]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      case, it is required that a means be available to operate the
+      control agent from a remote site using Internet protocols and
+      paths and with equivalent functionality with respect to a local
+      agent terminal.
+
+      It is desirable that a control agent and any other NOC software
+      tools which a vendor provides operate as user programs in a
+      standard operating system.  The use of the standard Internet
+      protocols UDP and TCP for communicating with the gateways should
+      facilitate this.
+
+      Remote gateway monitoring and (especially) remote gateway control
+      present important access control problems which must be addressed.
+      Care must also be taken to ensure control of the use of gateway
+      resources for these functions.  It is not desirable to let gateway
+      monitoring take more than some limited fraction of the gateway CPU
+      time, for example.  On the other hand, O&M functions must receive
+      priority so they can be exercised when the gateway is congested,
+      i.e., when O&M is most needed.
+
+      There are no current Internet standards for the control and
+      monitoring protocols, although work is in progress in this area.
+      The Host Monitoring Protocol (HMP) [7] could be used as a model
+      until a standard is developed; however, it is strongly recommended
+      that gateway O&M protocol be built on top of one of the standard
+      Internet end-to-end protocols UDP or TCP. An example of a very
+      simple but effective approach to gateway monitoring is contained
+      in RFC-996 [43].
+
+   5.3.   Gateway O&M Functions
+
+      The following O&M functions need to be performed in a gateway:
+
+         A.  Maintenance -- Hardware Diagnosis
+
+            Each gateway must operate as a stand-alone device for the
+            purposes of local hardware maintenance.  Means must be
+            available to run diagnostic programs at the gateway site
+            using only on-site tools, which might be only a diskette or
+            tape and local terminal.  It is desirable, although not
+            required, to be able to run diagnostics or dump the gateway
+            via the network in case of fault.  Means should be provided
+            to allow remote control from the NOC of of modems attached
+            to the gateway.  The most important modem control capability
+            is entering and leaving loopback mode, to diagnose line
+            problems.
+
+
+
+
+Braden & Postel                                                [Page 40]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         B.  Control -- Dumping and Rebooting
+
+            It must be possible to dump and reboot a stand-alone gateway
+            upon command from the NOC.  In addition, a stand-alone
+            gateway must include a watchdog timer that either initiates
+            a reboot automatically or signals a remote control site if
+            not reset periodically by the software.  It is desirable
+            that the boot data involved reside at an Internet host
+            (e.g., the NOC host) and be transmitted via the net;
+            however, the use of local devices at the gateway site is
+            acceptable.
+
+         C.  Control -- Configuring the Gateway
+
+            Every gateway will have a number of configuration parameters
+            which must be set (see the next section for examples).  It
+            must be possible to update the parameters without rebooting
+            the gateway; at worst, a restart may be required.
+
+         D.  Monitoring -- Status and Performance
+
+            A mechanism must be provided for retrieving status and
+            statistical information from a gateway.  A gateway must
+            supply such information in response to a polling message
+            from the NOC.  In addition, it may be desirable to configure
+            a gateway to transmit status spontaneously and periodically
+            to a NOC (or set of NOCs), for recording and display.
+
+            Examples of interesting status information include: link
+            status, queue lengths, buffer availability, CPU and memory
+            utilization, the routing data-base, error counts, and packet
+            counts.  Counts should be kept for dropped datagrams,
+            separated by reason.  Counts of ICMP datagrams should be
+            kept by type and categorized into those originating at the
+            gateway, and those destined for the gateway.  It would be
+            useful to maintain many of these statistics by network
+            interface, by source/destination network pair, and/or by
+            source/destination host pair.
+
+            Note that a great deal of useful monitoring data is often to
+            be found in the routing data-base.  It is therefore useful
+            to be able to tap into this data-base from the NOC.
+
+         E.  Monitoring -- Error Logging
+
+            A gateway should be capable of asynchronously sending
+            exception ("trap") reports to one or more specified Internet
+            addresses, one of which will presumably be the NOC host.
+
+
+Braden & Postel                                                [Page 41]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+            There must also be a mechanism to limit the frequency of
+            such trap reports, and the parameters controlling this
+            frequency must be settable in the gateway configuration.
+
+            Examples of conditions which should result in traps include:
+            datagrams discarded because of TTL expiration (an indicator
+            of possible routing loops); resource shortages; or an
+            interface changing its up/down status.
+
+   5.4.   Gateway Configuration Parameters
+
+      Every gateway will have a set of configuration parameters
+      controlling its operation.  It must be possible to set these
+      parameters remotely from the NOC or locally at any time, without
+      taking the gateway down.
+
+      The following is a partial but representative list of possible
+      configuration parameters for a full-function gateway.  The items
+      marked with "(i)" should be settable independently for each
+      network interface.
+
+         * (i)  IP (sub-) network address
+
+         * (i)  Subnet address mask
+
+         * (i)  MTU of local network
+
+         * (i)  Hardware interface address
+
+         * (i)  Broadcast compatibility option (0s or 1s)
+
+         *      EGP parameters -- neighbors, Autonomous System number,
+                and polling parameters
+
+         *      Static and/or default routes, if any
+
+         *      Enable/Disable Proxy ARP
+
+         *      Source Quench parameters
+
+         *      Address filter configuration
+
+         *      Boot-host address
+
+         *      IP address of time server host
+
+         *      IP address(es) of logging host(s)
+
+
+
+Braden & Postel                                                [Page 42]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         *      IP address(es) of hosts to receive traps
+
+         *      IP address(es) of hosts authorized to issue control
+                commands
+
+         *      Error level for logging
+
+         *      Maximum trap frequency
+
+         *      Hold-down period (if any)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 43]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+Appendix A.  Technical Details
+
+   This Appendix collects a number of technical details and rules
+   concerning datagram forwarding by gateways and datagram handling by
+   hosts, especially in the presence of broadcasting and subnets.
+
+   A.1.  Rules for Broadcasting
+
+      The following rules define how to handle broadcasts of packets and
+      datagrams [50]:
+
+         a.  Hosts (which do not contain embedded gateways) must NEVER
+             forward any datagrams received from a connected network,
+             broadcast or not.
+
+             When a host receives an IP datagram, if the destination
+             address identifies the host or is an IP broadcast address,
+             the host passes the datagram to its appropriate
+             higher-level protocol module (possibly sending ICMP
+             protocol unreachable, but not if the IP address was a
+             broadcast address).  Any other IP datagram must simply be
+             discarded, without an ICMP error message.  Hosts never send
+             redirects.
+
+         b.  All packets containing IP datagrams which are sent to the
+             local-network packet broadcast address must contain an IP
+             broadcast address as the destination address in their IP
+             header.  Expressed in another way, a gateway (or host) must
+             not send in a local-network broadcast packet an IP datagram
+             that has a specific IP host address as its destination
+             field.
+
+         c.  A gateway must never forward an IP datagram that arrives
+             addressed to the IP limited broadcast address {-1,-1}.
+             Furthermore, it must must not send an ICMP error message
+             about discarding such a datagram.
+
+         d.  A gateway must not forward an IP datagram addressed to
+             network zero, i.e., {0, *}.
+
+         e.  A gateway may forward a directed broadcast datagram, i.e.,
+             a datagram with the IP destination address:
+
+            { <Network-number>, -1}.
+
+             However, it must not send such a directed broadcast out the
+             same interface it came in, if this interface has
+             <Network-number> as its network number.  If the code in the
+
+
+Braden & Postel                                                [Page 44]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+             gateway making this decision does not know what interface
+             the directed-broadcast datagram arrived on, the gateway
+             cannot support directed broadcast to this connected network
+             at all.
+
+         f.  A gateway is permitted to protect its connected networks by
+             discarding directed broadcast datagrams.
+
+      A gateway will broadcast an IP datagram on a connected network if
+      it is a directed broadcast destined for that network.  Some
+      gateway-gateway routing protocols (e.g., RIP) also require
+      broadcasting routing updates on the connected networks.  In either
+      case, the datagram must have an IP broadcast address as its
+      destination.
+
+         Note:  as observed earlier, some host implementations (those
+         based on Berkeley 4.2BSD) use zero rather than -1 in the host
+         field.  To provide compatibility during the period until these
+         systems are fixed or retired, it may be useful for a gateway to
+         be configurable to send either choice of IP broadcast address
+         and accept both if received.
+
+   A.2.  ICMP Redirects
+
+      A gateway will generate an ICMP Redirect if and only if the
+      destination IP address is reachable from the gateway (as
+      determined by the routing algorithm) and the next-hop gateway is
+      on the same (sub-)network as the source host.  Redirects must not
+      be sent in response to an IP network or subnet broadcast address
+      or in response to a Class D or Class E IP address.
+
+      A host must discard an ICMP Redirect if the destination IP address
+      is not its own IP address, or the new target address is not on the
+      same (sub-)network.  An accepted Redirect updates the routing
+      data-base for the old target address.  If there is no route
+      associated with the old target address, the Redirect is ignored.
+      If the old route is associated with a default gateway, a new route
+      associated with the new target address is inserted in the
+      data-base.
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 45]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+Appendix B.  NSFNET Specific Requirements
+
+   The following sections discuss certain issues of special concern to
+   the NSF scientific networking community.  These issues have primary
+   relevance in the policy area, but also have ramifications in the
+   technical area.
+
+   B.1.  Proprietary and Extensibility Issues
+
+      Although hosts, gateways and networks supporting Internet
+      technology have been in continuous operation for several years,
+      vendors users and operators must understand that not all
+      networking issues are fully resolved.  As a result, when new needs
+      or better solutions are developed for use in the NSF networking
+      community, it may be necessary to field new protocols or augment
+      existing ones.  Normally, these new protocols will be designed to
+      interoperate in all practical respects with existing protocols;
+      however, occasionally it may happen that existing systems must be
+      upgraded to support these new or augmented protocols.
+
+      NSF systems procurements may favor those vendors who undertake a
+      commitment to remain aware of current Internet technology and be
+      prepared to upgrade their products from time to time as
+      appropriate.  As a result, vendors are strongly urged to consider
+      extensibility and periodic upgrades as fundamental characteristics
+      of their products.  One of the most productive and rewarding ways
+      to do this on a long-term basis is to participate in ongoing
+      Internet research and development programs in partnership with the
+      academic community.
+
+   B.2.  Interconnection Technology
+
+      In order to ensure network-level interoperability of different
+      vendor's gateways within the NSFNET context, we specify that a
+      gateway must at a minimum support Ethernet connections and serial
+      line protocol connections.
+
+      Currently the most important common interconnection technology
+      between Internet systems of different vendors is Ethernet.  Among
+      the reasons for this are the following:
+
+         1.  Ethernet specifications are well-understood and mature.
+
+         2.  Ethernet technology is in almost all aspects vendor
+             independent.
+
+         3.  Ethernet-compatible systems are common and becoming more
+             so.
+
+
+Braden & Postel                                                [Page 46]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+      These advantages combined favor the use of Ethernet technology as
+      the common point of demarcation between NSF network systems
+      supplied by different vendors, regardless of technology.  It is a
+      requirement of NSF gateways that, regardless of the possibly
+      proprietary switching technology used to implement a given
+      vendor-supplied network, its gateways must support an Ethernet
+      attachment to gateways of other vendors.
+
+      It is expected that future NSF gateway requirements will specify
+      other interconnection technologies.  The most likely candidates
+      are those based on X.25 or IEEE 802, but other technologies
+      including broadband cable, optical fiber, or other media may also
+      be considered.
+
+   B.3.  Routing Interoperability
+
+      The Internet does not currently have an "open IGP" standard, i.e.,
+      a common IGP which would allow gateways from different vendors to
+      form a single Autonomous System.  Several approaches to routing
+      interoperability are currently in use among vendors and the NSF
+      networking community.
+
+      *  Proprietary IGP
+
+         At least one gateway vendor has implemented a proprietary IGP
+         and uses EGP to interface to the rest of the Internet.
+
+      *  RIP
+
+         Although RIP is undocumented and various implementations of it
+         differ in subtle ways, it has been used successfully for
+         interoperation among multiple vendors as an IGP.
+
+      *  Gateway Daemon
+
+         The NSF networking community has built a "gateway daemon"
+         program which can mediate among multiple routing protocols to
+         create a mixed-IGP Autonomous System.  In particular, the
+         prototype gateway daemon executes on a 4.3BSD machine acting as
+         a gateway and exchanges routing information with other
+         gateways, speaking both RIP and Hello protocols; in addition,
+         it supports EGP to other Autonomous Systems.
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 47]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   B.4.  Multi-Protocol Gateways
+
+      The present NSF gateway requirements specify only the Internet
+      protocol IP.  However, in a few years the Internet will begin a
+      gradual transition to the functionally-equivalent subset of the
+      ISO protocols [17].  In particular, an increasing percentage of
+      the traffic will use the ISO Connectionless Mode Network Service
+      (CLNS, but commonly called "ISO IP") [33] in place of IP.  It is
+      expected that the ISO suite will eventually become the dominant
+      one; however, it is also expected that requirements to support
+      Internet IP will continue, perhaps indefinitely.
+
+      To support the transition to ISO protocols and the coexistence
+      stage, it is highly desirable that a gateway design provide for
+      future extensions to support more than one protocol simultaneous,
+      and in particular both IP and CLNS [18].
+
+      Present NSF gateway requirements do not include protocols above
+      the network layer, such as TCP, unless necessary for network
+      monitoring or control.  Vendors should recognize that future
+      requirements to interwork between Internet and ISO applications,
+      for example, may result in an opportunity to market gateways
+      supporting multiple protocols at all levels up through the
+      application level [16].  It is expected that the network-level NSF
+      gateway requirements summarized in this document will be
+      incorporated in the requirements document for these
+      application-level gateways.
+
+      Internet gateways function as intermediate systems (IS) with
+      respect to the ISO connectionless network model and incorporate
+      defined packet formats, routing algorithms and related procedures
+      [33, 34].  The ISO ES-IS [37] provides the functions of ARP and
+      ICMP Redirect.
+
+   B.5.  Access Control and Accounting
+
+      There are no requirements for NSF gateways at this time to
+      incorporate specific access-control and accounting mechanisms in
+      the design;  however, these important issues are currently under
+      study and will be incorporated into a subsequent edition of this
+      document.  Vendors are encouraged to plan for the introduction of
+      these mechanisms into their products.  While at this time no
+      definitive common model for access control and accounting has
+      emerged, it is possible to outline some general features such a
+      model is likely to have, among them the following:
+
+
+
+
+
+Braden & Postel                                                [Page 48]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+         1.  The primary access control and accounting mechanisms will
+             be in the service hosts themselves, not the gateways,
+             packet-switches or workstations.
+
+         2.  Agents acting on behalf of access control and accounting
+             mechanisms may be necessary in the gateways, to collect
+             data, enforce password protection, or mitigate resource
+             priority and fairness.  However, the architecture and
+             protocols used by these agents may be a local matter and
+             cannot be specified in advance.
+
+         3.  NSF gateways may be required to incorporate access control
+             and accounting mechanisms based on datagram
+             source/destination address, as well as other fields in the
+             IP header.
+
+         4.  NSF gateways may be required to enforce policies on access
+             to gateway and communication resources.  These policies may
+             be based upon equity ("fairness") or upon inequity
+             ("priority").
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 49]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+Acknowledgments
+
+   An earlier version of this document (RFC-985) [60] was prepared by
+   Dave Mills in behalf of the Gateway Requirements Subcommittee of the
+   NSF Network Technical Advisory Group, in cooperation with the
+   Internet Activities Board, Internet Architecture Task Force, and
+   Internet Engineering Task Force.  This effort was chaired by Dave
+   Mills, and contributed to by many people.
+
+   The authors of current document have also received assistance from
+   many people in the NSF and ARPA networking community.  We thank you,
+   one and all.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 50]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+References and Bibliography
+
+   Many of these references are  available from the DDN Network
+   Information Center, SRI International, 333 Ravenswood Avenue, Menlo
+   Park, California 94025 (telephone: 800-235-3155).
+
+   [1]   Postel, J., "Internet Protocol", RFC-791, USC Information
+         Sciences Institute, September 1981.
+
+   [2]   Postel, J., "Internet Control Message Protocol", RFC-792, USC
+         Information Sciences Institute, September 1981.
+
+   [3]   BBN, "Interface Message Processor - Specifications for the
+         Interconnection of a Host and an IMP", Report 1822, Bolt
+         Beranek and Newman, December 1981.
+
+   [4]   Plummer, D., "An Ethernet Address Resolution Protocol",
+         RFC-826, Symbolics, September 1982.
+
+   [5]   DOD, "Military Standard Internet Protocol", Military Standard
+         MIL-STD-1777, United States Department of Defense, August 1983.
+
+   [6]   BBN, "Defense Data Network X.25 Host Interface Specification",
+         Report 5476, Bolt Beranek and Newman, December 1983.
+
+   [7]   Hinden, R., "A Host Monitoring Protocol", RFC-869, BBN
+         Communications, December 1983.
+
+   [8]   Korb, J.T., "A Standard for the Transmission of IP Datagrams
+         over Public Data Networks", RFC-877, Purdue University,
+         September 1983.
+
+   [9]   Nagle, J., "Congestion Control in IP/TCP Internetworks",
+         RFC-896, Ford Aerospace, January 1984.
+
+   [10]  Hornig, C., "A Standard for the Transmission of IP Datagrams
+         over Ethernet Networks", RFC-894, Symbolics, April 1984.
+
+   [11]  Mills, D.L., "Exterior Gateway Formal Specification", RFC-904,
+         M/A-COM Linkabit, April 1984.
+
+   [12]  Xerox, "Xerox Synchronous Point-to-Point Protocol", Xerox
+         System Integration Standard 158412, December 1984.
+
+   [13]  Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", RFC-911, USC
+         Information Sciences Institute, August 1984.
+
+
+
+
+Braden & Postel                                                [Page 51]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   [14]  Postel, J., "Multi-LAN Address Resolution", RFC-925, USC
+         Information Sciences Institute, October 1984.
+
+   [15]  Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse
+         Address Resolution Protocol", RFC-904, Stanford University,
+         June 1984.
+
+   [16]  NRC, "Transport Protocols for Department of Defense Data
+         Networks", RFC-942, National Research Council, March 1985.
+
+   [17]  Postel, J., "DOD Statement on NRC Report", RFC-945, USC
+         Information Sciences Institute, April 1985.
+
+   [18]  ISO, "Addendum to the Network Service Definition Covering
+         Network Layer Addressing", RFC-941, International Standards
+         Organization, April 1985.
+
+   [19]  Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA
+         Internet Protocol Suite", Proceedings INFOCOM 85, IEEE,
+         Washington DC, March 1985.  Also in: IEEE Communications
+         Magazine, March 1985.  Also available as ISI-RS-85-153.
+
+   [20]  Romkey, J., "PC/IP Programmer's Manual", MIT Laboratory for
+         Computer Science, pp. 57-59, April 1986.
+
+   [21]  Mogul, J., and J. Postel, "Internet Standard Subnetting
+         Procedure", RFC-950, Stanford University, August 1985.
+
+   [22]  Reynolds, J., and J. Postel, "Official Internet Protocols",
+         RFC-1011, USC Information Sciences Institute, May 1987.
+
+   [23]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1010, USC
+         Information Sciences Institute, May 1987.
+
+   [24]  Nagle, J., "On Packet Switches with Infinite Storage", RFC-970,
+         Ford Aerospace, December 1985.
+
+   [25]  SRI, "DDN Protocol Handbook", NIC-50004, NIC-50005, NIC-50006,
+         (three volumes), SRI International, December 1985.
+
+   [26]  SRI, "ARPANET Information Brochure", NIC-50003, SRI
+         International, December 1985.
+
+   [27]  Mills, D.L., "Autonomous Confederations", RFC-975, M/A-COM
+         Linkabit, February 1986.
+
+   [28]  Jacobsen, O., and J. Postel, "Protocol Document Order
+         Information",  RFC-980, SRI International, March 1986.
+
+
+Braden & Postel                                                [Page 52]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   [29]  Malis, A.G., "PSN End-to-End Functional Specification",
+         RFC-979, BBN Communications, March 1986.
+
+   [30]  Postel, J, "Internetwork Applications using the DARPA Protocol
+         Suite", Proceedings INFOCOM 85, IEEE, Washington DC,
+         March 1985.  Also available as ISI-RS-85-151.
+
+   [31]  Postel, J, C. Sunshine, and D. Cohen, "The ARPA Internet
+         Protocol", Computer Networks, Vol. 5, No. 4, July 1981.
+
+   [32]  Cerf, V., and R. Kahn, "A Protocol for Packet Network
+         Intercommunication", IEEE Transactions on Communication,
+         May 1974.
+
+   [33]  ISO, "Protocol for Providing the Connectionless-mode Network
+         Service", RFC-994, DIS-8473, International Standards
+         Organization, March 1986.
+
+   [34]  ANSI, "Draft Network Layer Routing Architecture", ANSI X3S3.3,
+         86-215R, April 1987.
+
+   [35]  Rosen, E., "Exterior Gateway Protocol (EGP)", RFC-827, Bolt
+         Beranek and Newman, October 1982.
+
+   [36]  Sidhu, D., "Some Problems with the Specification of the
+         Military Standard Internet Protocol", RFC-963, Iowa State
+         University, November 1985.
+
+   [37]  ISO, "End System to Intermediate System Routing Exchange
+         Protocol for use in conjunction with ISO 8473", RFC-995,
+         April 1986.
+
+   [38]  Postel, J., "Address Mappings", RFC-796, USC/Information
+         Sciences Institute, September 1981.
+
+   [39]  Mills, D., "DCN Local Network Protocols", RFC-891, M/A-COM
+         Linkabit, December 1983.
+
+   [40]  McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing
+         Algorithm for the ARPANET",  IEEE Transactions on
+         Communications, May 1980.
+
+   [41]  Hinden, R., and A. Sheltzer, "The DARPA Internet Gateway",
+         RFC-823, Bolt Beranek and Newman, September 1982.
+
+   [42]  Farber, D., G. Delp, and T. Conte, "A Thinwire Protocol for
+         Connecting Personal Computers to the Internet", RFC-914,
+         University of Delaware, September 1984.
+
+
+Braden & Postel                                                [Page 53]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   [43]  Mills, D., "Statistics Server", RFC-996, University Of
+         Delaware, February 1987.
+
+   [44]  Postel, J. and K. Harrenstien, "Time Protocol", RFC-868,
+         May 1983.
+
+   [45]  Mills, D., "Network Time Protocol (NTP)", RFC-958, M/A-Com
+         Linkabit, September 1985.
+
+   [46]  Seamonson, L., and E. Rosen, "Stub Exterior Gateway Protocol",
+         RFC-888, Bolt Beranek And Newman, January 1984.
+
+   [47]  Deering, S., and D. Cheriton, "Host Groups: A Multicast
+         Extension to the Internet Protocol", RFC-966, Stanford
+         University, December 1985.
+
+   [48]  Deering, S., "Host Extensions for IP Multicasting", RFC-988,
+         Stanford University, July 1986.
+
+   [49]  Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford
+         University, October 1984.
+
+   [50]  Mogul, J., "Broadcasting Internet Datagrams in the Presence of
+         Subnets", RFC-922, Stanford University, October 1984.
+
+   [51]  Rosen, E., "Exterior Gateway Protocol", RFC-827, Bolt Beranek
+         and Newman, October 1982.
+
+   [52]  Rose, M., "Low Tech Connection into the ARPA Internet: The Raw
+         Packet Split Gateway", Technical Report 216, Department of
+         Information and Computer Science, University of California,
+         Irvine, February 1984.
+
+   [53]  Rosen, E., "Issues in Buffer Management", IEN-182, Bolt Beranek
+         and Newman, May 1981.
+
+   [54]  Rosen, E., "Logical Addressing", IEN-183, Bolt Beranek and
+         Newman, May 1981.
+
+   [55]  Rosen, E., "Issues in Internetting - Part 1: Modelling the
+         Internet", IEN-184, Bolt Beranek and Newman, May 1981.
+
+   [56]  Rosen, E., "Issues in Internetting - Part 2: Accessing the
+         Internet", IEN-187, Bolt Beranek and Newman, June 1981.
+
+   [57]  Rosen, E., "Issues in Internetting - Part 3: Addressing",
+         IEN-188, Bolt Beranek and Newman, June 1981.
+
+
+
+Braden & Postel                                                [Page 54]
+
+
+
+RFC 1009 - Requirements for Internet Gateways                  June 1987
+
+
+   [58]  Rosen, E., "Issues in Internetting - Part 4: Routing", IEN-189,
+         Bolt Beranek and Newman, June 1981.
+
+   [59]  Sunshine, C., "Comments on Rosen's Memos", IEN-191, USC
+         Information Sciences Institute, July 1981.
+
+   [60]  NTAG, "Requirements for Internet Gateways -- Draft", RFC-985,
+         Network Technical Advisory Group, National Science Foundation,
+         May 1986.
+
+   [61]  Khanna, A., and Malis, A., "The ARPANET AHIP-E Host Access
+         Protocol (Enhanced AHIP)", RFC-1005, BBN Communications,
+         May 1987
+
+   [62]  Nagle, J., "Congestion Control in IP/TCP Internetworks", ACM
+         Computer Communications Review, Vol.14, no.4, October 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braden & Postel                                                [Page 55]