Network Working Group G. Daley Internet-Draft July 14, 2009 Intended status: Standards Track Expires: January 15, 2010 Achieving Addressing Functions in IPv6 without using NAT draft-daley-ipv6-nonat6-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 January 15, 2010. 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 Proposals have been made to include Network Address Translation (NAT) in IPv6. Network Address Translation substitutes a source address in the outbound Packet headers at the Internet Egress point for one Daley Expires January 15, 2010 [Page 1] Internet-Draft IPv6 Function without NAT July 2009 present at the network edge. It then matches the responding packets by destination address, and restores the original headers. NAT itself is not a feature. It is a mechanism which provides features at an application cost. This document identifies features which are supplied by NAT in IPv4 and how these features may be provisioned in IPv6. Both NAT and application-friendly alternatives are presented. Daley Expires January 15, 2010 [Page 2] Internet-Draft IPv6 Function without NAT July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Relationship to previous work . . . . . . . . . . . . . . 4 1.2. Existing NAT Models for IPv6 . . . . . . . . . . . . . . . 5 1.3. Application impacts of existing NAT deployments . . . . . 5 1.3.1. Behaviour of some port address translating IPv4 NATs . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Network Topology Hiding in IPv6 . . . . . . . . . . . . . . . 6 2.1. Network Topology Hiding using Stateful Mappings . . . . . 7 2.2. Network Topology Hiding using Stateless Mappings . . . . . 7 2.2.1. Prefix Only Transformations . . . . . . . . . . . . . 7 2.2.2. Prefix and Suffix Transformations . . . . . . . . . . 8 2.3. Source Address Mappings and NAT . . . . . . . . . . . . . 8 3. Provider Independence in IPv6 . . . . . . . . . . . . . . . . 9 3.1. Using Provider Aggregatable Addresses for Multihoming . . 9 3.1.1. Aggregatable Addresses and host selection . . . . . . 9 3.1.2. Provider Aggregatable Addresses and gateway selection . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3. Limits of Provider Aggregatable Addressing . . . . . . 11 3.2. Provider Independent Addressing and Multihoming . . . . . 12 4. Reduce impacts on the global routing table . . . . . . . . . . 14 5. No prefix reassignment on ISP change . . . . . . . . . . . . . 14 6. Address Amplification . . . . . . . . . . . . . . . . . . . . 16 7. Alternatives to NAT for Network Topology Hiding . . . . . . . 16 7.1. Local Tunnels For network topology hiding . . . . . . . . 17 7.2. Translation extension headers For network Topology Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Address Allocation Channel for NAT . . . . . . . . . . . . 20 8. Problems with NAT and Topology Hiding . . . . . . . . . . . . 20 9. Problems with Local Delivery mechanisms and Topology Hiding . 20 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Local Transport . . . . . . . . . . . . . . . . . . . . . 21 9.3. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 21 9.5. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 21 9.6. Source Address Selection . . . . . . . . . . . . . . . . . 21 10. General problems with Topology Hiding and the Internet . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Daley Expires January 15, 2010 [Page 3] Internet-Draft IPv6 Function without NAT July 2009 1. Introduction Network Address Translation substitutes a source address in the outbound Packet headers at the Internet Egress point for one present at the network edge. It then matches the responding packets by destination address, and restores the original headers [RFC2663]. For some applications, changes in packet headers mismatch application semantics, requiring in-band NAT detection or helper services such as STUN [RFC3489][RFC3947]. The experience with IPv4 has shown that implementing NATs in network gateways is simple, taking few man- months to achieve a production ready solution. The impact of Network Address Translation on IPv4 applications development has been significant, with development of peer-to-peer and address referring applications being hampered [RFC2993]. Until now, NATs have only existed for IPv4, and for transitioning from an IPv6 network to an IPv4 network [RFC2766]. Current IPv6 NAT proposals aim at providing the following functions, aimed at providing "Feature Parity" with IPv4 [I-D.mrw-behave-nat66]: * Topology Concealment * Provider Independence * Reduce impacts on the global routing table * No prefix reassignment on ISP change * Address Amplification This document explores each of these features and identifies capabilities and gaps within the IPv6 protocol suite to deliver them. 1.1. Relationship to previous work The discussion in this document can be seen as an adjunct to existing descriptions of IPv6 and NAT relationships [RFC2993]. Particularly, previous work on Local Network Protection is described in RFC4864 [RFC4864]. This document provides encyclopedic description of alternatives to NAT technologies in delivering addressing features in IPv6. In comparison, the current document provides specific analysis of features and direct comparison of proposed measures for local IPv6 packet delivery. Further work is required to consolidate this analysis either to supplement the information in RFC 4864, or specialize in the particular area of most benefit. Daley Expires January 15, 2010 [Page 4] Internet-Draft IPv6 Function without NAT July 2009 1.2. Existing NAT Models for IPv6 Current NAT proposals for IPv6 allow for a stateless mapping of IPv6 address or prefix at the network boundary [I-D.mrw-behave-nat66], or more traditional stateful NAT and PAT [RFC2663]. Stateful NAT systems store information regarding the interior address used for communication, and allocate another exterior address for communication on the Internet. If packets arrive at another gateway which does not have this stored state, communications fail as no mapping can be made to an interior address. Stateless NAT systems use an algorithmic mapping to identify the exterior address to use on outbound packets, and the reverse mapping to identify the interior address for inbound packets. The scope of the changes depends on the algorithm and its parameters. Arrival of an inbound packet at another gateway will generate the same interior address, so long as the algorithm and parameters are uniformly configured. 1.3. Application impacts of existing NAT deployments While implementation of either stateless or stateful NAT in a gateway is relatively simple to perform, the implications for application programmers are significant. Applications which contain addresses for referral cannot discern their exterior address locally. This means inbound connections can only be provisioned by long term static configuration, or by determination at application run-time of the exterior IP. Existing IPv4 deployment relies heavily on address and port address translation [RFC2766], which has the additional impact that inbound connections cannot consistently be mapped to the same internal address [RFC4787]. As such, mechanisms are required which identify the availability and reachability of sessions at particular ports and addresses. Daley Expires January 15, 2010 [Page 5] Internet-Draft IPv6 Function without NAT July 2009 +---+ SrcIP 192.1.0.1 DstIP 192.1.0.50 +---+ Host A | | SrcPort: 23456 DstPort: 5080 | | \--|---|------------------------------------>| | | | | | | | DstIP 192.1.0.1 SrcIP 192.1.0.50 | | | | DstPort: 10001 SrcPort: 10234 | | | X |<------------------------------------| | Host B | | | | +---+ +---+ Port Server Translator A Port translating NAT receiving an unmapped inbound communication 1.3.1. Behaviour of some port address translating IPv4 NATs Existing NAT IP testing is provided by in-band addressing tests [RFC3489], and by either in-band relaying through external devices [I-D.ietf-mmusic-ice] or hole-punching to establish. Both of these mechanisms rely upon the availability, trust and trust of third parth devices outside the perimeter of the organization. Even where a one-to-one or pool mapping of addresses is available in NAT, applications cannot make assessments about their visible addresses without contacting the exterior network. Where information is provided between end devices, each endpoint must understand that addresses can change in transit. 2. Network Topology Hiding in IPv6 NAT in IPv4 is used also to prevent simple disclosure of topological structures in corporate network environments. This may be performed in order to limit data loss, for commercial purposes, or to reduce information flows due to security concerns [I-D.iab-ipv6-nat]. Proposals for using NAT within IPv6 cite topology hiding as a requirement. Current IPv6 NAT proposals allow for a stateless mapping of an IPv6 address or prefix, or traditional NAT and Port Translation. Other proposals which provide topology hiding use tunnel mechanisms [RFC3775] or discover local routing identifiers for packet transit [I-D.thaler-ipv6-saf]. Independent of whether NAT is in use, topology hiding requires a mapping between external addressing and internal addressing. The delivery of topology hiding within these environments is examined below. Daley Expires January 15, 2010 [Page 6] Internet-Draft IPv6 Function without NAT July 2009 2.1. Network Topology Hiding using Stateful Mappings If using existing stateful address mapping mechanisms for topology hiding, information is lost to the external viewer. This loss of information occurs where the exterior address pool is smaller than the available interior addressing, or where allocation of an exterior address loses structure. I::A -----------> G::A' State Allocation I::B -----------> G::B' such that B' =/=> B and A ' =/=> A, Stateful mapping operations require a return packet from the Internet to be routed by the original gateway or one to which its state mappings have been distributed. State held within the network may be significantly less than the number of hosts in the network. Address reallocation over time could allow further compression of the number of exterior addresses. 2.2. Network Topology Hiding using Stateless Mappings For Stateless address mapping mechanisms, an algorithm provides a one-to-one correspondence between interior addresses and externally visible addresses [I-D.ietf-behave-v6v4-xlate]. This relies upon an algorithmic transform T, which may have site specific parameters, such as internal (I) and external prefixes (G), and a site key (k). Inbound packets use the inverted transform, to restore the original address. T(I,G,k) Interior --------------> Exterior Address <-------------- Address ________ T(I,G,k) 2.2.1. Prefix Only Transformations Existing IPv6 NAT proposals specify a stateless prefix mapping for addresses [I-D.mrw-behave-nat66]. Using this transform, only the prefix information is changed, with the subnet portion of the prefix being exchanged using the Transform Tp. Daley Expires January 15, 2010 [Page 7] Internet-Draft IPv6 Function without NAT July 2009 Tp(I,G,k) I:A::C <-------------> G:A'::C I:B::D <-------------> G:B'::D I:B::E <-------------> G:B'::E _________ Tp(I,G,k) This exchange preserves information about which links and prefixes are related, which doesn't hide topology. It only hides the mapping of the internal prefix number. 2.2.2. Prefix and Suffix Transformations Where IPv6 prefixes and suffixes are transformed, and there is a stateless mapping between internal and external addresses, beyond the site prefix (G or I). The transforms Tps applies these changes. Tps(I,G,k) I:A::C <-------------> G:T::U I:B::D <-------------> G:V::W I:B::E <-------------> G:X::Y __________ Tps(I,G,k) Information about relationships between topological elements may be obscured, since suffixes are changed. The number of unique hosts communicating on the network cannot be obscured though because stateless transforms require a one-to-one mapping between interior and exterior addresses. Maintaining topology secrecy relies entirely upon keeping the mapping transform secret. Where it makes sense to standardize the base transforms, the importance of the site specific key (k) becomes critical. 2.3. Source Address Mappings and NAT Each of the above approaches may be deployed with NAT for the purpose of internal topology hiding. Alternatives which make similar mappings can achieve the same topology hiding without the impact of NAT on applications. Daley Expires January 15, 2010 [Page 8] Internet-Draft IPv6 Function without NAT July 2009 Some of these alternatives are explored below in Section 7. 3. Provider Independence in IPv6 One of the motivations for IPv6 Network Address Translation is to gain provider independence [NAT66pres]. Provider independence allows packets to transit through either one Internet Service Provider (ISP) or another. In order to achieve provider independence, addresses advertisable through multiple ISPs are required, or multiple ISP specific addresses need to be used. IAB/IESG Recommendations on IPv6 Addresses [RFC3177] provides guidelines for address allocations to sites. It identifies that sites may require multihoming mechanisms, although it doesn't identify valid multihoming schemes. 3.1. Using Provider Aggregatable Addresses for Multihoming Default IP address allocations in IPv6 and IPv4 are provider aggregatable (dependent). These addresses are advertisable through one ISP and provide routing scalability through summarization [RFC4291]. With multiple provider aggregatable connections, multihoming can be provided using either address selection on the end-host, or on a gateway (for example by using NAT). 3.1.1. Aggregatable Addresses and host selection The below shows how addressing is presented to hosts from multiple ISPs, along with any stable local prefix (The stable addressing in this case comes from Unique Local Addresses [RFC4193]). Daley Expires January 15, 2010 [Page 9] Internet-Draft IPv6 Function without NAT July 2009 +------+ +------+ | ISP1 | | ISP2 | +------+ +------+ ^ ^ --- \ / | PA1::/48\ /PA2::/48 | V/------\V | / \ | |Firewall| | |/Gateway| --- |Range of +--------+ | | Prefix : | |PA2::/48 : Range of| | +---+ Prefix | | | R | ULA::/48| | +---+ | | |PA1:C::/64 | | |ULA:C::/64 | | VPA1:C::/64 | | +--------+ | | Host: |PA1:C::M| | | |ULA:C::N| --- --- |PA2:C::R| +--------+ Multihoming using routed provider aggregatable prefixes Each of the prefixes is applied across the network and hosts receive router advertisements or DHCPv6 address allocations with the prefixes [RFC4861][RFC4862][RFC3315]. Hosts then have multiple addresses configured, and make assessments within applications to use all or one of the addresses. Assessments of whether a local or global address is used would be based on internal policy (NOTE: This makes assumptions about the status of [RFC3484]). Network connectivity through the address lasts as long as the provider aggregatable prefix is valid, although if connectivity through an ISP fails, application connectivity may break. This is because TCP binds a source IP/Dest IP/Source Port/Dest Port tuple. Unavailablity of the path between these endpoints will impact applications [RFC5533]. Applications able to withstand individual connection failures will be able to survive path failures. Otherwise application sockets or APIs may present error conditions [RFC2553]. Daley Expires January 15, 2010 [Page 10] Internet-Draft IPv6 Function without NAT July 2009 3.1.2. Provider Aggregatable Addresses and gateway selection Where a gateway exists on the path to the Internet, choice of ISP paths can be made by that gateway, as shown below. Internally the network operates with a local address plan, and the gateway substitutes or translates packet headers in order to load balance or provide some robustness in accordance with site policy. +------+ +------+ | ISP1 | | ISP2 | +------+ +------+ ^ ^ --- \ / | Range of PA1::/48\ /PA2::/48 | Prefix V/------\V | PA2::/48 / \ --- |Firewall| Translate/Present PA1,PA2 |/Gateway| --- +--------+ | : | : | Range of +---+ | Prefix | R | | ULA::/48 +---+ | | | |ULA:C::/64 | V | +--------+ | Host: |ULA:C::N| | | | --- +--------+ This scenario has the same session survivability challenges illustrated by the host selected provider aggregatable addressing. This scenario has the additional issue that that if address translation occurs without explicit involvement of the host, failures of one routing path are not readily identifiable to the host. Even when the gateway fails over to another ISP's addresses, existing sessions will fail, and new sessions succeed. even though the local addressing plan has not changed. 3.1.3. Limits of Provider Aggregatable Addressing Where Provider Aggregatable addresses are used for multihoming, control over inbound connection requests is diminished. Content providers typically provide information about services through domain Daley Expires January 15, 2010 [Page 11] Internet-Draft IPv6 Function without NAT July 2009 name mechanisms [RFC1035][RFC3596]. A lookup of name to IP address mapping occurs, and the client selects one of the available addresses for the service. For example, if a company has the following Provider Aggregatable prefixes from different ISPs, it may provision two IP addresses [RFC3849]: 2001:DB8:0000:/48 -> 2001:DB8:0000:0003:0200:5eff:fe78:9abc 2001:DB8:ffff:/48 -> 2001:DB8:ffff:0003:0200:5eff:fe78:9abc An IPv6 (AAAA) domain name lookup for www.example.com would return both of these records either from cache or from the originating DNS server. Content providers have little control over which of these addresses are used by clients to initiate sessions. Where a client uses TCP to connect to a content service, it selects one of the server IP addresses, which with provider aggregatable addressing determines which of the ISPs will deliver the traffic. Leaving the selection of the ISP to the client is undesirable particularly if one of the service providers has capacity constraints or is more costly to utilize. An alternative solution is to use provider independent addressing. 3.2. Provider Independent Addressing and Multihoming Provider Independent (PI) address prefixes may be advertised through multiple ISPs simultaneously. PI addresses are advertised individually according to the source organization's routing policy. Announcements from two or more ISPs are typical, with BGP parameters being set to identify which path is best [RFC4271][RFC4760]. This sort of control over path selection toward a particular address ensures flexibility for content providers. Additionally, outbound sessions gain survivability from a particular ISP failure, without impacting sessions. This is due to the preservation of IP addressing at the application, that is unavailable using provider aggregatable addresses. Initially, IPv6 address allocation policy did not include Provider Independent addressing in order to reduce the number of prefixes advertised within the Internet. The desire of existing multihomed content providers to retain equivalent inbound traffic control contributed to the regional internet registries allowing allocation of IPv6 provider independent addressing for all sites which are currently multihomed [APNICv6MH]. Daley Expires January 15, 2010 [Page 12] Internet-Draft IPv6 Function without NAT July 2009 Current (2009/04) allocation policy provides provider independent addressing for IPv6 on exactly the same terms as IPv4. Please note that in the past, early adopting organizations received PI address blocks even though they were not multihomed. The current policy does not extend PI IPv6 addresses to these organizations. Please also note that policies to acquire new provider independent IPv4 addressing may change as addresses become scarce. In order to provide a stable internal address plan with multiple providers, organizations will likely use a local addressing plan such as Unique Local Addressing [RFC4193]. In the typical case, the PI address plan is deployed across the internal infrastructure of the network, in parallel to any local addressing scheme. This is shown below. +------+ +------+ | ISP1 | | ISP2 | +------+ +------+ ^ ^ --- \ / | PI::/48\ /PI::/48 | V/------\V | / \ | |Firewall| | |/Gateway| --- |Range of +--------+ | | Prefix : | |PI::/48 : Range of| | +---+ Prefix | | | R | ULA::/48| | +---+ | | |PI:C::/64 | | |ULA:C::/64 | | V | | +--------+ | | Host: |PI:C::M | | | |ULA:C::N| --- --- +--------+ Multihomed provider aggregatable prefixes using routing and source address selection. Alternatively, connectivity can be delegated to the gateway, which would require a NAT or local delivery scheme to send packets within a locally addressed network. Daley Expires January 15, 2010 [Page 13] Internet-Draft IPv6 Function without NAT July 2009 4. Reduce impacts on the global routing table Provider independence of internal packet delivery can be achieved without network renumbering by making use of either Provider Independent Addressing or Network Address Translation. Network Address Translation can be used along with provider aggregatable addressing, to ease transition operations when changing ISPs. This means that the addressing which is tied to carriers can be aggregated to a single set of routes advertised in the network core. With Provider Independent addressing, addresses may be retained when a ISP change occurs. As such they are not able to be aggregated or summarized within the Internet routing table. Note that the current IPv6 allocation policy results in an IPv6 routing table with a number of routes not greater than the equivalent IPv4 routing table. While this system does not curtail growth of the internet routing table, the overall impact in the number of churned routes should still be no greater than that of IPv4, especially considering that the provider aggregatable address space will not need to be so fragmented. 5. No prefix reassignment on ISP change With provider aggregatable addresses, when an organization connects to a new ISP, they need to renumber their external addressing plan. Where no gateway NAT or local delivery scheme is in place, they will also need to renumber their internal addressing. In IP, renumbering Provider Aggregatable addresses upon ISP change is limited to those hosts that hold exterior addresses (or provide lookup records for them, as in DNS), and devices performing Network Address Translation. It is desirable that the transitions in IPv6 are able to replicate the ease of transition available within IPv4. Daley Expires January 15, 2010 [Page 14] Internet-Draft IPv6 Function without NAT July 2009 /-------------\ /-------------\ / PA1::/32 \ / PA2::/32 \ | | | | \ +------+ / \ +------+ / \-----| ISP1 |/ \| ISP2 |-----/ +------+ +------+ ^ ^ --- \ / |Range of PA1:D::/48\ /PA2:E::/48 | Prefix V/------\V |PA2:E::/48 / \ --- |Firewall| |/Gateway| --- +--------+ | : | : Range of| +---+ Prefix | | R | ULA::/48| +---+ | | | |ULA:C::/64 | V | +---------+ | |ULA:C::Q | --- +---------+ Route injection from multihomed provider aggregatatble prefixes Where similar function is to be deployed, it remains useful to determine if the capability can be acquired without damage to applications as would occur with Network Address Translation. Unlike IPv4 though, parallel network addressing infrastructure is available and supported by all hosts [RFC4294]. Internal addressing plans based on Universal Local Addressing (ULA) [RFC4193] provide stable local addresses for internal corporate resources regardless of the addresses to be used on the Internet. This means that if renumbering is deployed to end hosts either through on-link configuration [RFC4862] or DHCPv6 [RFC3315], internal connectivity will not be interrupted. Additionally, DHCPv6 prefix delegation [RFC3633] provides means for changing IPv6 Address allocations on routers in a non-disruptive fashion [RFC4193]. Daley Expires January 15, 2010 [Page 15] Internet-Draft IPv6 Function without NAT July 2009 6. Address Amplification Address amplification is used to serve multiple addresses or subnets by a smaller address allocation. This allows for preservation of address space, or making use of address space otherwise insufficient to route for all local devices. This feature of NAT has been extensively used in IPv4 because of insufficient allocation of IP addresses to homes and businesses. The IAB and IESG recommendations for IPv6 site address allocations identify three models allows for address delivery [RFC3177]: 1. typical deployments of addresses receive a /48 prefix, which supplies 65536 subnets per organization. 2. When by design only a single subnet is required, a /64 may be allocated. 3. When absolutely only one device is connecting, a /128 is allocated. Discussions within the IETF about alternative deployments allow for the specification of an intermediate allocation at /56, allowing for 256 subnets for a household use. In either this case, or case 1 above, the number of subnets which can be served by each prefix allocation may be sufficient to avoid NAT or address amplification operations. For case 2, the unforseen usage of additional devices may later become an issue requiring address amplification. In these cases, a local addressing mechanism is required to allocate addressing to edge devices. In order to achieve address amplification, state must be kept, which identifies which of the public address resources is currently in use. This precludes all stateless schemes. Consequently local tunneling, Translation extension headers, stateful NAT and NAT with address allocation channels may all be used with a smaller number of external addresses than internal addresses. 7. Alternatives to NAT for Network Topology Hiding NAT's principal problems are associated with a lack of address knowledge in applications [RFC2993][RFC5389]. Alternatives to NAT require a way of allocating external addresses to applications before Daley Expires January 15, 2010 [Page 16] Internet-Draft IPv6 Function without NAT July 2009 bindings at the application programming interface occur [RFC3775][I-D.thaler-ipv6-saf]. This allows applications to function independently of whether an address is translated or not. Once the exterior address is allocated, devices at the network perimeter need to handle delivery and transmission of packets for interior devices. The location of such devices separate to the hosts provides opportunities for topology hiding. Each of these local delivery mechanisms requires a protocol to be run between the host and network. Participants are likely to be the internet access gateway itself, and the host participating in the communications. 7.1. Local Tunnels For network topology hiding As presented at IETF 74 by Dave Thaler, local tunnelling provides equivalent support for address hiding, when deployed at the network perimeter. ^ ^ : . : . : . G:T::U V V G:V::W +-----+ +-----+ ______| GW1 |_______| GW2 |______ | | | | +-----+ +-----+ |^| \^\ |:| \.\ |:| \.\ |:| \.\ I:A::C |V| \V\ I:B::D +-----+ +-----+ | | | | | | | | +-----+ +-----+ VIP=G:T::U VIP=G:V::W Use of a local tunnel to a gateway Devices discover a gateway using local configuration mechanisms, such as DHCPv6 [RFC3315][RFC3736] or IPv6 Router Discovery [RFC4861]. A tunnel is established to the gateway, and either a stateful relationship is established, or an algorithmic mapping of addresses Daley Expires January 15, 2010 [Page 17] Internet-Draft IPv6 Function without NAT July 2009 (such as identified for stateless NATs above) is used to provide IP addressing information. The local topology hiding mechanisms are bound by the same limitations as for the equivalent mechanism under NAT. Applications have the advantage that they are able to bind virtual IP addresses associated with the allocated address. This removes the requirement for in-band address discovery mechanisms prevalent in IPv4 [RFC3849]. Hierarchical Mobile IPv6 provides an example of one such tunneling mechanism. It incorporates discovery mechanisms, a stateful binding of addresses, and an ability to update stateful bindings (as is necessary for mobile environments). Explicit tunnel systems allow for failover by directing communications through an alternate gateway. Topology hiding is preserved, and existing communications continue after tunnel connection repair. This is not a service available with stateful Network Address Translations. ^ ^ : . : . : . G:T::U V V G:V::W +-----+ +-----+ ______| GW1 |_______| GW2 |______ | | | | +-----+ +-----+ /:/ |^| /:/ |.| /:/ |.| /:/ |.| I:A::C /V/ |V| I:B::D +-----+ +-----+ | | | | | | | | +-----+ +-----+ VIP=G:T::U VIP=G:V::W Failover to alternate gateway 7.2. Translation extension headers For network Topology Hiding Tony Hain identified a mechanism for providing topology hiding through use of an IPv6 extension header that replaces a packet source address when passing through a gateway or firewall. Daley Expires January 15, 2010 [Page 18] Internet-Draft IPv6 Function without NAT July 2009 A routing header could be constructed and placed on the packet, to be examined upon passage through the gateway. This header would contain the topologically correct exterior address for the interior host. The gateway would save the interior->exterior address mapping, and pass the packet upstream toward the destination. Inbound packets would be modified with a routing or desintation header to include the path taken upon ingress through a gateway. The original header is presented to upper layer applications as the application address. Inbound A:B +--+ A:B1 D[B] +--+ A:B2 D[B,B1] +--+ A:B3 D[B,B1,B2] ----->| |---------->| |------------->| |----------------> +--+ +--+ +--+ Example inbound packet flows with multiple levels of NAT using routing header Outbound data flows use information about exterior addressing within the application, and encapsulate data with information about external addresses in a routing header, along with the internal address comprising the packet header. Outbound B:A +--+ B1:A R[B] +--+ B2:A R[B1,B] +--+ B3:A R[B2,B1,B] <-----| |<----------| |<-------------| |<---------------- +--+ +--+ +--+ Example outbound packet flows with multiple levels of NAT using routing header As packets pass through a gateway, the source address is replaced with an address from the next routing header. The contents of the routing extension header allow outbound mapping, or stored state to be created on a gateway. This allows the packet to pass to an exterior network containing only the source address information visible to the exterior domain. Outbound packets reaching a gateway without valid routing header information are rejected by ICMP message. This causes systems to learn the location and addressing requirements of the gateway, if necessary for internet access. Additionally, policy could be specified in the first instance by DHCP. Daley Expires January 15, 2010 [Page 19] Internet-Draft IPv6 Function without NAT July 2009 Mappings can be stateless, or stateful as for pool NATs. The same mapping criteria for Topology Hiding apply. 7.3. Address Allocation Channel for NAT It is possible to perform Network address translation in a way that allows applications to bind to the exterior address. This requires an address allocation channel which informs interior devices of their exterior IP address mapping. For stateless mappings, this entails informing the hosts as to their transform algorithm. Devices communicating through the gateway can then identify. For stateful mappings, a communication with the gateway would be required, although packets themselves would require no additional tunnel or header components. In both of these cases, identification of internal destinations would be valuable to ensure that application address allocation uses an appropriate address. Due to the addition of a discovery channel, this has been categorized as a local delivery mechanism, rather than a pure NAT. 8. Problems with NAT and Topology Hiding Since applications are initially unaware of their public addresses, and the boundary where topology hiding is present. Protocols expressing identity or addressing information may require testing and application awareness. Indeed, the predominant NAT and Firewall traversal mechanisms used in IPv4 perform initial NAT mapping tests using native source addresses. Additionally, network applications such as traceroute can identify those hosts which share hop-distance and delay. In some circumstances it is possible to construct the topology solely from such information. 9. Problems with Local Delivery mechanisms and Topology Hiding Local delivery mechanisms that avoid NAT have a series of issues which must be managed. * Discovery Daley Expires January 15, 2010 [Page 20] Internet-Draft IPv6 Function without NAT July 2009 * Local Transport * MTU issues * Backward compatibility. * Recursion * Source Address Selection. 9.1. Discovery Local delivery mechanisms require new and reliable mechanisms which describe operations at the network boundary. Additionally, the correct operation of existing IPv6 devices which do not support local delivery mechanisms need to be identified. 9.2. Local Transport The construction of packets to be delivered to network boundaries is required in a way which allows traversal of firewalls and reliable gateway operation. 9.3. MTU Issues The transfer of data within a local delivery encapsulation may require addition of addressing and extension headers. In some circumstances this will impact on the efficiency of transmission due to packet overheads. Additionally, while the aim of local delivery is to reduce application impacts, there is some interplay between the reduced MTU and application operations [RFC2292][RFC2460]. 9.4. Backward Compatibility The correct operation of existing IPv6 devices which do not support local delivery mechanisms need to be identified. 9.5. Recursion If multiple levels of local delivery are required, the issues of discovery, delivery, MTU and source addressing are 9.6. Source Address Selection Source address selection requires particular care in order to insulate applications from the address translation knowledge required in IPv4 NAT today. Since the application program doesn't have to Daley Expires January 15, 2010 [Page 21] Internet-Draft IPv6 Function without NAT July 2009 make explicit computations about determining addressing, the u require revisiting. system has to assist in finding which of the addresses is suitable for binding in communications. The operating system needs to be able to identify that an address on the Internet requires connectivity through a Virtual IP address held at the gateway, rather than through a locally acquired address. Existing IPv6 source address selection rules go part way toward this, by providing scope-matching constructs [RFC3484]. In order to ensure that communications use the external gateway provided address, support to distinguish between ULA addressed destinations and globally addressed destinations should be incorporated into this specification. This could be assisted by providing address selection advice in gateway discovery mechanisms which identify address prefixes which are local, and those requiring local delivery services, even where globally routable addresses are used within a local network. 10. General problems with Topology Hiding and the Internet Whether or not appplication programs understand their external address, topological and network composition information still passes network boundaries. Applications report bugs including stack traces [DRWatsonDescript], Cookies uniquely identify hosts and browsers. and operating system information can be gleaned through reviewing fragmentation and TCP windowing behaviour [ettercap]. As such neither NAT or an address preserving local delivery mechanism is a complete solution to divulgence of operating information. The author considers that due to the ongoing issues in application transparency place address preserving mechanisms in a more favourable position. 11. IANA Considerations There are no allocations made in this document. 12. Security Considerations Delivery of application services based on the IP addressing is subject to source address spoofing. Migration to Non-NAT services provides no stronger identification tie for security purposes. Daley Expires January 15, 2010 [Page 22] Internet-Draft IPv6 Function without NAT July 2009 Several schemes are described to achieve similar addressing functions. Without concrete description of the mechanisms in use, security aspects of the external interface, or the internal packet delivery cannot be completely described. 13. Acknowledgments Some of the local delivery mechanism discussions were informed by a discussion with Tony Hain at IETF 74. 14. References 14.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, February 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Daley Expires January 15, 2010 [Page 23] Internet-Draft IPv6 Function without NAT July 2009 Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Daley Expires January 15, 2010 [Page 24] Internet-Draft IPv6 Function without NAT July 2009 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [I-D.iab-ipv6-nat] Thaler, D. and L. Zhang, "IAB Thoughts on IPv6 Network Address Translation", draft-iab-ipv6-nat-00 (work in progress), March 2009. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-00 (work in progress), June 2009. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-00 (work in progress), July 2009. [I-D.mrw-behave-nat66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", draft-mrw-behave-nat66-02 (work in progress), March 2009. [NAT66pres] Wasserman, M., "NAT66: draft-mrw-behave-nat-02.txt", IETF 74 Presentation draft-mrw-behave-nat66-02, March 2009. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. Daley Expires January 15, 2010 [Page 25] Internet-Draft IPv6 Function without NAT July 2009 14.2. Informative References [I-D.thaler-ipv6-saf] Thaler, D., "Source Address Finding (SAF) for IPv6 Translation Mechanisms", draft-thaler-ipv6-saf-01 (work in progress), February 2009. [APNICv6MH] "http://www.apnic.net/policy/proposals/ prop-035-v002.html". [DRWatsonDescript] Microsoft Corporation, "Description of the Dr. Watson for Windows (Drwtsn32.exe) Tool", Microsoft Knowledge Base Q308538. [ettercap] Ornaghi, A. and M. Valleri, "Ettercap NG: http://ettercap.sourceforge.net". Author's Address Greg Daley 22 Maryston St Yarraville, Victoria 3013 Australia Phone: +61 3 9314 9797 Email: hoskuld@hotmail.com Daley Expires January 15, 2010 [Page 26]