rfc2775.txt

RFC 的详细文档！


RFC 2775                 Internet Transparency             February 2000


   selected traffic, usually belonging to a very limited set of
   applications). Firewalls, by their nature, fundamentally limit
   transparency.

3.3.2 SOCKS

   A footnote to the effect of firewalls is the SOCKS mechanism [RFC
   1928] by which untrusted applications such as telnet and ftp can
   punch through a firewall.  SOCKS requires a shim library in the
   Intranet client, and a server in the firewall which is essentially an
   application level relay. As a result, the remote server does not see
   the real client; it believes that the firewall is the client.

3.4 Private addresses

   When the threat of IPv4 address exhaustion first arose, and in some
   cases user sites were known to be "pirating" addresses for private
   use, a set of official private addresses were hurriedly allocated
   [RFC 1597] and later more carefully defined [BCP 5].  The legitimate
   existence of such an address allocation proved to very appealing, so
   Intranets with large numbers of non-global addresses came into
   existence. Unfortunately, such addresses by their nature cannot be
   used for communication across the public Internet; without special
   measures, hosts using private addresses are cut off from the world.

   Note that private address space is sometimes asserted to be a
   security feature, based on the notion that outside knowledge of
   internal addresses might help intruders. This is a false argument,
   since it is trivial to hide addresses by suitable access control
   lists, even if they are globally unique - indeed that is a basic
   feature of a filtering router, the simplest form of firewall. A
   system with a hidden address is just as private as a system with a
   private address.  There is of course no possible point in hiding the
   addresses of servers to which outside access is required.

   It is also worth noting that the IPv6 equivalent of private
   addresses, i.e. site-local addresses, have similar characteristics to
   BCP 5 addresses, but their use will not be forced by a lack of
   globally unique IPv6 addresses.

3.5 Network address translators

   Network address translators (NATs) are an almost inevitable
   consequence of the existence of Intranets using private addresses yet
   needing to communicate with the Internet at large. Their
   architectural implications are discussed at length in [NAT-ARCH], the
   fundamental point being that address translation on the fly destroys
   end-to-end address transparency and breaks any middleware or



Carpenter                    Informational                      [Page 7]

RFC 2775                 Internet Transparency             February 2000


   applications that depend on it. Numerous protocols, for example
   H.323, carry IP addresses at application level and fail to traverse a
   simple NAT box correctly. If the full range of Internet applications
   is to be used, NATs have to be coupled with application level
   gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be
   updated whenever a new address-dependent application comes along.  In
   practice, NAT functionality is built into many firewall products, and
   all useful NATs have associated ALGs, so it is difficult to
   disentangle their various impacts.

3.6 Application level gateways, relays, proxies, and caches

   It is reasonable to position application level gateways, relays,
   proxies, and caches at certain critical topological points,
   especially the Intranet/Internet boundary.  For example, if an
   Intranet does not use SMTP as its mail protocol, an SMTP gateway is
   needed. Even in the normal case, an SMTP relay is common, and can
   perform useful mail routing functions, spam filtering, etc. (It may
   be observed that spam filtering is in some ways a firewall function,
   but the store-and-forward nature of electronic mail and the
   availability of MX records allow it to be a distinct and separate
   function.)

   Similarly, for a protocol such as HTTP with a well-defined voluntary
   proxy mechanism, application proxies also serving as caches are very
   useful. Although these devices interfere with transparency, they do
   so in a precise way, correctly terminating network, transport and
   application protocols on both sides. They can however exhibit some
   shortfalls in ease of configuration and failover.

   However, there appear to be cases of "involuntary" applications level
   devices such as proxies that grab and modify HTTP traffic without
   using the appropriate mechanisms, sometimes known as "transparent
   caches", or mail relays that purport to remove undesirable words.
   These devices are by definition not transparent, and may have totally
   unforeseeable side effects.  (A possible conclusion is that even for
   non-store-and-forward protocols, a generic diversion mechanism
   analogous to the MX record would be of benefit. The SRV record [RFC
   2052] is a step in this direction.)

3.7 Voluntary isolation and peer networks

   There are communities that think of themselves as being so different
   that they require isolation via an explicit proxy, and even by using
   proprietary protocols and addressing schemes within their network. An
   example is the WAP Forum which targets very small phone-like devices
   with some capabilities for Internet connectivity. However, it's not




