not match the local host address or the new target address is not
on the same subnet. An accepted redirect updates the routing data
base for the old target address. If there is no route or
RFC985 May 1986
Requirements for Internet Gateways -- DRAFT
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. Note that it is not possible to send a gratuitous redirect
unless the sender is possessed of considerable imagination.
When subnets are in use there is some ambiguity as to the scope of
a redirect, unless all hosts and gateways involved have prior
knowledge of the subnet masks. It is recommended that the use of
ICMP network-redirect messages be avoided in favor of ICMP
host-redirect messages instead. This requires the original sender
(i.e. redirect recipient) to support a general IP
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 address
is reachable from the local host (as determined by the routing
algorithm) and the next hop is via the same interface and the
target address is defined in the routing data base. Redirects
should never be sent in response to an IP net or subnet broadcast
address or in response to a Class-D or Class-E IP address.
ICMP redirects are never forwarded, regardless of destination
address. The source IP address of the ICMP redirect itself is not
checked, since the sending gateway may use one of its addresses
not on the common net. The source IP address of the encapsulated
IP datagram is not checked on the assumption the host or gateway
sending the original IP datagram knows what it is doing.
RFC985 May 1986
Requirements for Internet Gateways -- DRAFT
Appendix B. Policy Issues
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. Interconnection Technology
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.
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, fiber-optic or other protocols such as
DDCMP may also be considered.
B.2. Proprietary and Extensible Issues
Internet technology is a growing, adaptable technology. Although
hosts, gateways and networks supporting this technology have been
in continuous operation for several years, vendors users and
operators should understand that not all networking issues are
fully understood. 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. 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 protocols.
RFC985 May 1986
Requirements for Internet Gateways -- DRAFT
NSF systems vendors should understand that they also 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, these 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.3. Multi-Protocol Gateways
Although the present requirements for an NSF gateway specify only
the Internet protocol suite, it is highly desirable that gateway
designs allow future extensions to support additional suites and
allow simultaneous operation with more than a single one.
Clearly, the ISO protocol suite is a prime candidate for one of
these suites. Other candidates include XNS and DECnet.
Future requirements for NSF gateways may include provisions for
other protocol suites in addition to Internet, as well as models
and specifications to interwork between them, should that be
appropriate. For instance, it is expected that the ISO suite will
eventually become the dominant one; however, it is also expected
that requirements to support other suites will continue, perhaps
indefinitely.
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 through the
application level. 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.
B.4. 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 redraft of this document at
an early date. Vendors are encouraged to plan for the early
introduction of these mechanisms in their products. While at this
RFC985 May 1986
Requirements for Internet Gateways -- DRAFT
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:
1. The primary access control and accounting executive
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
executive mechanisms may be necessary in the gateways,
packet switches or workstations. These may be used 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 not possible to specify in advance.
3. NSF gateways may be required to incorporate access control
and accounting mechanisms based on packet
source/destination address, as well as other fields in the
IP header, internal priority and fairness. However, it is
extremely unlikely that these mechanisms would involve a
user-level login to the gateway itself.