As per Relevance of the word datagram, we have this rfc below:
Network Working Group Network Technical Advisory
Request for Comments: 985
May 1986
Requirements for Internet Gateways --
Status of this
This RFC summarizes the requirements for gateways to be used
networks supporting the DARPA Internet protocols. While it
specifically to National Science Foundation research programs,
requirements are stated in a general context and are
applicable throughout the Internet community. This document
prepared by the Gateway Requirements Subcommittee of the NSF
Technical Advisory Group in cooperation with the Internet
Board, Internet Architecture Task Force and Internet Engineering
Force. It requests discussion and suggestions for improvements
Distribution of this memo is unlimited
The purpose of this document is to present guidance for
offering products that might be used or adapted for use in
Internet application. It enumerates the protocols required and
references to RFCs and other documents describing the
specifications. In a number of cases the specifications are
and may contain ambiguous or incomplete information. In these
further discussion giving specific guidance is included in
document. Specific policy issues relevant to the NSF
networking community are summarized in an Appendix
*********************************************************************
This is a DRAFT edition of this statement of gateway requirements
Comments are sought on this document for consideration
possibly incorporated in the final edition. Comments
especially sought from those actually developing gateways
particular vendors and potential vendors of gateways. The
for comments is 90 days ending 15-Aug-86, at which time
edition will be issued with a new RFC number
*********************************************************************
Suggestions and comments on this document can be sent to
subcommittee chairman Dave Mills (mills@usc-isid.arpa), or
committee chairman Dave Farber (farber@huey.udel.edu).
subcommittee members, present affiliations and Internet mailboxes
as follows
Hank Dardy, NRL dardy@nrl.
Dave Farber, U Delaware farber@huey.udel.
Dennis Jennings, JVNC jennings%pucc.bitnet@wiscvm.wisc.
NTAG [Page 1]
RFC 985 May 1986
Requirements for Internet Gateways --
Larry Landweber, U Wisconsin landweber@rsch.wisc.
Tony Lauck, DEC rhea!bergil!lauck@decwrl.
Dave Mills (Chairman), Linkabit mills@usc-isid.
Dennis Perry, DARPA/IPTO perry@ipto.
The subcommittee wishes to thank the following
contributors and invited referees
Len Bosack, Stanford U/CISCO bosack@su-score.
Bob Braden, ISI braden@isi-braden.
Hans-Werner Braun, U Michigan hwb@gw.umich.
Noel Chiappa, MIT/Proteon jnc@proteon.
Doug Comer, Purdue U dec@cs.purdue.
Ira Fuchs, Princeton U fuchs%pucc.bitnet@wiscvm.wisc.
Ed Krol, U Illinois krol%uiucvmd.bitnet@wiscvm.wisc.
Barry Leiner, RIACS leiner@riacs.
Mike Muuss, BRL mike@brl.
Ron Natalie, BRL ron@brl.
Harvey Newman, CIT newman@cit-hex.
Jon Postel, ISI postel@usc-isib.
Marshall Rose, NRTC mrose@nrtc-gremlin.northrop.
Jeff Schiller, MIT jis@bitsy.mit.
Lixia Zhang, MIT lixia@xx.lcs.mit.
1.
The following sections are intended as an introduction and
for those unfamiliar with the DARPA Internet architecture and
Internet gateway model. General background and discussion on
Internet architecture and supporting protocol suite can be found
the DDN Protocol Handbook [25] and ARPANET Information Brochure [26],
both available from the Network Information Center,
International, Menlo Park, CA 94025. Readers familiar with
concepts can proceed directly to Section 2.
1.1. The DARPA Internet
The DARPA Internet system consists of a number of gateways
networks that collectively provide packet transport for
subscribing to the DARPA Internet protocol architecture.
protocols include the Internet Protocol (IP), Internet
Message Protocol (ICMP), Transmission Control Protocol (TCP)
application protocols depending upon them. All protocols use
as the basic packet-transport mechanism. IP is a datagram,
connectionless, service and includes provision for
specification, fragmentation/reassembly and security information
ICMP is considered an integral part of IP, although it
NTAG [Page 2]
RFC 985 May 1986
Requirements for Internet Gateways --
architecturally layered upon it. ICMP provides error reporting
flow control and first-hop gateway redirection. Reliable
delivery is provided in the protocol suite by TCP, which
end-end retransmission, resequencing and connection control
Connectionless service is provided by the User Datagram
(UDP).
The Internet community presently includes several thousand
connected to over 400 networks with about 120 gateways. There
now well over 2400 hosts registered in the ARPA domain alone
an unknown number registered in other domains, with the
increasing at about ten percent each month. Many of the hosts
gateways and networks in the Internet community are
by civil organizations, including universities,
laboratories and equipment manufacturers. Most of the
are administered by the US DoD and considered part of the
Internet, which presently consists of three sets of networks:
experimental segment, or ARPANET, the unclassified segment,
MILNET, and the classified segment, which does not yet have
collective name
The Internet model includes constituent networks, called
networks to distinguish them from the Internet system as a whole
which are required only to provide datagram (connectionless
transport. This requires only best-effort delivery of
packets, or datagrams. Each datagram carries 32-bit source
destination addresses, which are encoded in three
providing a two-part address, one of which is the local-
number and the other the host number on that local net.
to the Internet service specification, datagrams can be
out of order, be lost or duplicated and/or contain errors.
those networks providing connection-oriented service the
reliability provided by virtual circuits enhances the end-
robustness of the system, but is not strictly necessary
Local networks are connected together in the Internet model
means of Internet gateways. These gateways provide
transport only and normally seek to minimize the state
necessary to sustain this service in the interest of
flexibility and robustness. In the conventional model the
has a physical interface and address on each of the local
between which it provides forwarding services. The gateway
participates in one or more distributed routing or
algorithm such as the Gateway-Gateway Protocol (GGP) or
Gateway Protocol (EGP) in order to maintain its routing tables
NTAG [Page 3]
RFC 985 May 1986
Requirements for Internet Gateways --
1.2. The Internet Gateway
An Internet gateway is a self-contained, stand-alone packet
that performs the following functions
1. Interfaces to two or more packet-switching networks
including encapsulation, address transformation and
control
2. Conforms to specific DARPA Internet protocols specified
this document, including the Internet Protocol (IP),
Internet Control Message Protocol (ICMP), Exterior
Protocol (EGP) and others as necessary
3. Supports an interior gateway protocol (IGP) reachability
routing algorithm in cases of multiple gateways
as a system. Supports the EGP reachability algorithm
exchange routes between systems, in particular the
"core" system operated by BBN
4. Receives and forwards Internet datagrams consistent
good engineering practice in the management of resources
congestion control and fairness. Recognizes various
conditions and generates ICMP error and
messages as required
5. Provides system support facilities, including loading
debugging, status reporting, exception reporting
control
In some configurations gateways may be connected
packet-switching local nets that provide generic local-
routing, error-control and resource-management functions.
others gateways may be directly connected via serial lines,
that these functions must be provided by the gateways themselves
There are three typical scenarios that should be addressed
gateway vendors
1. National or regional network. Gateways of this
should be capable of switching multiple continuous flows
the 1.5-Mbps range at rates to several thousand packets
second. They will be high-performance, possibly redundant
multiple-processor devices, probably procured as a
and operated remotely from a regional or
monitoring center. The design of these gateways
emphasize high aggregate throughput, throughput-
NTAG [Page 4]
RFC 985 May 1986
Requirements for Internet Gateways --
resource management and very high reliability. The
application would be an NSF backbone net or one of
consortium or regional nets
2. Campus network. Gateways of this class should be
of switching some burst flows at 10-Mbps (Ethernets, etc.),
together with some flows in the 64-Kbps range or lower,
rates to perhaps several thousand packets per second.
will be medium-performance devices, probably
procured from different vendors for each campus
operated from a campus computing center. The design
these gateways should emphasize low average delay and
burst performance, together with delay and type-of-
sensitive resource management. Their chief function
be to interconnect various LANs and campus
resources, including a high-speed interconnect to
national or regional net. An important factor will be
very flexible routing mechanism, since these gateways
have to select among several backbone nets based
cost/performance considerations
3. Department network. Gateways of this class should
capable of switching a small number of burst flows
10-Mbps (Ethernets, etc.), together with a small number
flows in the range 64-Kbps or lower, at rates of a
hundred packets per second. They will
medium-performance devices procured from a variety
vendors and used for protocol-matching, LAN repeaters
as general utility packet switches. They will probably
locally maintained by the various users and not be used
transit switches
It is important to realize that Internet gateways normally
in an unattended mode, but that equipment and software faults
affect the entire Internet. While some of the above
involve positive control of some gateways from a
center, usually via a path involving other networks and
gateways, others may involve much less formal control procedures
Thus the gateways must be highly robust and be expected
operate, possibly in a degraded state, under conditions of
congestion or failure of network resources
NTAG [Page 5]
RFC 985 May 1986
Requirements for Internet Gateways --
2. Protocols
The Internet architecture uses datagram gateways to
networks and subnetworks. These gateways function as
systems (IS) with respect to the ISO connectionless network model
incorporate defined packet formats, routing algorithms and
procedures. In the following it is assumed the
implementation supports the full protocol, including all
options, with exceptions only as noted
2.1. Internet Protocol (IP
This is the basic datagram protocol used in the Internet system
It is described in RFC-791 [1] and also MIL-STD-1777 [5], both
which are intended to describe the same standard, but in
different words
With respect to current gateway requirements the following can
ignored, although they may be required in future: Type of
field, Security option, Stream ID option and Timestamp option
However, if recognized, the interpretation of these
must conform to the standard specification
Note that the Internet gateway model does not require that
gateway reassemble IP datagrams with destination address
than the gateway itself. However, in the case of those
in which the gateway directly participates as a peer,
routing and monitor/control protocols, the gateway may have
reassemble datagrams addressed to it. This consideration is
pertinent to EGP
Note that, of the five classes of IP addresses. Class-A
Class-E, Class-D and Class-E addresses are reserved
experimental use. A gateway which is not participating in
experiments should ignore all packets with a Class-D or Class-
destination IP address. No ICMP Destination Unreachable or
Redirect messages should result from receiving such packets
2.2. Internet Control Message Protocol (ICMP
This is an auxiliary protocol used to convey advice and
messages and is described in RFC-792 [2].
The distinction between subnets of a subnetted network,
depends on an arbitrary mask as described in RFC-950 [21], is
general not visible outside that network. This distinction
important in the case of certain ICMP messages, including the
NTAG [Page 6]
RFC 985 May 1986
Requirements for Internet Gateways --
Destination Unreachable and ICMP Redirect messages. The
Destination Unreachable message is sent by a gateway in
to a datagram which cannot be forwarded because the destination
unreachable or down. A choice of several types of these
is available, including one designating the destination
and another the destination host. However, the span of
implied by the former is ill-defined unless the subnet mask
known to the sender, which is in general not the case. It
recommended that use of the ICMP Destination Network
messages be avoided. Instead, an ICMP Destination
Unreachable message should be sent for each distinct
IP address
The ICMP Redirect message is sent by a gateway to a host in
to change the address used by the host for a designated host
net. A choice of four types of messages is available,
on whether it applies to a particular host, network or service
As in the previous case, these distinctions may depend upon
subnet mask. As in the above case, it is recommended that the
of ICMP messages implying a span of addresses (e.g.
unreachable, net redirect) be avoided in favor of those
specific addresses (e.g. host unreachable, host redirect).
The ICMP Source Quench message has been the subject of
controversy. It is not considered realistic at this time
specify in detail the conditions under which this message is to
generated or interpreted by a host or gateway
New host and gateway implementations are expected to support
ICMP Address Mask messages described in RFC-950. It is
desirable, although not required, to provide correct data for
Timestamp messages, which have been found useful in
debugging and maintenance
2.3. Exterior Gateway Protocol (EGP
This is the basic protocol used to exchange information
gateway systems of the Internet and is described in RFC-904 [11].
However, EGP as presently specified is an asymmetric protocol
only the "non-core" procedures defined in RFC-904. There are
present no "core" procedures specified, which would be
for a stand-alone Internet. RFC-975 [27] suggests
modifications leading to a symmetric model; however, this is
an official specification
In principle, a stand-alone Internet can be built with non-
EGP gateways using the EGP distance field to convey some
NTAG [Page 7]
RFC 985 May 1986
Requirements for Internet Gateways --
such as hop count. However, the use of EGP in this way as
routing algorithm is discouraged, since typical
adapt very slowly to changing topology and have no loop-
features
The EGP model requires each gateway belong to an autonomous
of gateways. If a routing algorithm is operated in one or
gateways of an autonomous system, its data base must be coupled
the EGP implementation in such a way that, when a net is
down by the routing algorithm, the net is also declared down
EGP to other autonomous systems. This requirement is designed
minimize spurious traffic to "black holes" and insure
utilization of the resources on other systems
There are no peer-discovery or authentication procedures
in the present EGP specification and no defined interpretation
the distance fields in the update messages, although
procedures may be defined in future (see RFC-975). There
currently no guidance on the selection of polling parameters
no specific recovery procedures in case of certain error
(e.g. "administratively prohibited"). It is recommended that
implementations include provisions to initialize these
as part of the monitoring and control procedures and that
these procedures not require recompilation or rebooting
gateway
2.4. Address Resolution Protocol (ARP
This is an auxiliary protocol used to manage
address-translation function between hardware addresses in
local-net environment and Internet addresses and described
RFC-826 [4]. However, there are a number of unresolved
having to do with subnets and response to addresses not in
same subnet or net. These issues, which are intertwined with
and various gateway models, are discussed in Appendix A
3.
The concept of subnets was introduced in order to allow
complexity of interconnected LAN structures within an organization
while insulating the Internet system against explosive growth
network numbers and routing complexity. The subnet architecture
described in RFC-950 [21], is intended to specify a standard
that does not require reconfiguration for host implementations
regardless of subnetting scheme. The document also specifies a
NTAG [Page 8]
RFC 985 May 1986
Requirements for Internet Gateways --
ICMP Address Mask message, which a gateway can use to specify
details of the subnetting scheme to hosts and is required in new
and gateway implementations
The current subnet specification RFC-950 does not describe
specific procedures to be used by the gateway, except by implication
It is recommended that a (sub)net address and address mask
provided for each network interface and that these values
established as part of the gateway configuration procedure. It
not usually necessary to change these values during operation of
particular gateway; however, it should be possible to add
gateways and/or (sub)nets and make other configuration changes to
gateway without taking the entire network down
4. Local Network
The packet format used for transmission of datagrams on the
subnetworks is described in a number of documents summarized below
4.1. Public data networks via X.25
The formats specified for public data networks via X.25 access
described in RFC-877 [8]. Datagrams are transmitted over
level-3 virtual circuits as complete packet sequences.
circuits are usually established dynamically as required and
out after a period of no traffic. Retransmission,
and flow control are performed by the network for each
circuit and by the LAPB link-level protocol. Multiple
virtual circuits are often used in order to improve
utilization of the subscriber access line, which can result
random resequencing. The correspondence between Internet
X.121 addresses is usually established by table-lookup. It
expected that this will be replaced by some sort of
procedure in future
4.2. ARPANET via 1822 Local Host, Distant Host or HDLC Distant
The formats specified for ARPANET networks via 1822 access
described in BBN Report 1822 [3], which includes the
for several subscriber access methods. The Local Host (LH)
Very Distant Host (VDH) methods are not recommended for
implementations. The Distant Host (DH) method is used when
host and IMP are separated by not more than about 2000 feet
cable, while the HDLC Distant Host is used for greater
where a modem is required. Retransmission, resequencing and
control are performed by the network and by the HDLC link-
protocol, when used. While the ARPANET 1822 protocols are
NTAG [Page 9]
RFC 985 May 1986
Requirements for Internet Gateways --
used at present, they are expected to be eventually overtaken
the DDN Standard X.25 protocol (see below) and the new
End-to-End Protocol described in RFC-979 [29].
While the cited report gives details of the various
subscriber access methods, it specifies neither the IP
encapsulation format nor address mappings. While these
generally straightforward and easy to implement, the
involve considerations beyond the scope of readily
documentation. Potential vendors are encouraged to contact one
the individuals listed at the beginning of this document
further information
Gateways connected to ARPANET/MILNET IMPs must
features to avoid host-port blocking (RFNM counting) and to
and report (as ICMP Unreachable messages) the failure
destination hosts or gateways
4.3. ARPANET via DDN Standard X.25
The formats specified for ARPANET networks via X.25 are
in the Defense Data Network X.25 Host Interface Specification [6].
This document describes two sets of procedures, the DDN Basic X.25
and the DDN Standard X.25, but only the latter is suitable for
in the Internet system. The DDN Standard X.25 procedures
similar to the public data subnetwork X.25 procedures, except
the address mappings. Retransmission, resequencing and
control are performed by the network and by the LAPB link-
protocol
4.4.
The formats specified for Ethernet networks are described
RFC-894 [10]. Datagrams are encapsulated as Ethernet packets
48-bit source and destination address fields and a 16-bit
field. Address translation between Ethernet addresses and
addresses is managed by the Address Resolution Protocol, which
required in all Ethernet implementations. There is no
retransmission, resequencing or flow control. although
hardware interfaces will retransmit automatically in case
collisions on the cable
It is expected that amendments will be made to this
as the result of IEEE 802.3 evolution. See RFC-948 [20]
further discussion and recommendations in this area. Note
that the IP broadcast address, which has primary application
Ethernets and similar technologies that support an
NTAG [Page 10]
RFC 985 May 1986
Requirements for Internet Gateways --
broadcast function, has an all-ones value in the host field of
IP address. Some early implementations chose the all-zeros
for this purpose, which is presently not in conformance with
definitive specification RFC-950 [21].
See Appendix A for further considerations
4.5. Serial-Line
Gateways may be used as packet switches in order to
networks. In some configurations gateways may be
with each other and some hosts by means of serial asynchronous
synchronous lines, with or without modems. When justified by
expected error rate and other factors, a link-level protocol
be required on the serial line. While there is no requirement
a particular standard protocol be used for this, it is
that standard hardware and protocols be used, unless a
reason to the contrary exists. In order to support the
variety of configurations, it is recommended that some
on full X.25 (i.e. "symmetric mode") be used where
permit; however, X.25 LAPB would also be acceptable
requirements permit. In the case of asynchronous lines no
choice is apparent
5.
In order to assure interoperability between gateways procured
different vendors, it is necessary to specify points of
demarcation. With respect to interoperability of the
function, this is specified as EGP. All gateway systems must
one or more gateways which support EGP with a core gateway,
described in RFC-904 [11]. It is desirable that these gateways
able to operate in a mode that does not require a core gateway
system. Additional discussion on these issues can be found
RFC-975 [27].
With respect to the interoperability at the network layer and below
two points of protocol demarcation are specified, one for
and the other for serial lines. In the case of Ethernets
protocols are as specified in Section 4.4 and Appendix A of
document. For serial lines between gateways of different vendors
the protocols are specified in Section 4.5 of this document
Exceptions to these requirements may be appropriate in some cases
NTAG [Page 11]
RFC 985 May 1986
Requirements for Internet Gateways --
6. Subnetwork
It is recognized that gateways may also function as general
switches to build networks of modest size. This requires
functionality in order to manage network routing, control
configuration. While it is beyond the scope of this document
specify the details of the mechanisms used in any particular,
proprietary, architecture, there are a number of basic
which must be provided by any acceptable architecture
6.1. Reachability
The architecture must provide a robust mechanism to establish
operational status of each link and node in the network,
the gateways, the links connecting them and, where appropriate
the hosts as well. Ordinarily, this requires at least
link-level reachability protocol involving a periodic exchange
hello messages across each link. This function might be
to the link-level protocols used (e.g. LAPB, DDCMP). However,
is in general ill-advised to assume a host or gateway is
correctly if its link-level reachability protocol is
correctly. Additional confirmation is required in the form of
operating routing algorithm or peer-level reachability protocol
such as used in EGP
Failure and restoration of a link and/or gateway are
network events and must be reported to the control center. It
desirable, although not required, that reporting paths not
correct functioning of the routing algorithm itself
6.2. Routing
It has been the repeated experience of the Internet
participants that the routing mechanism, whether static
dynamic, is the single most important engineering issue in
design. In all but trivial network topologies it is
that some degree of routing dynamics is vital to
operation, whether it be affected by manual or automatic means
some combination of both. In particular, if routing changes
made manually, the changes must be possible without taking
the gateways for reconfiguration and, preferably, be possible
a remote site such as a control center
It is not likely that all nets can be maintained from
full-service control center, so that automatic-fallback
rerouting features may be required. This must be considered
normal case, so that systems of gateways operating as the
NTAG [Page 12]
RFC 985 May 1986
Requirements for Internet Gateways --
packet switches in a network would normally be expected to have
routing algorithm with the capability of reacting to link
other gateway failures and changing the routing automatically
Following is a list of features considered necessary
1. The algorithm must sense the failure or restoration of
link or other gateway and switch to appropriate
within an interval less than the typical TCP user
(one minute is a safe assumption).
2. The algorithm must never form routing loops
neighbor gateways and must contain provisions to avoid
suppress routing loops that may form between non-
gateways. In no case should a loop persist for longer
an interval greater than the typical TCP user timeout
3. The control traffic necessary to operate the
algorithm must not significantly degrade or disrupt
network operation. Changes in state which might
disrupt normal operation in a local area must not
disruption in remote areas of the network
4. As the size of the network increases, the demand
resources must be controlled in an efficient way.
lookups should be hashed, for example, and data-
updates handled piecemeal, with only the changes
over a wide area. Reachability and delay metrics, if used
must not depend on direct connectivity to all
gateways or the use of network-specific
mechanisms. Polling procedures (e.g. for
checking) should be used only sparingly and in no
introduce an overhead exceeding a constant independent
network topology times the longest non-looping path
5. The use of a default gateway as a means to reduce the
of the routing data base is strongly discouraged in view
the many problems with multiple paths, loops
mis-configuration vulnerabilities. If used at all,
should be limited to a discovery function, with
routes cached from external or internal data bases
either the routing algorithm or EGP
6. This document places no restriction on the type of
algorithm, such as node-based, link-based or any
algorithm, or metric, such as delay or hop-count. However
the size of the routing data base must not be allowed
exceed a constant independent of network topology times
NTAG [Page 13]
RFC 985 May 1986
Requirements for Internet Gateways --
number of nodes times the mean connectivity (average
of incident links). An advanced design would not
that the entire routing data base be kept in any
gateway, so that discovery and caching techniques would
necessary
7. Operation and
Gateways and packets switches are often operated as a system by
organization who agrees to operate and maintain the gateways, as
as to resolve link problems with the respective common carriers.
is important to note that the network control site may not
physically attached to the network being monitored. In general,
following requirements apply
1. Each gateway must operate as a stand-alone device for
purposes of local hardware maintenance. Means must
available to run diagnostic programs at the gateway site
only on-site tools, which might be only a diskette or tape
local terminal. It is desirable, although not required,
run diagnostics via the network and to automatically
and dump the gateway via the net in case of fault.
general, this requires special hardware
The use of full-blown transport services such as TCP is
general ill-advised if required just to reboot and dump
gateway. Consideration should be given
retransmission-overlay protocols based on UDP or
monitoring protocols such as HMP described in RFC-869 [7].
2. It must be possible to reboot and dump the gateway
from the control site. Every gateway must include a
timer that either initiates a reboot or signals a
control site if not reset periodically by the software. It
desirable that the data involved reside at the control
and be transmitted via the net; however, the use of
devices at the gateway site is acceptable. Nevertheless,
operation of initiating reboot or dump must be possible
the net, assuming a path is available and the connecting
are operating
3. A mechanism must be provided to accumulate traffic
including, but not limited to, packet tallies, error-
tallies and so forth. The preferred method of
these data is by explicit, periodic request from the
site using a standard datagram protocol based on UDP or HMP
NTAG [Page 14]
RFC 985 May 1986
Requirements for Internet Gateways --
The use of full-blown transport services such as TCP is
general ill-advised if required just to collect
from the gateway. Consideration should be given
retransmission-overlay protocols based on UDP or HMP
4. Exception reports ("traps") occuring as the result of
or software malfunctions should be transmitted
(batched to reduce packet overheads when possible) to
control site using a standard datagram protocol based on
or HMP
5. A mechanism must be provided to display link and node
on a continuous basis at the control site. While it
desirable that a complete map of all links and nodes
available, it is acceptable that only those components in
by the routing algorithm be displayed. This information
usually available locally at the control site, assuming
site is a participant in the routing algorithm
The above functions require in general the participation of a
site or agent. The preferred way to provide this is as a
program suitable for operation in a standard software
such as Unix. The program would use standard IP protocols such
TCP, UDP, and HMP to control and monitor the gateways. The use
specialized host hardware and software requiring
additional investment is strongly discouraged; nevertheless,
vendors may elect to provide the control agent as an integrated
of the network in which the gateways are a part. If this is
case, it is required that a means be available to operate the
agent from a remote site using Internet protocols and paths and
equivalent functionality with respect to a local agent terminal
Remote control of a gateway via Internet paths can involve either
direct approach, in which the gateway supports TCP and/or
directly, or an indirect approach, in which the control
supports these protocols and controls the gateway itself
proprietary protocols. The former approach is preferred,
either approach is acceptable
NTAG [Page 15]
RFC 985 May 1986
Requirements for Internet Gateways --
8. References and
[1] Defense Advanced Research Projects Agency, "Internet Protocol",
DARPA Network Working Group Report RFC-791, USC
Sciences Institute, September 1981.
[2] Defense Advanced Research Projects Agency, "Internet
Message Protocol", DARPA Network Working Group Report RFC-792,
USC Information Sciences Institute, September 1981.
[3] Advanced Research Projects Agency, "Interface Message
- Specifications for the Interconnection of a Host and an IMP",
BBN Report 1822, Bolt Beranek and Newman, December 1981.
[4] Plummer, D., "An Ethernet Address Resolution Protocol",
Network Working Group Report RFC-826, Symbolics, September 1982.
[5] United States Department of Defense, "Military Standard
Protocol", Military Standard MIL-STD-1777, August 1983.
[6] Defense Communications Agency, "Defense Data Network X.25
Interface Specification", BBN Communications, December 1983.
[7] Hinden, R., "A Host Monitoring Protocol", DARPA Network
Group Report RFC-869, BBN Communications, December 1983.
[8] Korb, J.T., "A Standard for the Transmission of IP
over Public Data Networks", DARPA Network Working Group
RFC-877, Purdue University, September 1983.
[9] Nagle, J., "Congestion Control in IP/TCP Internetworks",
Network Working Group Report RFC-896, Ford Aerospace
January 1984.
[10] Hornig, C., "A Standard for the Transmission of IP
over Ethernet Networks", DARPA Network Working Group
RFC-894, Symbolics, April 1984.
[11] Mills, D.L., "Exterior Gateway formal Specification",
Network Working Group Report RFC-904, M/A-COM Linkabit
April 1984.
[12] Postel, J., and J. Reynolds., "ARPA-Internet Protocol Policy",
DARPA Network Working Group Report RFC-902, USC
Sciences Institute, July 1984.
NTAG [Page 16]
RFC 985 May 1986
Requirements for Internet Gateways --
[13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", DARPA
Working Group Report RFC-911, USC Information
Institute, August 1984.
[14] Postel, J., "Multi-LAN Address Resolution", DARPA
Working Group Report RFC-925, USC Information
Institute, October 1984.
[15] International Standards Organization, "Protocol for
the Connectionless-Mode Network Services", DARPA Network
Group Report RFC-926, International Standards Organization
December 1984.
[16] National Research Council, "Transport Protocols for
of Defense Data Networks", DARPA Network Working Group
RFC-942, National Research Council, March 1985.
[17] Postel, J., "DOD Statement on NRC Report", DARPA Network
Group Report RFC-945, USC Information Sciences Institute
April 1985.
[18] International Standards Organization, "Addendum to the
Service Definition Covering Network Layer Addressing",
Network Working Group Report RFC-941, International
Organization, April 1985.
[19] Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA
Protocol Suite", Proceedings INFOCOM 85, Washington DC
March 1985] Also in: IEEE Communications Magazine, March 1985.
[20] Winston, I., "Two Methods for the Transmission of IP
over IEEE 802.3 Networks", DARPA Network Working Group
RFC-948, University of Pennsylvania, June 1985.
[21] Mogul, J., and J. Postel, "Internet Standard
Procedure", DARPA Network Working Group Report RFC-950,
University, August 1985.
[22] Reynolds, J., and J. Postel, "Official ARPA-Internet Protocols",
DARPA Network Working Group Report RFC-961, USC
Sciences Institute, October 1985.
[23] Reynolds, J., and J. Postel, "Assigned Numbers", DARPA
Working Group Report RFC-960, USC Information
Institute, December 1985.
NTAG [Page 17]
RFC 985 May 1986
Requirements for Internet Gateways --
[24] Nagle, J., "On Packet Switches with Infinite Storage",
Network Working Group Report RFC-970, Ford Aerospace
December 1985.
[25] Defense Communications Agency, "DDN Protocol Handbook",
NIC-50004, NIC-50005, NIC-50006, (three volumes),
International, December 1985.
[26] Defense Communications Agency, "ARPANET Information Brochure",
NIC-50003, SRI International, December 1985.
[27] Mills, D.L., "Autonomous Confederations", DARPA Network
Group Report RFC-975, M/A-COM Linkabit, February 1986.
[28] Jacobsen, O., and J. Postel, "Protocol Document
Information", DARPA Network Working Group Report RFC-980,
International, March 1986.
[29] Malis, A.G., "PSN End-to-End Functional Specification",
Network Working Group Report RFC-979, BBN Communications
March 1986.
NTAG [Page 18]
RFC 985 May 1986
Requirements for Internet Gateways --
Appendix A. Ethernet
Following is a summary of procedures specified for use by hosts
gateways on an Ethernet
A.1.
A packet is accepted from the cable only if its
Ethernet address matches either the assigned interface address
a broadcast/multicast address. Presumably, this filtering is
by the interface hardware; however, the software driver
expected to do this if the hardware does not. Some
incorporate an optional feature that associates an
multicast address with a specific subnet in order to
access for testing, etc. When this feature is activated,
assigned multicast address replaces the broadcast address
A.2. IP
In case of broadcast/multicast (as determined from the
Ethernet address) an IP datagram is discarded if the source
address is not in the same subnet, as determined by the
host IP address and subnet mask. It is desirable that this
be overridden by a configuration parameter, in order to
the infrequent cases where more than one subnet may coexist on
same cable
A.3. ARP
An ARP reply is discarded if the destination IP address does
match the local host address. An ARP request is discarded if
source IP address is not in the same subnet. It is desirable
this test be overridden by a configuration parameter, in order
support the infrequent cases where more than one subnet
coexist on the same cable (see RFC-925 for examples). An
reply is generated only if the destination protocol IP address
reachable from the local host (as determined by the
algorithm) and the next hop is not via the same interface. If
local host functions as a gateway, this may result in ARP
for destinations not in the same subnet
A.4. ICMP
An ICMP redirect is discarded if the destination IP address
not match the local host address or the new target address is
on the same subnet. An accepted redirect updates the routing
base for the old target address. If there is no route
NTAG [Page 19]
RFC 985 May 1986
Requirements for Internet Gateways --
associated with the old target address, the redirect is ignored
If the old route is associated with a default gateway, a new
associated with the new target address is inserted in the
base. Note that it is not possible to send a gratuitous
unless the sender is possessed of considerable imagination
When subnets are in use there is some ambiguity as to the scope
a redirect, unless all hosts and gateways involved have
knowledge of the subnet masks. It is recommended that the use
ICMP network-redirect messages be avoided in favor of
host-redirect messages instead. This requires the original
(i.e. redirect recipient) to support a general
address-translation cache, rather than the usual network table
However, this is normally done anyway in the case of ARP
An ICMP redirect is generated only if the destination IP
is reachable from the local host (as determined by the
algorithm) and the next hop is via the same interface and
target address is defined in the routing data base.
should never be sent in response to an IP net or subnet
address or in response to a Class-D or Class-E IP address
ICMP redirects are never forwarded, regardless of
address. The source IP address of the ICMP redirect itself is
checked, since the sending gateway may use one of its
not on the common net. The source IP address of the
IP datagram is not checked on the assumption the host or
sending the original IP datagram knows what it is doing
NTAG [Page 20]
RFC 985 May 1986
Requirements for Internet Gateways --
Appendix B. Policy
The following sections discuss certain issues of special concern
the NSF scientific networking community. These issues have
relevance in the policy area, but also have ramifications in
technical area
B.1. Interconnection
Currently the most important common interconnection
between Internet systems of different vendors is Ethernet.
the reasons for this are the following
1. Ethernet specifications are well-understood and mature
2. Ethernet technology is in almost all aspects
independent
3. Ethernet-compatible systems are common and becoming
so
These advantages combined favor the use of Ethernet technology
the common point of demarcation between NSF network
supplied by different vendors, regardless of technology. It is
requirement of NSF gateways that, regardless of the
proprietary switching technology used to implement a
vendor-supplied network, its gateways must support an
attachment to gateways of other vendors
It is expected that future NSF gateway requirements will
other interconnection technologies. The most likely
are those based on X.25 or IEEE 802, but other
including broadband cable, fiber-optic or other protocols such
DDCMP may also be considered
B.2. Proprietary and Extensible
Internet technology is a growing, adaptable technology.
hosts, gateways and networks supporting this technology have
in continuous operation for several years, vendors users
operators should understand that not all networking issues
fully understood. As a result, when new needs or better
are developed for use in the NSF networking community, it may
necessary to field new protocols. Normally, these new
will be designed to interoperate in all practical respects
existing protocols; however, occasionally it may happen
existing systems must be upgraded to support these protocols
NTAG [Page 21]
RFC 985 May 1986
Requirements for Internet Gateways --
NSF systems vendors should understand that they also undertake
commitment to remain aware of current Internet technology and
prepared to upgrade their products from time to time
appropriate. As a result, these vendors are strongly urged
consider extensibility and periodic upgrades as
characteristics of their products. One of the most productive
rewarding ways to do this on a long-term basis is to
in ongoing Internet research and development programs
partnership with the academic community
B.3. Multi-Protocol
Although the present requirements for an NSF gateway specify
the Internet protocol suite, it is highly desirable that
designs allow future extensions to support additional suites
allow simultaneous operation with more than a single one
Clearly, the ISO protocol suite is a prime candidate for one
these suites. Other candidates include XNS and DECnet
Future requirements for NSF gateways may include provisions
other protocol suites in addition to Internet, as well as
and specifications to interwork between them, should that
appropriate. For instance, it is expected that the ISO suite
eventually become the dominant one; however, it is also
that requirements to support other suites will continue,
indefinitely
Present NSF gateway requirements do not include protocols
the network layer, such as TCP, unless necessary for
monitoring or control. Vendors should recognize that
requirements to interwork between Internet and ISO applications
for example, may result in an opportunity to market
supporting multiple protocols at all levels through
application level. It is expected that the network-level
gateway requirements summarized in this document will
incorporated in the requirements document for
application-level gateways
B.4. Access Control and
There are no requirements for NSF gateways at this time
incorporate specific access-control and accounting mechanisms
the design; however, these important issues are currently
study and will be incorporated into a redraft of this document
an early date. Vendors are encouraged to plan for the
introduction of these mechanisms in their products. While at
NTAG [Page 22]
RFC 985 May 1986
Requirements for Internet Gateways --
time no definitive common model for access control and
has emerged, it is possible to outline some general features
a model is likely to have, among them the following
1. The primary access control and accounting
mechanisms will be in the service hosts themselves, not
gateways, packet switches or workstations
2. Agents acting on behalf of access control and
executive mechanisms may be necessary in the gateways
packet switches or workstations. These may be used
collect data, enforce password protection or
resource priority and fairness. However, the
and protocols used by these agents may be a local
and not possible to specify in advance
3. NSF gateways may be required to incorporate access
and accounting mechanisms based on
source/destination address, as well as other fields in
IP header, internal priority and fairness. However, it
extremely unlikely that these mechanisms would involve
user-level login to the gateway itself
NTAG [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