Carpenter                    Informational                      [Page 8]

RFC 2775                 Internet Transparency             February 2000


   the Internet they're connecting directly to. They have to go through
   a proxy. This could potentially mean that millions of devices will
   never know the benefits of end-to-end connectivity to the Internet.

   A similar effect arises when applications such as telephony span both
   an IP network and a peer network layer using a different technology.
   Although the application may work end-to-end, there is no possibility
   of end-to-end packet transmission.

3.8 Split DNS

   Another consequence of the Intranet/Internet split is "split DNS" or
   "two faced DNS", where a corporate network serves up partly or
   completely different DNS inside and outside its firewall. There are
   many possible variants on this; the basic point is that the
   correspondence between a given FQDN (fully qualified domain name) and
   a given IPv4 address is no longer universal and stable over long
   periods.

3.9 Various load-sharing tricks

   IPv4 was not designed to support anycast [RFC 1546], so there is no
   natural approach to load-sharing when one server cannot do the job.
   Various tricks have been used to resolve this (multicast to find a
   free server, the DNS returns different addresses for the same FQDN in
   a round-robin, a router actually routes packets sent to the same
   address automatically to different servers, etc.). While these tricks
   are not particularly harmful in the overall picture, they can be
   implemented in such a way as to interfere with name or address
   transparency.

4. Summary of current status and impact

   It is impossible to estimate with any numerical reliability how
   widely the above inventions have been deployed. Since many of them
   preserve the illusion of transparency while actually interfering with
   it, they are extremely difficult to measure.

   However it is certain that all the mechanisms just described are in
   very widespread use; they are not a marginal phenomenon. In corporate
   networks, many of them are the norm. Some of them (firewalls, relays,
   proxies and caches) clearly have intrinsic value given the Intranet
   concept. The others are largely artefacts and pragmatic responses to
   various pressures in the operational Internet, and they must be
   costing the industry very dearly in constant administration and
   complex fault diagnosis.





Carpenter                    Informational                      [Page 9]

RFC 2775                 Internet Transparency             February 2000


   In particular, the decline of transparency is having a severe effect
   on deployment of end-to-end IP security. The Internet security model
   [SECMECH] calls for security at several levels (roughly, network,
   applications, and object levels).  The current network level security
   model [RFC 2401] was constructed prior to the recognition that end-
   to-end address transparency was under severe threat.  Although
   alternative proposals have begun to emerge [HIP] the current reality
   is that IPSEC cannot be deployed end-to-end in the general case.
   Tunnel-mode IPSEC can be deployed between corporate gateways or
   firewalls.  Transport-mode IPSEC can be deployed within a corporate
   network in some cases, but it cannot span from Intranet to Internet
   and back to another Intranet if there is any chance of a NAT along
   the way.

   Indeed, NAT breaks other security mechanisms as well, such as DNSSEC
   and Kerberos, since they rely on address values.

   The loss of transparency brought about by private addresses and NATs
   affects many applications protocols to a greater or lesser extent.
   This is explored in detail in [NAT-PROT]. A more subtle effect is
   that the prevalence of dynamic addresses (from DHCP, SLIP and PPP)
   has fed upon the trend towards client/server computing.  Today it is
   largely true that servers have fixed addresses, clients have dynamic
   addresses, and servers can in no way assume that a client's IP
   address identifies the client. On the other hand, clients rely on
   servers having stable addresses since a DNS lookup is the only
   generally deployed mechanism by which a client can find a server and
   solicit service.  In this environment, there is little scope for true
   peer-to-peer applications protocols, and no easy solution for mobile
   servers. Indeed, the very limited demand for Mobile IP might be
   partly attributed to the market dominance of client/server
   applications in which the client's address is of transient
   significance. We also see a trend towards single points of failure
   such as media gateways, again resulting from the difficulty of
   implementing peer-to-peer solutions directly between clients with no
   fixed address.

   The notion that servers can use precious globally unique addresses
   from a small pool, because there will always be fewer servers than
   clients, may become anachronistic when most electrical devices become
   network-manageable and thus become servers for a management protocol.
   Similarly, if every PC becomes a telephone (or the converse), capable
   of receiving unsolicited incoming calls, the lack of stable IP
   addresses for PCs will be an issue. Another impending paradigm shift
   is when domestic and small-office subscribers move from dial-up to
   always-on Internet connectivity, at which point transient address
   assignment from a pool becomes much less appropriate.




