doc: Add RFC documents

1 files changed, 1066 insertions, 0 deletions

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