Internet Engineering Task Force Alain Durand INTERNET-DRAFT SUN Microsystems January 29, 2003 Expires July 30, 2003 Issues with NAT-PT DNS ALG in RFC2766 Status of this memo This memo provides information to the Internet community. It does not specify an Internet standard of any kind. This memo is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. Abstract Recent discussions on the need to translate or not between IPv4 and IPv6 have brought a better understanding on the impact of tools like NAT-PT [NAT-PT]. Several problems have been identified around the DNS ALG functionality. An alternative solution that does not require this DNS ALG for connections initiated by the IPv6 side has been proposed. This memo aims at analyzing the pros and cons of both solutions in that case. Connections initiated by the IPv4 side would always require the help of a DNS-ALG and thus are not covered by this memo. 1. Introduction: non DNS ALG solution Note: This section does not provide a complete description of a non DNS ALG solution for NAT-PT, but provide a quick overview of such a solution to understand better the discussions of the next sections. For outgoing connections, DNS-ALG is there in NAT-PT only to provide a local prefix for the address mapping. If a well known prefix were defined, there would be no need for DNS ALG. However, for incoming connection, there is no other way than relying on a DNS ALG. For outgoing connections, the consequences of this change would be that end-nodes willing to use the translator would now have the responsibility to do so, it would not happen automatically, and such IPv6-only end nodes would have to be specifically programmed to do so. The way this is envision to work is that an IPv6 application running on an IPv6 only node and willing to send a packet to an IPv4 address will simply create an IPv6 destination address made by appending the well-known prefix with the IPv4 address and send this one on the wire. For example, if the well known prefix is ::FFFE:0:0/96, then an IPv6 only application willing to send a packet to 1.2.3.4 will simply send it to the IPv6 address ::FFFE:1.2.3.4. IPv6->IPv4 translators would advertise that well-known prefix or shorter version of it, to their local routing system (IGP). Note: it is not expected that this prefix would be advertised outside of the IGPs in the Internet default free zone. Thus, it could be deployed within an enterprise or by an ISP for its residential customers. It is neither expected nor really desirable to see this prefix advertised in BGP peerings. 2. Issues around address selection in outgoing connections. RFC2766 section 4.2 says: "...the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 query to the external DNS system unchanged, as well as an A query for the same node. If an AAAA/A6 record exists for the destination, this will be returned to NAT-PT which will forward it, also unchanged, to the originating host. If there is an A record for Node-C the reply also returns to the NAT-PT. The DNS-ALG then, translates the reply adding the appropriate PREFIX and forwards it to the originating device with any IPv6 addresses that might have learned." 2.1 IPv6 node behind NAT-PT with DNS-ALG to dual stack node Let's take the case of a node X behind a NAT-PT box trying to communicate with a dual stack node Y outside of the NAT-PT domain for which both A and AAAA addresses are published in the DNS. X will issue a AAAA query for Y. The DNS contains a AAAA record for Y, this AAAA record will be returned (unchanged) to X. The DNS contains also a A record for Y, so the DNS-ALG, according to RFC2766, will create a AAAA record to map it. So X will be returned 2 AAAA records, the regular one and a translated one. Later, RFC2766 says: "NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT, and packets addressed to this PREFIX will be routed to the NAT-PT. The pre-configured PREFIX only needs to be routable within the IPv6 stub domain and as such it can be any routable prefix that the network administrator chooses." In practice, this means that PREFIX is taken out of X site /48 prefix. So when X will initiate the connection to Y, it will apply the address selection rules on the two IPv6 addresses returned by the DNS. All things being equal, address selection will do a longest prefix match, and as the translated IPv6 address of Y is in the same prefix as X, this one will have precedence over the 'regular' IPv6 address of Y. As a consequence, X will choose a translated path to Y when it could have chosen a direct native IPv6 path. One possible way to avoid this issue is to require the DNS ALG to not return the translated AAAA if a regular AAAA record actually exist. There are some performance/time-out issues associated to this. 2.2 IPv6 node behind NAT-PT without DNS-ALG to dual stack node Without DNS-ALG, node X will only receive the normal AAAA record for Y and use IPv6 for its connection. Thus, with the well known prefix, the problems described in section 2.1 do not exist. 2.3 Dual stack node behind NAT-PT with DNS-ALG to IPv4 node RFC2766 clearly states that it is only applicable for IPv6-only devices, but in practice, it is very difficult to know if nodes behind a NAT-PT domain will be dual-stack or not. Most probably, there will be a mixture of IPv4-only nodes, IPv6-only nodes and dual stack nodes. Let's look at the case where a dual-stack node X behind a NAT-PT + DNS-ALG box wants to communicate to an IPv4 only node Y outside of the translator. Let's also make the hypothesis that X IPv4 address is a global one. This could be the case of an enterprise network who is using IPv4 global address internally but, as those IPv4 global addresses are a scarce resource, it has decided not to allocate IPv4 global addresses to a new generation of devices. On this network, there would be a mix of non-upgraded IPv4-only hosts, dual-stack nodes and new generation IPv6-only devices. When node X wants to initiate a communication with node Y, it will typically issue DNS queries for AAAA and A records for Y. Y being IPv4 only, only an A record exists in the DNS. RFC2766 is not clear on how a DNS-ALG should treat answers to A queries made by internal nodes. As a matter of fact, one could fear that a careless DNS-ALG would also intercept them and translate them into a AAAA form. In other words, nodes asking for a A record could be returned a translated AAAA record instead. Also, when X will ask for a AAAA (X is dual stack, so it would ask for both), it would be returned a translated AAAA. So in any case, a translated AAAA record will be returned to X. Nodes are usually configure to prefer IPv6 over IPv4 when both are available, the communication between X and Y will then takes place using the translated path when the native IPv4 path would have worked. A first approach to solve this problem is to make sure in the DNS-ALG that if an A query is originating from inside, it would not be translated. But, as the text above shows, this is good but not enough. One step further would be for the DNS-ALG to recognize the fact that X is asking for both A and AAAA, then infer that it should be a query coming from a dual-stack host and not try to generate the translated AAAA answer. Another approach would be to make sure that only the IPv6-only device will use the DNS-ALG, as recommended by RFC2766. This can be tricky in practice and would require to isolate the IPv6-only device in one part of the network. 2.4 Dual stack node behind NAT-PT without DNS-ALG to IPv4 node Without DNS-ALG node X will only receive the normal A record for Y and use IPv4 for its connection. Thus, with the well known prefix, the problems described in section 2.3 do not exist. 3. Issues around DNS-sec 3.1 DNS-sec deployment with NAT-PR and DNS-ALG Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- sec. Actually there is a way to make it work, which is to mandate that each node behind the NAT-PT box use 'AD is secure' and trust the local recursive DNS resolver to verify the DNS signatures. This effectively prevents node from performing their own verification and impose a trust model that may or may not be acceptable. -------------------------------------------------------------------- => DNS-sec is only deployable within a NAT-PT domain with DNS-ALG if nodes are willing to delegate signature verifications to the local recursive DNS server. This is changing the basic trust model provided by DNSsec where end-nodes can (if they want to) perform themselves the signature verifications. -------------------------------------------------------------------- 3.2 DNS-sec deployment with NAT-PT without DNS-ALG In the absence of DNS-ALG, the DNS records are not modified and nodes can, if they want, do the signature verifications themselves. 4. Scaling 4.1 Scaling NAT-PT with DNS-ALG The way to scale NAT-PT with a DNS-ALG is for the DNS-ALG to allocate different prefixes for different translators. The DNS-ALG could do that in a round-robin way, used a pre-defined list or any kind of hashing function. This would allow the DNS-ALG to monitor the traffic and perform dynamic adjustments. This can be seen as dynamic scaling. 4.2 Scaling NAT-PT without DNS-ALG Without a DNS-ALG, the routing system perform the scaling of the system. Each NAT-PT box can advertise only the subset of the IPv4 space it intend to cover. The maximum granularity one can achieve is one box per IPv4 address destination. This can be seen as static scaling. 5. Robustness 5.2 Robustness of NAT-PT with DNS-ALG The DNS-ALG needs to actively monitor the NAT-PT boxes, to detect the potential failure of one of them and remove it from the list of valid translators. In practice, this means that the prefix associated to that translator will not be used anymore by the DNS-ALG to respond to DNS queries. For this to work, the DNS-ALG must set the TTL of the DNS answer to zero and user applications are expected to respect that TTL, i.e. not cache the name to address mapping, even for a short time. With this system, new connections started after new name to address resolution request intercepted by the DNS-ALG will work, existing connections would hang and new connections that are using the obsolete mapping would fail. Note: this last point is important in this discussion. For example, web browser that have to load different URLs pointing to the 'same' place (e.g. many pictures on the same page) may be tempted to cache the name to address resolution mapping even though the TTL is set to zero. 5.3 Robustness of NAT-PT without DNS-ALG Without the DNS ALG, the routing system can also provide robustness to the system. NAT-PT boxes can be configured to announce the same prefix, the routing system could either forward the traffic to the nearest translator or perform some kind of load balancing between the various boxes. If one of them dies, it stops announcing its prefix, thus disappear automatically from the routing tables. new connections will be redirected transparently to a new translator, but existing connections would hang. Instabilities in the routing system may end up sending packets belonging to the same flow to different NAT-PT boxes. As NAT-PT is stateful, this would end-up in broken connections. However, the IGP announcing the routes to the NAT-PT boxes are usually rather stable, so this may not be as big a problem as it first seems to be. Long term connections would statistically be more affected than short term connections. 6. Security considerations Section 3. discusses the potential security impact of RFC2766 on DNSsec. 7. Authors addresses Alain Durand SUN Microsystems, Inc 901 San Antonio Road UMPK17-202 Palo Alto, CA 94303-4900 USA Mail: Alain.Durand@sun.com 8. References [NAT-PT] Tsirtsis, G., Srisuresh, P., "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000