Network Working Group C. Vogt Internet-Draft Ericsson Expires: September 10, 2009 March 9, 2009 Qualifying the Harmfulness of Address Translation draft-vogt-address-translation-harmfulness-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 10, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Address translation is widely considered harmful because its existing variants conflict with well-established design principles of the Internet engineering community. Still, address translation has become common practice despite technical problems because it Vogt Expires September 10, 2009 [Page 1] Internet-Draft Qualifying the Harmfulness of NAT March 2009 constitutes an easy-to-deploy solution to a set of common operational needs. Since some of these needs will continue to exist in IP version 6, there is concern within the Internet engineering community about the potential proliferation of harmful technology from IP version 4 to IP version 6. This document addresses this concern. It compares feasible address translator designs with respect to harmful implications, explains why the problems of address translation, as used today, are to a significant extent specific to IP version 4, and shows how the problems can be mitigated in IP version 6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Purposes of Address Translation . . . . . . . . . . . . . . . 3 3. Functional Components of Address Translation . . . . . . . . . 5 4. Implications of Address Translation . . . . . . . . . . . . . 6 4.1. One-to-One Address Translation . . . . . . . . . . . . . . 6 4.2. Many-to-One Address Translation . . . . . . . . . . . . . 9 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Vogt Expires September 10, 2009 [Page 2] Internet-Draft Qualifying the Harmfulness of NAT March 2009 1. Introduction One of the design principles most well-heeded by the Internet engineering community is that addresses have end-to-end validity and do not change in packets en route. This principle is being challenged by the widespread use of address translation on the Internet. Address translators rewrite addresses in packets en route, typically at network borders, to satisfy network operators' desire for provider independence, topology concealment, or conservation of global addresses. The incentives for deploying address translation are strong, even though the technique, as used today for IP version 4, has profound drawbacks. Since the incentives are furthermore partly independent of the IP version, there is concern within the Internet engineering community about the potential proliferation of harmful technology from IP version 4 to IP version 6. This document addresses this concern by qualifying the harmfulness of feasible address translator designs in IP version 4 and 6. The document makes three contributions to this end: First, it compares potentially harmful implications of different address translator designs. Second, it infers that many of the problems with address translation as deployed today are due to address overloading, a technique that helps conserving global addresses, rather than because addresses are rewritten in packets en route. Third, the document argues that, while address overloading is inevitable in IP version 4 due to the shortage of global addresses [REF], address translation in IP version 6 does not require address overloading and could hence, if designed rightly, be considerably less problematic than address translation in IP version 4. The following sections of this document are organized as follows: Section 2 explains the purposes for which address translation is used, and section 3 identifies the components of address translation that are necessary to achieve these purposes. Section 4 describes the implications of address translation, and it shows that many resulting problems can be attributed to address overloading being one of the components. Section 5 concludes that these problems are avoidable in address translation for IP version 6, where address overloading is dispensable. 2. Purposes of Address Translation Network operators frequently apply address translation to separate the addresses they use locally in their networks from the global addresses at which the networks are reachable from the Internet. They do this for any of the following three purposes: Vogt Expires September 10, 2009 [Page 3] Internet-Draft Qualifying the Harmfulness of NAT March 2009 o Provider independence: Network operators desire the flexibility to change providers at low cost, in order to avoid lock-in to any particular provider. o Topology concealment: Network operators may want to hide a network's local topology from the rest of the Internet for security reasons. o Global address conservation: Network operators see increasing pressure to conserve global IP version 4 addresses due to the imminent runout of unallocated global IP version 4 addresses [REF]. A usecase of address translation to achieve provider independence is in residential networks or small enterprise networks, which either cannot afford, or are not eligible for, global provider-independent addresses. Internet registries restrict assignments of global provider-independent addresses to networks of sufficient size in an effort to prevent excessive load on the global routing system. This is deemed necessary because global provider-independent addresses cannot be aggregated as efficiently as provider-assigned addresses, and hence increase the load of the global routing system [REF]. The recommended practice for these networks is to use address space assigned by their providers, and to renumber in the event of a provider change. Renumbering can be a smooth process in sufficiently optimized networks. Unfortunately, though, experience [REF] shows that the process often involves substantial manual labor, and is hence costly and time-consuming. Although the addresses of hosts could be changed automatically via DHCP, routers and servers still typically have manually configured addresses, and would therefore have to be renumbered manually. Old addresses may also be preconfigured in applications, firewalls, and operations and management systems [REF]. Address translation helps avoiding network renumbering without global provider-independent addresses. Network operators can use local provider-independent addresses internally, and they translate those onto global addresses assigned by their providers. A security-related usecase of address translation to for denial-of- service attack protection. The usual network-topological assignment of addresses provides a means to infer the topology of a network by remote hosts. Attackers may use this information to identify attack targets. For example, a denial-of-service attack against a server may more easily be executed via a host on the server's link, and such a host can typically be identified based on comparing its IP address to the IP address of the server in question. Address translation can conceil the internal topology of a network, by mapping local and global addresses such that the topological structuring of local Vogt Expires September 10, 2009 [Page 4] Internet-Draft Qualifying the Harmfulness of NAT March 2009 addresses cannot be derived from global addresses. The conservation of global addresses provides a third usecase for address translation. It is of common interest among operators of IP version 4 networks, for which the dire shortage of global IP version 4 addresses makes network expansion difficult. This, in turn, can have an negative impact on revenue. Address translation helps conserving global addresses because it allows multiple hosts with separate local addresses to share one global address. 3. Functional Components of Address Translation In order to accomplish the purposes identified above, address translation incorporates two functional components: o Address rewriting: The local and global addresses of a network are mapped, and swapped accordingly in packets leaving or entering the network. o Address overloading: Multiple local addresses are mapped onto a single global address. To enable demultiplexing of packets received at a global address back onto the right local address, address translators store the corresponding local address as connection-specific state, and they use port numbers in the received packets as indexes into this state. Address rewriting affords provider independence and topology concealment. Provider independence is achieved through the decoupling of a network's local addresses from the global addresses assigned by the network's provider. The local addresses hence do not need to change if the network changes providers. This eliminates the need to renumber. Topology hiding can be achieved either by overloading a single global address with a large portion of local addresses, or by choosing, and keeping secret, a non-trivial permutation based on which local and global addresses are mapped. Simple address rewriting without address overloading requires at least one global address per host, which maps one-to-one onto its corresponding global address. To conserve global addresses, it is necessary to have multiple hosts share one global address. This can be achieved by combining address rewriting with address overloading. Given that the functional component of address overloading is optional, two types of address translation can be distinguished: Vogt Expires September 10, 2009 [Page 5] Internet-Draft Qualifying the Harmfulness of NAT March 2009 o One-to-one address translation, which consists of address rewriting without address overloading, and which achieves provider independence and topology concealment. o Many-to-one address translation, which combines address rewriting with address overloading, and which achieves global address conservation in addition to provider independence and topology concealment. In the following, the architectural impact of address translation will be evaluated separately for its two types. 4. Implications of Address Translation Since address translation changes the way hosts are addressed and packets are forwarded, it has a signifiant impact on Internet architecture. The analysis below examines the harmfulness of this impact. It shows potential problems that result from address translation, and analyzes the feasibility and cost of mitigating those problems. One-to-one address translation and many-to-one address translation are thereby considered separately, since the functional components of address rewriting and address overloading each have their own architectural impact. 4.1. One-to-One Address Translation Since address translation renders hosts reachable at different addresses depending on the location of a given peer, peers must be enabled to discover and use one of the host's addresses they can reach. A peer's location hence governs which of a host's addresses can be used in the IP headers or, for referrals, in the payloads of packets exchanged with the peer. Since address translators rewrite only IP headers, addresses referred to in packet payloads may have to be global end to end. This calls for support in hosts with translated addresses as well as their authoritative DNS servers. Authoritative DNS servers must refer peers to the global addresses of a host if the intended communication will go via an address translator. Hosts must use their global addresses for address referrals in packets they send to peers via an address translator, and they must recognize their global addresses in packets received via an address translator. An example of a protocol that may require hosts to refer to their global address is the Session Initiation Protocol [REF], a protocol used to bootstrap multimedia applications. An example of a protocol that may require hosts to recognize their global address in received packets is ICMP [REF]. ICMP error and notification messages may include a copy of Vogt Expires September 10, 2009 [Page 6] Internet-Draft Qualifying the Harmfulness of NAT March 2009 the packet by which they were triggered. The triggering packet, in turn, may include translated, global addresses, which are not reverse-translated when included in the payload of an ICMP message. These properties imply that, for one-to-one address translation to function properly, two components are needed: o Obtainability of global addresses: A host with translated addresses and its authoritative DNS server must be able to obtain the global addresses of the host. They must either be configured with the global addresses or have means to dynamically discover them. o Peer-dependent address selection: Addresses referred to in packet payloads, including responses from authoritative DNS servers, must be reachable from the peer's location. The following shows that both components can be realized in a simple and non-disruptive manner based on suitable host support. Host support is critical, though, since in its absence one-to-one address translation breaks applications that use address referrals. Obtainability of global addresses may in the simplest case be realized by configuring applications and authoritative DNS servers with the global addresses of hosts. In the case of authoritative DNS servers, this approach corresponds to common practice. It is also tractable because, in one-to-one address translation, global addresses are static, hence the configuration usually does not have to be modified. While pre-configuration would in principle also suffice to make applications aware of global addresses, auto- discovery of global addressses is typically preferred to reduce administrative complexity. Standard methods exists for this [REF]. They discover a global address by inquiring of infrastructure what a packet's source address looks like after translation. The methods were broadly introduced to handle many-to-one address translation in the IP version 4 Internet. Still, since neither the methods nor the infrastructure they leverage can be expected to always be available, there may be situations in which applications will fail in the presence of address translation. It is noteworthy that, for one-to-one address translation, the discovery of global addresses by hosts could be simplified compared to existing methods. Existing discovery methods were designed not only to discover global addresses, but also to initialize disambiguation state in address translators. Since one-to-one address translation is stateless, the latter functionality can be eliminated for the benefit of simplicity. For example, a simplified method for hosts to discover their global addresses is for access Vogt Expires September 10, 2009 [Page 7] Internet-Draft Qualifying the Harmfulness of NAT March 2009 routers to announce address mapping rules, based on which hosts derive their global addresses given their local addresses. In the case where addresses are translated by swapping their prefix, a mapping rule could be as simple as a pair of local and global address prefixes. This discovery method would be similar to the existing practice of auto-configuring addresses based on on-link address prefixes announced by access routers. For hosts and authoritative DNS servers to refer peers to addresses they can reach, three approaches are possible: o Pre-selection: Address referrals include either only local addresses or only global addresses of a host, depending on the location of the peer. This approach is also known as "split horizon". o Post-selection: Address referrals always include both global and local addresses, independent of the location of the peer. It is left to destination address selection mechanisms in peers to find an address that is reachable from a peer's location. o Fixed: Address referrals always include only global addresses, independent of the location of the peer. The suitability of each of these approaches depends on the deployment scenario: In deployments where topology concealment is desired, address referrals can only be pre-selected or fixed, because referrals with local addresses could reveal information about the topology to be concealed. Address referrals must also be pre- selected or fixed where peers may be unable to select the right address among the addresses they have been referred to. While suitable destination address selection mechanisms are standard [REF] in IP version 6, they cannot be expected in IP version 4. An advantageous of pre-selected address referrals over fixed address referrals is that the former always provide an address that the peer can reach via a shortest path, while the latter may cause a connection to traverse an address translator unnecessarily. On the other hand, a disadvantage of pre-selected address referrals is that they require knowledge of a peer's location. If this is unavailable, address referrals must be fixed where topology concealment is desired, or where peers may not support destination address selection appropriately. Post-selected address referrals are the most robust approach in IP version 6 when topology concealment is not necessary. They provide peers with complete address information that remains valid even when being recursively referred to between peers, or when being carried by Vogt Expires September 10, 2009 [Page 8] Internet-Draft Qualifying the Harmfulness of NAT March 2009 a mobile peer between the scopes of the local and global addresses. For the same reason, post-selected address referrals are used in upcoming standards for multi-homing [REF] in IP version 6. From the perspective of a peer, it is invisible whether one of the addresses is the translation of the other, or whether the purpose of the addresses is to locate different interfaces on a host. 4.2. Many-to-One Address Translation Given the foregoing analysis of the Internet-architectural impacts of one-to-one address translation, and given that many-to-one address translation differs from one-to-one address translation only in the extra use of address overloading, the impact of many-to-one address translation on Internet architecture can be evaluated based on solely the implications of address overloading. Those are twofold: o Ambiguous addresses: Overloading renders a global address ambiguous with respect to the host that is reachable through it because it maps a single global address onto the local addresses of multiple hosts. o Connection-specific forwarding: Address overloading requires forwarding that is connection-specific so that the recipient host of packets destined to an overloaded address can be disambiguated. These implications are in conflict with fundamental Internet- architectural principles [REF], which mandate that global address are both unambiguous, and sufficient for connection-agnostic forwarding. The conflict leads to the following two problems of many-to-one address translation, with may have a harmful impact on Internet architecture as the subsequent analysis shows. o No support for certain connection types: Many-to-one address translation relies on the availability and modifiability of port numbers to identify the connection of a packet. Packets without port numbers are therefore dropped, and so are packets with port numbers that are not modifiable due to encryption and authentication. Furthermore, new connections must be initiated in a way that permits the establishment of disambiguation state. Other connection initiation procedures are not possible, such as the immediate transmission of packets to a global address. o Reduced network robustness: Address translators constitute a single point of failure for two reasons: First, since they maintain disambiguation state that connections depend upon, they limit a network's ability to reroute traffic in the event of failures. Second, address translators may deliberately dispose of disambiguation state after temporary absence of packets in a Vogt Expires September 10, 2009 [Page 9] Internet-Draft Qualifying the Harmfulness of NAT March 2009 connection, which may make it impossible to resume the connection afterwards. Methods to mitigate these problems are either not always applicable, or they are complex and hence a source of capital and operational cost. Limited applicability is a shortfall of methods that attempt to enable support for a wider set of connection types in many-to-one address translation. One method [REF] enables many-to-one address translation for connections without accessible port numbers by tunneling packets in an extra layer of UDP. The additional UDP header in packets then provides the port numbers that address translators need to identify the connection of the packets. Unfortunately, UDP tunneling in general cannot enable all connections without accessible port numbers because it requires support at both ends of a connection: Both the host which address is being translated, and the peer are involved, independent of whether the address of the peer is translated as well. Where bilateral support is not provided, connections without accessible port numbers cannot pass through many-to-one address translation. Another method [REF] to increase the applicability of many-to-one address translation enables hosts with overloaded addresses to receive incoming connections initiated by a peer. Without such method, new connections must be initiated by the host which address is overloaded. Only then does the first packet include the local address to be translated, which can be memorized by the address translator -- in conjunction with the port numbers from the packet and a mapped global address -- to enable subsequent disambiguation of packets received at the mapped global address. To enable connections initiated by a peer, the DNS is used as a point of rendezvous between a host and its peer [REF]. A DNS query by the peer for the host's DNS name is then interpreted as a desire to communicate with the host, and it triggers the establishment of disambiguation state in an address translator. Unfortunately, also this method is of limited applicability, as it takes affect only in those cases where the peer actually performs a DNS lookup prior to connection establishment. This may not always be the case, such as when the peer was previously referred to, or pre-configured with, the address of the host that it wants to reach. A common method to increase the robustness of networks with address translators is to set up the address translators redundantly. This enables failover of connections from one path to another. While redundant provisioning is straightforward for one-to-one address translation, it is complex, and therefore expensive to deploy and maintain, for many-to-one address translation. Address translators that do not overload addresses function without disambiguation state and can hence substitute for each other without prior Vogt Expires September 10, 2009 [Page 10] Internet-Draft Qualifying the Harmfulness of NAT March 2009 synchronization. The cost of redundancy is then directly proportional to the number of address translators deployed. However, address translators that perform address overloading do maintain disambiguation state, and must hence be continuously synchronized with backup address translators. This increases the cost of redundancy to being proportional to the square of the number of address translators deployed. Increasing the robustness of networks with many-to-one address translators is therefore expensive, and the complexity involved constitutes a potential failure source on its own. 5. Conclusion This document has shown that the harmful implications of address translation are formost due to the overloading of multiple local addresses onto a single global address. Such many-to-one address translation, which is pursued in the IP version 4 Internet to conserve global addresses, is problematic: It fails to support all connection types, it reduces network robustness because it constitutes a single point of failure, and it requires extra host functionality to support address referrals in applications. One-to- one address translation, which does not overload addresses, would be less problematic: It works for all connection types, and it does not constitute a single point of failure. Furthermore, although one-to- one address translation continues to require extra host functionality to support address referrals, the host functionality can be simplified compared to what is necessary in many-to-one address translation. The superiority of one-to-one address translation over many-to-one address translation naturally leads to the question whether the former can satisfy the demand for address translation, as it has become apparent through the wide deployment of address translators in today's Internet. Clearly, this depends on the availability of global addresses. One-to-one address translation, which requires one global address per local address, is unsuitable for IP version 4, where the shortage of global addresses necessitates the use of address overloading. For IP version 6, however, one-to-one address translation is suitable, as the sufficient number of global addresses here makes address overloading dispensable. Address translation in IP version 6 could hence, if designed without address overloading, be considerably less harmful than address translation in IP version 4. Appendix A. Acknowledgment The author would like to thank James Kempf, Tony Li, David Sinicrope, Vogt Expires September 10, 2009 [Page 11] Internet-Draft Qualifying the Harmfulness of NAT March 2009 Suresh Krishnan, and Zoltan Turanyi for their reviews of this document and their valuable comments. This document was generated using the xml2rfc tool. Author's Address Christian Vogt Ericsson Research 200 Holger Way San Jose, CA 95134 United States Email: christian.vogt@ericsson.com Vogt Expires September 10, 2009 [Page 12]