As per Relevance of the word redirect, we have this rfc below:
Network Working Group B.
Request for Comments: 1620
Category: Informational J.
Y.
IBM
May 1994
Internet Architecture Extensions for Shared
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The original Internet architecture assumed that each network
labeled with a single IP network number. This assumption may
violated for shared media, including "large public data networks
(LPDNs). The architecture still works if this assumption
violated, but it does not have a means to prevent multiple host
router and router-router hops through the shared medium. This
discusses alternative approaches to extending the
architecture to eliminate some or all unnecessary hops
Table of
1. INTRODUCTION .................................................. 2
2. THE ORIGINAL INTERNET ARCHITECTURE ............................ 2
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA ....................... 4
4. SOME SOLUTIONS TO THE SM PROBLEMS ............................. 7
4.1 Hop-by-Hop Redirection ................................... 7
4.2 Extended Routing ......................................... 11
4.3 Extended Proxy ARP ....................................... 13
4.4 Routing Query Messages ................................... 14
4.5 Stale Routing Information ................................ 14
4.6 Implications of Filtering (Firewalls) .................... 15
5. SECURITY CONSIDERATIONS ....................................... 16
6. CONCLUSIONS ................................................... 17
7. ACKNOWLEDGMENTS ............................................... 17
8. REFERENCES .................................................... 18
Authors' Addresses ............................................... 19
Braden, Postel & Rekhter [Page 1]
RFC 1620 Shared Media IP Architecture May 1994
1.
This memo concerns the implications of shared medium networks for
architecture of the TCP/IP protocol suite. General familiarity
the TCP/IP architecture and the IP protocol is assumed
The Internet architecture is founded upon what was originally
the "Catenet model" [PSC81]. Under this model, the
(originally dubbed "the Catenet") is formed using routers (
called "gateways") to interconnect distinct and perhaps
networks. An IP host address (more correctly characterized as
network interface address) is formed of the pair (net#,host#).
"net#" is a unique IP number assigned to the network (or subnet)
which the host is attached, and "host#" identifies the host on
network (or subnet).
The original Internet model made the implicit assumptions that
network has a single IP network number and that networks
different numbers may interchange packets only through routers
These assumptions may be violated for networks implemented using
common "shared medium" (SM) at the link layer (LL). For example
network managers sometimes configure multiple IP network
(usually subnet numbers) on a single broadcast-type LAN such as
Ethernet. The large (switched) public data networks (LPDNs), such
SMDS and B-ISDN, form a potentially more important example of
medium networks. Any two systems connected to the same shared
network are capable of communicating directly at the LL, without
layer switching by routers. This presents an opportunity to
performance and perhaps lower cost by eliminating unnecessary LL
through the medium
This memo discusses how unnecessary hops can be eliminated in
shared medium, while retaining the coherence of the existing
architecture. This issue has arisen in a number of IETF
Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP
IP, and BGP. It is time to take a careful look at the
issues to be solved. This memo first summarizes the relevant
of the original Internet architecture (Section 2), and then
explains the extra-hop problems created by shared media
(Section 3). Finally, it discusses some possible solutions (
4).
2. THE ORIGINAL INTERNET
We very briefly review the original architecture, to introduce
terminology and concepts. Figure 1 illustrates a typical set of
networks A, ... D, represented traditionally as clouds
interconnected by routers R2, R3, and R4. Routers R1 and R5
Braden, Postel & Rekhter [Page 2]
RFC 1620 Shared Media IP Architecture May 1994
to other parts of the Internet. Ha, ... Hd represent hosts
to these networks
It is not necessary to distinguish between network and subnet in
memo. We may assume that there is some address mask associated
each "network" in Figure 1, allowing a host or router to divide
32 bits of an IP address into an address for the cloud and a
number that is defined uniquely only within that cloud
Ha Hb Hc
| | | |
| | | |
_|_ _|_ _|_ _|_
( ) ( ) ( ) ( )
(Net) (Net) (Net) (Net
( A ) ( B ) ( C ) ( D )
- R1 --( )-- R2 --( )-- R3 --( )-- R4 --( )-- R5 --
( ) ( ) ( ) ( )
(___) (___) (___) (___)
Figure 1. Example Internet
An Internet router is connected to local network(s) as a special
of host. Indeed, for network management purposes, a router plays
role of a host by originating and terminating datagrams. However
there is an important difference between a host and a router:
routing function is mostly centralized in the routers, allowing
to be "dumb" about routing. Internet hosts are required [RFC-1122]
to make only one simple routing decision: is the destination
local to the connected network? If the address is not local, we
it is "foreign" (relative to the connected network or to the host).
A host sends a datagram directly to a local destination address
(for a foreign destination) to a first-hop router. The
initially uses some "default" router for any new destination address
If the default is the wrong choice, that router returns a
message and forwards the datagram. The Redirect message
the preferred first-hop router for the given destination address
The host uses this information, which it maintains in a "
cache" [RFC-1122], to determine the first-hop address for
datagrams to the same destination
To actually forward an IP datagram across a network hop, the
must have the link layer (LL) address of the target. Therefore,
host and router must have some "address resolution" procedure to
IP address to an LL address. ARP, used for networks with
capability, is the most common address resolution
Braden, Postel & Rekhter [Page 3]
RFC 1620 Shared Media IP Architecture May 1994
[Plummer82]. If there is no LL broadcast capability (or if it is
expensive), then there are two other approaches to
resolution: local configuration tables, and "address-
servers" (AR Servers).
If AR Servers are used for address resolution, hosts must
configured with the LL address(es) of one or more nearby servers
The mapping information provided by AR Servers might itself
collected using a protocol that allows systems to register their
addresses, or from static configuration tables. The ARP
format and the overall ARP protocol structure (ARP Request/ARP Reply
may be suitable for the communications between a host and an
server, even in the absence of the LL broadcast capabilities;
would ease conversion of hosts to using AR Servers
The examples in this memo use ARP for address resolution. At
some of the LPDN's that are planned will provide sufficient
capability to support ARP. It is important to note that ARP
at the link layer, while the Redirect and routing cache
operate at the IP layer of the protocol stack
3. THE PROBLEMS INTRODUCED BY SHARED
Figure 2 shows the same configuration as Figure 1, but now
A, B, C, and D are all within the same shared medium (SM), shown
the dashed box enclosing the clouds. Networks A, ... D are
logical IP networks (called LIS's in [Laubach93]) rather
physical networks. Each of these logical networks may (or may not
be administratively distinct. The SM allows direct
between any two hosts or routers connected to it. For example,
Ha can interchange datagrams directly with host Hd or with router R4.
A router that has some but not all of its interfaces connected to
shared medium is called a "border router"; R1 and R5 are examples
Figure 2 illustrates the "classical" model [Laubach93] for use of
Internet architecture within a shared medium, i.e., simply
the original Internet architecture described earlier. This
provide correct but not optimal operation. For example, in the
of two hosts on the same logical network (not shown in Figure 2),
original rules will clearly work; the source host will forward
datagram directly in a single hop to a host on the same
network. The original architectural rules will also work
communication between any pair of hosts shown in Figure 2;
example, host Ha would send a datagram to host Hd via the four-
path Ha -> R2 -> R3 -> R4 -> Hd. However, the classical model
not take advantage of the direct connectivity Ha -> Hd allowed by
shared medium
Braden, Postel & Rekhter [Page 4]
RFC 1620 Shared Media IP Architecture May 1994
Ha Hb Hc
| | | |
---- | ---------- | ---------- | ---------- | ----
| __|__ __|__ __|__ __|__ |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
( Net ) ( Net ) ( Net ) ( Net )
| ( A ) ( B ) ( C ) ( D ) |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
(_____) (_____) (_____) ( ____)
| | | | | | | | | |
--- | | -------- | | -------- | | -------- | | ---
| | | | | | | |
- R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 ---
Figure 2. Logical IP Networks in Shared
This memo concerns mechanisms to achieve minimal-hop
when it is desired. We should note that is may not always
desirable to achieve minimal-hop connectivity in a shared medium
For example, the "extra" hops may be needed to allow the routers
act as administrative firewalls. On the other hand, when
firewall protection is not required, it should be possible to
advantage of the shared medium to allow this datagram to use
paths. In general, it should be possible to choose between
security and efficient connectivity. This is discussed further
Section 4.6 below
We also note that the mechanisms described here can only optimize
path within the local SM. When the SM is only one segment of
path between source and receiver, removing hops locally may limit
ability to switch to globally more optimal paths that may
available as the result of routing changes. Thus, consider Ha
>...Hx, where host Hx is outside the SM to which host Ha is attached
Suppose that the shortest global path to Hx is via some border
Rb1. Local optimization using the techniques described below
remove extra hops in the SM and allow Ha->Rb1->...Hx. Now
that a later route change outside the SM makes the path Ha->Rb2-
>...Hx more globally optimum, where Rb2 is another border router
Since Ha does not participate in the routing protocol, it does
know that it should switch to Rb2. It is possible that Rb2 may
realize it either; this is the situation
GC(Ha->Rb2->...Hx) < GC(Ha->Rb1->Rb2->...Hx) < GC(Ha->Rb1->...Hx
Braden, Postel & Rekhter [Page 5]
RFC 1620 Shared Media IP Architecture May 1994
where GC() represents some global cost function of the
path
Note that ARP requires LL broadcast. Even if the SM
broadcast, it is likely that administrators will erect firewalls
keep broadcasts local to their LIS
There are three cases to be optimized. Suppose H and H' are
and Rb and Rb' are border routers connected to the same same SM
Then the following one-hop paths should be possible
H -> H': Host to host within the
H -> Rb: Host to exit
Rb -> Rb': Entry border router to exit border router
for transit traffic
We may or not be able to remove the extra hop implicit in Rb -> R ->
H, where Rb, R, and H are within the same SM, but the ultimate
is outside the SM. To remove this hop would require distribution
host routes, not just network routes, between the two routers R
Rb; this would adversely impact routing scalability
There are a number of important requirements for any
solution to these problems
*
Modified hosts and routers must interoperate with
nodes
*
Minimal software changes should be required
*
The new scheme must be at least as robust against errors
software, configuration, or transmission as the
architecture
*
The new scheme must be at least as securable against
as the existing architecture
Braden, Postel & Rekhter [Page 6]
RFC 1620 Shared Media IP Architecture May 1994
The distinction between host and router is very significant from
engineering viewpoint. It is considered to be much harder to make
global change in host software than to change router software
because there are many more hosts and host vendors than routers
router vendors, and because hosts are less centrally
than routers. If it is necessary to change the specification of
a host does (and it is), then we must minimize the extent of
change
4. SOME SOLUTIONS TO THE SM
Four different approaches have been suggested for solving these
problems
(1) Hop-by-Hop
In this approach, the host Redirect mechanism is extended
collapse multiple-hop paths within the same shared medium, hop
by-hop. A router is to be allowed to send, and a host
to accept, a Redirect message that specifies a foreign
address within the same SM. We refer to this as a "
Redirect". Section 4.1 analyzes this approach in some detail
(2) Extended
Routing protocols can be modified to know about the SM and
provide LL addresses
(3) Extended Proxy
This is a form of the proxy ARP approach, in which the
problem is solved implicitly by an extended address
mechanism at the LL. This approach has been described
Heinanen [Heinanen93] and by Garrett et al [Garratt93].
(4) Route Query
This approach has been suggested by Halpern [Halpern93].
than adding additional information to routing, this
would add a new IP-layer mechanism using end-to-end query
reply datagrams
These four are discussed in the following four subsections
4.1 Hop-by-Hop
The first scheme we consider would operate at the IP layer.
would cut out extra hops one by one, with each router in the
Braden, Postel & Rekhter [Page 7]
RFC 1620 Shared Media IP Architecture May 1994
operating on local information only. This approach requires
host and router changes but no routing protocol changes
The basic idea is that the first-hop router, upon observing
the next hop is within the same SM, sends a foreign Redirect
the source, redirecting it to the next hop.
application of this algorithm at each intermediate router
eventually result in a direct path from source host to
host, if both are within the same SM
Suppose that Ha wants to send a datagram to Hd. We use
notation IP.a for the IP address of entity a, and LL.a for
corresponding LL address. Each line in the following shows an
datagram and the path that datagram will follow, separated by
colon. The notation "Redirect( h, IP.a)" means a
specifying IP.a as the best next hop to reach host h
(1) Datagram 1: Ha -> R2 -> R3 -> R4 ->
(2) Redirect(Hd, IP.R3): R2 ->
(3) Datagram 2: Ha -> R3 -> R4 ->
(4) Redirect(Hd, IP.R4): R3 ->
(5) Datagram 3: Ha -> R4 ->
(6) Redirect(Hd, IP.Hd): R4 ->
(7) Datagram 4: Ha ->
There are three problems to be solved to make hop-by-
redirection work; we label them HH1, HH2, and HH3.
HH1: Each router must be able to resolve the LL address of
source Ha, to send a (foreign) Redirect
Let us assume that the link layer provides the source
address when an IP datagram arrives. If the
determines that a Redirect should be sent, then it will
sent to the source LL address of the received datagram
HH2: A source host must be able to perform address resolution
obtain the LL address of each router to which it
redirected
It would be possible for each router R, upon sending
Redirect to Ha, to also send an unsolicited ARP Reply point
Braden, Postel & Rekhter [Page 8]
RFC 1620 Shared Media IP Architecture May 1994
to-point to LL.Ha, updating Ha's ARP cache with LL.R
However, there is not guarantee that this unsolicited
Reply would be delivered. If it was lost, there would be
forwarding black hole. The host could recover by
over from the original default router; however, this may
too inefficient a solution
A much more direct and efficient solution would introduce
extended ICMP Redirect message (call it XRedirect)
carries the LL address as well as the IP address of
target. This would remove the issue of reliable delivery
the unsolicited ARP described earlier, because the fate
the LL address would be shared with the IP target address
both would be delivered or neither would. (An XRedirect
essentially the same as a Redirect in the OSI ES-
protocol).
Using XRedirect, the previous example becomes
(1) Datagram 1: Ha -> R2 -> R3 -> R4 ->
(2) XRedirect(Hd, IP.R3, LL.R3): R2 ->
(3) Datagram 2: Ha -> R3 -> R4 ->
(4) XRedirect(Hd, IP.R4, LL.R4): R3 ->
(5) Datagram 3: Ha -> R4 ->
(6) XRedirect(Hd, IP.Hd, LL.Hd): R4 ->
(7) Datagram 4: Ha ->
HH3: Each router should be able to recognize when it is the
hop in the path, since a Redirect should be sent only by
first hop router. Unfortunately this will be possible
if the LL address corresponding to the IP source address
been cached from an earlier event; a router in this
determines the LL address of the source from the
datagram (see HH1 above). If it cannot determine whether
is the first hop, a router must always send an [X]Redirect
which will be spurious if the router is not the first hop
Such spurious [X]Redirects will be sent to the IP address
the source host, but using the LL address of the previous-
router. The propagation scope of [X]Redirects can be
to a single IP hop (see below), so they will go no
than the previous-hop router, where they will be discarded
Braden, Postel & Rekhter [Page 9]
RFC 1620 Shared Media IP Architecture May 1994
However, there will be some router overhead to process
useless [X]
Next, we discuss the changes in hosts and in routers required
hop-by-hop redirection
o Host
The Host Requirements RFC [RFC-1122] specifies the
mechanism for routing an outbound datagram in terms
sending the datagram directly to a local destination or
to the first hop router (to reach a foreign destination
[RFC-1122 3.3.1]. Although this mechanism assumes a
address, a foreign address for a first-hop router should
equally well
The target address contained in the routing cache is
by Redirect messages. There is currently a restriction
what target addresses may be accepted in Redirect
[RFC-1122 3.2.2.2], which would prevent foreign
from working
A Redirect message SHOULD be silently discarded if
new router address it specifies is not on the
connected (sub-) net through which the Redirect arrived
or if the source of the Redirect is not the
first-hop router for the specified destination
To support foreign Redirects requires simply removing
first validity check. The second check, which requires
acceptable Redirect to come from the node to which
datagram that triggered the Redirect was sent, is retained
The same validity check would be used for XRedirects
In order to send a datagram to the target address found
the routing cache, a host must resolve the IP address into
LL address. No change should be necessary in the host's IP
to-LL resolution mechanism to handle a foreign rather than
local address
The Hop-by-Hop redirection requires changes to the
of the IP address that an ICMP Redirect is allowed to carry
Under the present definition [Postel81b], an ICMP
message is only allowed to carry an IP address of a router
In order for the hop-by-hop redirection mechanism
eliminate all router hops, allowing two hosts connected
the same SM to communicate directly, a [X]Redirect
must be able to carry the IP address of the destination host
Braden, Postel & Rekhter [Page 10]
RFC 1620 Shared Media IP Architecture May 1994
o Router
The router changes required for hop-by-hop redirection
much more extensive than the host changes. The
given earlier showed the additional router functions
would be needed
Consider a router that is connected to an SM. When
receives a datagram from the SM, it tests whether the
hop is on the same SM, and if so, it sends a
XRedirect to the source host, using the link layer
with which the datagram arrived
A router should avoid sending more than a limited number
successive foreign Redirects to the same host. This
necessary because an unmodified host may legitimately
a Redirect to a foreign network and continue to
datagrams to the same router. A router can accomplish
limitation by keeping a cache of foreign Redirects sent
Note that foreign Redirects generated by routers according
these rules, like the current local Redirects, may
exactly one link-layer hop. It is therefore reasonable
desirable to set their TTL to 1, to ensure they cannot
outside the SM
The extra check needed to determine whether to generate
Redirect may incur additional processing and thus result in
performance degradation; to avoid this, a router may
perform the check at all but just forward the packet.
scheme with [X]Redirects is not applicable to such a router
Finally, note that the hop-by-hop redirection scheme is
applicable when the source host is connected to an SM,
routers do not listen to Redirects. To optimize
forwarding of transit traffic between entry and exit
routers, an extension to routing is required, as discussed
the following section. Conversely, an extension to
routing protocol cannot be used to optimize
traffic from a host connected to the SM, since a host
not listen to routing protocols
4.2 Extended
The routing protocols may be modified to carry
information that is specific to the SM. The router could use
attribute "SameSM" for a route to deduce the shortest path to
reported to its neighbors. It could also carry the LL
Braden, Postel & Rekhter [Page 11]
RFC 1620 Shared Media IP Architecture May 1994
with each router IP address
For example, the extended routing protocol would allow R2 to
that R4 is the best next-hop to reach the destination network
the same SM, and to know both IP.R4 and LL.R4, leading to the
Ha->R2->R4->Hb. Further optimization cannot be done with
routing alone, since the host does not participate in routing,
because we want the routing protocol to handle only per-
information, not per-host information. Hop-by-hop
could then be used to eliminate all router hops, as in
following sequence
(1) Datagram 1: Ha -> R2 -> R4 ->
(2) XRedirect(Hd, IP.R4, LL.R4): R2 ->
(3) Datagram 2: Ha -> R4 ->
(4) XRedirect(Hd, IP.Hd, LL.Hd): R4 ->
(5) Datagram 3: Ha ->
There are three aspects to the routing protocol extension
(1) the ability to pass "third-party" information -- a
should be able to specify the address (IP address and
LL address) of some other router as the next-hop
(2) knowledge of the "SameSM" attribute for routes;
(3) knowledge of LL addresses corresponding to IP addresses
routers within the same SM
A router must be able to determine that a particular IP
(e.g., the source address) is in the same SM. There are
possible ways to make this information available to a router
the SM
(1) A router may use a single physical interface to an SM;
implies that all its logical interfaces lie within the
SM
(3) There might be some administrative structure in the
addresses, e.g., all IP addresses within a
national SM might have a common prefix string
(3) There might be configuration information, either local to
router or available from some centralized server (e.g,
Braden, Postel & Rekhter [Page 12]
RFC 1620 Shared Media IP Architecture May 1994
DNS). Note that a router could consult this server in
background while continuing to forward datagrams
delay. The only consequence of a delay in obtaining
"SameSM" information would be some unnecessary (
temporary) hops
4.3 Extended Proxy
The approach of Heinanen [Heinanen93] was intended to solve
problem of address resolution in a shared medium with no
mechanism ("Non-Broadcast, MultiAccess" or NBMA). Imagine
the shared medium has a single IP network number, i.e., it is
network "cloud". Heinanen envisions a set of AR Servers
this medium. These AR Servers run some routing protocol
themselves. A source host issues an ARP Request (via a point-to
point LL transmission) to an AR Server with which it
associated. This ARP Request is forwarded hop-by-hop at the
layer through the AR Servers, towards the AR Server that
associated with the destination host. That AR Server resolves
address (using information learned from either host
or a configuration file), and returns an ARP Reply back
the AR Servers to the source host
Ha Hb Hc
| | | |
---- | ---------- | ---------- | ---------- | ----
( )
( Shared Medium (One Logical Network) )
( )
----|--|---------|------------|----------|----|---
| | | | | |
- R1 - | | | | --- R5 ---
____|__ __|____ __|____ _|_____
| AR Sa | | AR Sb | | AR Sc | | AR Sd |
|_______| |_______| |_______| |_______|
Figure 3. Single-Cloud Shared
Figure 3 suggests that each of the hosts Ha, ... Hd is
with a corresponding AR Server "AR Sa", ..."AR Sd".
This same scheme could be applied to the LIS model of Figure 2.
The AR Servers would be implemented in the routers, and if
medium supports broadcast then the hosts would be configured
proxy ARP. That is, the host would be told that all
Braden, Postel & Rekhter [Page 13]
RFC 1620 Shared Media IP Architecture May 1994
are local, so it will always issue an ARP request for the
destination. The set of AR Servers would resolve this request
Since routing loops are a constant possibility, Heinanen'
proposal includes the addition of a hop count to ARP requests
replies
Like all proxy ARP schemes, this one has a seductive simplicity
However, solving the SM problem at the LL has several costs.
requires a complete round-trip time before the first datagram
flow. It requires a hop count in the ARP packet. This seems
a tip-off that the link layer may not be the most
place to solve the SM problem
4.4 Routing Query
This scheme [Halpern93] introduces a new IP level mechanism:
routing query and reply messages. These messages are forwarded
IP datagrams hop-by-hop in the direction of the
address. The exit router can return a reply, again hop-by-hop
that finally reaches the source host as an XRedirect. It
also be possible (but not necessary) to modify hosts to
these queries
The query/reply pair is supplying the same information that
would add to routing protocols under Extended Routing. However
the Query/Reply messages would allow us to keep the
routing protocols unchanged, and would also provide the
information only for the routes that are actually needed,
reducing the routing overhead. Note that the Query/Reply
can happen in parallel with forwarding the initial datagram hop
by-hop, so it does not add an extra round-trip delay
4.5 Stale Routing
We must consider what happens when the network topology changes
The technique of extended routing (Section 4.2) is capable
providing sufficient assurances that stale information will
purged from the system within the convergence time associated
a particular routing protocol being used
However, the three other techniques (hop-by-hop redirection
extended Proxy ARP, and routing query messages) may be expected
provide minimal-hop forwarding only as long as the
topology remains unchanged since the time such information
acquired. Changes in the topology may result in a change in
minimal-hop path, so that the first-hop router may no longer
the correct choice. If the host that is using this first-
Braden, Postel & Rekhter [Page 14]
RFC 1620 Shared Media IP Architecture May 1994
router is not aware of the changes, then instead of a minimal-
path the host could be using a path that is now suboptimal
perhaps highly sub-optimal, with respect to the number of hops
Futhermore, use of the information acquired via either
Proxy ARP or routing query messages to optimize routing
routers attached to the same SM is highly problematic,
presence of stale information on routers could result
forwarding loops that might persist as long as the
isn't purged; neither approach provides suitable handling of
information
4.6 Implications of Filtering (Firewalls
For a variety of reasons an administrator of a LIS may erect
Layer firewalls (perform IP-layer filtering) to constrain
connectivity between the hosts/routers within the LIS
hosts/routers in other LISs within the same SM. To
disruption in forwarding, the mechanisms described in
document need to take into account such firewalls
Using [X]Redirects requires a router that generates an [X]
to be cognizant of possible Link Layer connectivity
between the router that is specified as the Next Hop in
Redirect and the host that is the target of the Redirect
Using extended routing requires a router that originates and/
propagates "third-party" information be cognizant of the
Link Layer connectivity constraints. Specifically, a router
not propagate "third-party" information when there is a lack
Link Layer connectivity between the router depicted by
information and the router which is the immediate recipient
that information
Using extended proxy ARP requires an ARP Server not to
an ARP Request to another ARP server if there are Link
connectivity constraints between the originator of the ARP
and the other ARP server
Using SM routing query and reply messages requires the
that pass the messages to be aware of the possible Link
connectivity constraints. The flow of messages need to
these constraints
Braden, Postel & Rekhter [Page 15]
RFC 1620 Shared Media IP Architecture May 1994
5. SECURITY
We should discuss the security issues raised by our
changes. We should note that we are not talking about "real
security here; real Internet security will require
techniques on an end-to-end basis. However, it should not be easy
subvert the basic delivery mechanism of IP to cause datagrams to
to unexpected places
With this understanding, the security problems arise in two places
the ICMP Redirect messages and the ARP replies
* ICMP Redirect
We may reasonably require that the routers be secure. They
generally under centralized administrative control, and we
assume that the routing protocols will contain
authentication mechanisms (even if it is not currently true).
Therefore, a host will reasonably be able to trust a
that comes from a router
However, it will NOT be reasonable for a host to trust
host. Suppose that the target host in the examples of
4.1 is untrustworthy; there is no way to prevent its issuing
new Redirect to some other destination, anywhere in
Internet. On the other hand, this exposure is no worse than
was; the target host, once subverted, could always act as
hidden router to forward traffic elsewhere
* ARP
Currently, an ARP Reply can come only from the local network
and a physically isolated network can be administrative
from subversion of ARP. However, an ARP Reply can come
anywhere within the SM, and an evil-doer can use this fact
divert the traffic flow from any host within the
[Bellovin89].
The XRedirect closes this security hole. Validating
XRedirect (as coming from the node to which the last
was sent) will also validate the LL address
Another approach is to validate the source address from
the ARP Reply was received (assuming the link layer
carries the source address and the driver supplies it).
acceptable ARP reply for destination IP address D can only
from LL address x, where the routing cache maps D -> E and
ARP cache gives x as the translation of E. This validation
Braden, Postel & Rekhter [Page 16]
RFC 1620 Shared Media IP Architecture May 1994
involving both routing and ARP caches, might be ugly
implement in a strictly-layered implementation. It would
natural if layering were already violated by combining the
cache and routing cache
It is possible for the link layer to have security mechanisms
could interfere with IP-layer connectivity. In particular,
could possible be non-transitivity of logical interconnection
a shared medium. In particular, some large public data networks
include configuration options that could allow Net A to talk to Net
and Net B to talk to Net C, but prevent A from talking directly to C
In this case, the routing protocols have to be sophisticated
to handle such anomalies
6.
We have discussed four possible extensions to the
architecture to allow hop-efficient forwarding of IP datagrams
shared media, when this optimization is allowed by IP-
firewalls. We do not draw any conclusions in this paper about
best mechanisms
Our suggested extensions are evolutionary, leaving intact the
ideas of the current Internet architecture. It would be possible
make (and some have suggested) much more radical changes
accommodate shared media. In the extreme, one could entirely
the inner clouds in Figure 2, so that there would be no
network structure within the SM. The IP addresses would then
logical, and some mechanism of distributed servers would be needed
find routes within this random haze. We think this approach
all the requirements for management and security in today's Internet
It might make a good research paper, but it would not be
Internet design strategy
7.
We are grateful to Keith McGloghrie, Joel Halpern, and others
rubbed our noses in this problem. We also acknowledge Tony
(cisco), Greg Minshall (Novell), and John Garrett (AT&T) for
review and constructive comments. We are also grateful to
Gilliland who supplied the paper tablecloth, colored crayons,
fine food that allowed these ideas to be assembled initially
Braden, Postel & Rekhter [Page 17]
RFC 1620 Shared Media IP Architecture May 1994
8.
[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP
Suite", ACM CCR, v. 19. no. 2, April 1989.
[Garrett93] Garrett, J., Hagan, J. and J. Wong, "Directed ARP",
1433, AT&T Bell Laboratories, University of Pennsylvania,
1993.
[Plummer82] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, MIT, November 1982.
[Halpern93] Halpern, J., Private Communication, July 1993.
[Heinanen93] Heinanen, J., "NBMA Address Resolution Protocol (
ARP)", Work in Progress, June 1993.
[Laubach93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[Postel81a] Postel, J., "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[Postel81b] Postel, J., "Internet Control Message Protocol-
Internet Program Protocol Specification", STD 5, RFC 792, ISI
September 1981.
[PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA
Protocol", Computer Networks 5, pp. 261-271, 1983.
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information
Institutue, October 1989.
Braden, Postel & Rekhter [Page 18]
RFC 1620 Shared Media IP Architecture May 1994
Authors'
Bob
Information Sciences
University of Southern
4676 Admiralty
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Braden@ISI.
Jon
Information Sciences
University of Southern
4676 Admiralty
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Postel@ISI.
Yakov
Office 32-017
T.J. Watson Research Center, IBM Corp
P.O. Box 218,
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: Yakov@WATSON.IBM.
Braden, Postel & Rekhter [Page 19]
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