Carpenter                    Informational                     [Page 10]

RFC 2775                 Internet Transparency             February 2000


   Many of the inventions described in the previous section lead to the
   datagram traffic between two hosts being directly or indirectly
   mediated by at least one other host. For example a client may depend
   on a DHCP server, a server may depend on a NAT, and any host may
   depend on a firewall. This violates the fate-sharing principle of
   [Saltzer] and introduces single points of failure. Worse, most of
   these points of failure require configuration data, yet another
   source of operational risk. The original notion that datagrams would
   find their way around failures, especially around failed routers, has
   been lost; indeed the overloading of border routers with additional
   functions has turned them into critical rather than redundant
   components, even for multihomed sites.

   The loss of address transparency has other negative effects.  For
   example, large scale servers may use heuristics or even formal
   policies that assign different priorities to service for different
   clients, based on their addresses. As addresses lose their global
   meaning, this mechanism will fail. Similarly, any anti-spam or anti-
   spoofing techniques that rely on reverse DNS lookup of address values
   can be confused by translated addresses. (Uncoordinated renumbering
   can have similar disadvantages.)

   The above issues are not academic. They add up to complexity in
   applications design, complexity in network configuration, complexity
   in security mechanisms, and complexity in network management.
   Specifically, they make fault diagnosis much harder, and by
   introducing more single points of failure, they make faults more
   likely to occur.

5. Possible future directions

5.1 Successful migration to IPv6

   In this scenario, IPv6 becomes fully implemented on all hosts and
   routers, including the adaptation of middleware, applications, and
   management systems. Since the address space then becomes big enough
   for all conceivable needs, address transparency can be restored.
   Transport-mode IPSEC can in principle deploy, given adequate security
   policy tools and a key infrastructure.  However, it is widely
   believed that the Intranet/firewall model will certainly persist.

   Note that it is a basic assumption of IPv6 that no artificial
   constraints will be placed on the supply of addresses, given that
   there are so many of them. Current practices by which some ISPs
   strongly limit the number of IPv4 addresses per client will have no
   reason to exist for IPv6. (However, addresses will still be assigned
   prudently, according to guidelines designed to favour hierarchical
   routing.)



Carpenter                    Informational                     [Page 11]

RFC 2775                 Internet Transparency             February 2000


   Clearly this is in any case a very long term scenario, since it
   assumes that IPv4 has declined to the point where IPv6 is required
   for universal connectivity. Thus, a viable version of Scenario 5.3 is
   a prerequisite for Scenario 5.1.

5.2 Complete failure of IPv6

   In this scenario, IPv6 fails to reach any significant level of
   operational deployment, IPv4 addressing is the only available
   mechanism, and address transparency cannot be restored. IPSEC cannot
   be deployed globally in its current form. In the very long term, the
   pool of globally unique IPv4 addresses will be nearly totally
   allocated, and new addresses will generally not be available for any
   purpose.

   It is unclear exactly what is likely to happen if the Internet
   continues to rely exclusively on IPv4, because in that eventuality a
   variety of schemes are likely to promulgated, with a view toward
   providing an acceptable evolutionary path for the network. However,
   we can examine two of the more simplistic sub-scenarios which are
   possible, while realising that the future would be unlikely to match
   either one exactly:

5.2.1 Re-allocating the IPv4 address space

   Suppose that a mechanism is created to continuously recover and re-
   allocate IPv4 addresses. A single global address space is maintained,
   with all sites progressively moving to an Intranet private address
   model, with global addresses being assigned temporarily from a pool
   of several billion.

   5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT
           (NAT with port number translation). This has the disadvantage
           that the host is unaware of the unique address being used for
           its traffic, being aware only of its ambiguous private
           address, with all the problems that this generates. See
           [NAT-ARCH].

   5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP
           addressing implemented at the host rather than by a NAT box.
           See [RSIP]. In this case the host is aware of its unique
           address, allowing for substantial restoration of the end-to-
           end usefulness of addresses, e.g. for TCP or cryptographic
           checksums.







Carpenter                    Informational                     [Page 12]

RFC 2775                 Internet Transparency             February 2000