Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1009

Requirements for Internet gateways

Pages: 54
Obsoletes:  0985
Obsoleted by:  1812
Part 2 of 2 – Pages 25 to 54
First   Prev   None

ToP   noToC   RFC1009 - Page 25   prevText
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.
ToP   noToC   RFC1009 - Page 26
      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.
ToP   noToC   RFC1009 - Page 27
   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.
ToP   noToC   RFC1009 - Page 28
      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].
ToP   noToC   RFC1009 - Page 29
      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].
ToP   noToC   RFC1009 - Page 30
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
ToP   noToC   RFC1009 - Page 31
             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.
ToP   noToC   RFC1009 - Page 32
   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
ToP   noToC   RFC1009 - Page 33
      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.
ToP   noToC   RFC1009 - Page 34
   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.
ToP   noToC   RFC1009 - Page 35
   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.
ToP   noToC   RFC1009 - Page 36
      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.
ToP   noToC   RFC1009 - Page 37
      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.
ToP   noToC   RFC1009 - Page 38
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.
ToP   noToC   RFC1009 - Page 39
      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
ToP   noToC   RFC1009 - Page 40
      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.
ToP   noToC   RFC1009 - Page 41
         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.
ToP   noToC   RFC1009 - Page 42
            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)
ToP   noToC   RFC1009 - Page 43
         *      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)
ToP   noToC   RFC1009 - Page 44
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
ToP   noToC   RFC1009 - Page 45
             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.
ToP   noToC   RFC1009 - Page 46
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.
ToP   noToC   RFC1009 - Page 47
      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.
ToP   noToC   RFC1009 - Page 48
   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:
ToP   noToC   RFC1009 - Page 49
         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").
ToP   noToC   RFC1009 - Page 50
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.
ToP   noToC   RFC1009 - Page 51
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.
ToP   noToC   RFC1009 - Page 52
   [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.
ToP   noToC   RFC1009 - Page 53
   [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.
ToP   noToC   RFC1009 - Page 54
   [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.
ToP   noToC   RFC1009 - Page 55
   [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.