外文翻译---路由信息协议(编辑修改稿)

外文翻译---路由信息协议(编辑修改稿)内容摘要：

between two hosts. Locators must be valid only as long as the routing mechanisms so require (which could be shorter or longer than the lifetime of a munication). It will be noted that it is a contingent fact of history that the same address space and the same fields in the IP header (source and destination addresses) are used by RFC791 and RFC793 for both identifiers and locators, and that in the traditional Inter a host39。 s identifier is identical to its locator, as well as being spatially unique (unambiguous) and temporally unique (constant). These uniqueness conditions had a number of consequences for design assumptions of routing (the infrastructure that IPv4 locators enable) and transport protocols (that which depends on the IP connectivity). Spatial uniqueness of an address meant that it served as both an interface identifier and a host identifier, as well as the key to the routing table. Temporal uniqueness of an address meant that there was no need for TCP implementations to maintain state regarding identity of the far end, other than the IP address. Thus IP addresses could be used both for endtoend IP security and for binding upper layer sessions. Generally speaking, the use of IPv4 addresses as locators has been considered more important than their use as identifiers, and whenever there has been a conflict between the two uses, the use as a locator has prevailed. That is, it has been considered more useful to deliver the packet, then worry about how to identify the end points, than to provide 共 6 页 第 7 页 identity in a packet that cannot be delivered. In other words, there has been intensive work on routing protocols and little concrete work on other aspects of address usage. 3. Ideal properties. Whatever the constraints mentioned above, it is easy to see the ideal properties of identifiers and locators. Identifiers should be assigned at birth, never change, and never be reused. Locators should describe the host39。 s position in the work39。 s topology, and should change whenever the topology changes. Unfortunately neither of the these ideals are met by IPv4 addresses. The remainder of this document is intended as a snapshot of the current real situation. 4. Overview of the current situation of IPv4 addresses. It is a fact that IPv4 addresses are no longer all globally unique and no longer all have indefinite lifetimes. Addresses are no longer globally unique locators [RFC1918] shows how corporate works, . Intras, may if necessary legitimately reuse a subset of the IPv4 address space, forming multiple routing realms. At the boundary between two (or more) routing realms, we may find a spectrum of devices that enables munication between the realms. At one end of the spectrum is a pure Application Layer Gateway (ALG). Such a device acts as a termination point for the application layer data stream, and is visible to an enduser. For example, when an enduser Ua in routing realm A wants to municate with an enduser Ub in routing realm B, Ua has first to explicitly establish munication with the ALG that interconnects A and B, and only via that can Ua establish munication with Ub. We term such a gateway a nontransparent ALG. Another form of ALG makes munication through the ALG transparent to an end user. Using the previous example, with a transparent ALG, Ua would not be required to establish explicit connectivity to the ALG first, before starting to municate with Ub. Such connectivity will be established transparently to Ua, so that Ua would only see connectivity to Ub. For pleteness, note that it is not necessarily the case that municating via an ALG involves changes to the work header. An ALG could be used only at the beginning of a session for the purpose of authentication, after which the 共 6 页 第 8 页 ALG goes away and munication continues natively. Both nontransparent and transparent ALGs are required (by definition) to understand the syntax and semantics of the application data stream. ALGs are very simple from the viewpoint of work layer architecture, since they appear as Inter hosts in each realm, . they act as origination and termination points for munication. At the other end of the spectrum is a Network Address Translator (NAT) [RFC1631]. In the context of this document we define a NAT as a device that just modifies the work and the transport layer headers, but does not understand the syntax/semantics of the application layer data stream (using our terminology what is described in RFC1631 is a device that has both the NAT and ALG functionality). In the standard case of a NAT placed between a corporate work using private addresses [RFC1918] and the public Inter, that NAT changes the source IPv4 address in packets going towards the Inter, and changes the destination IPv4 address in packets ing from the Inter. When。