rfc1620.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,067 行 · 第 1/3 页
TXT
1,067 行
Network Working Group B. BradenRequest for Comments: 1620 ISICategory: Informational J. Postel ISI Y. Rekhter IBM Research May 1994 Internet Architecture Extensions for Shared MediaStatus 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 ............................................... 19Braden, Postel & Rekhter [Page 1] RFC 1620 Shared Media IP Architecture May 19941. 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 connectBraden, 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 procedureBraden, 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.⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?