behave Working Group C. Perkins, Ed. Internet-Draft WiChorus Inc. Intended status: Standards Track October 12, 2009 Expires: April 15, 2010 Translating IPv4 to IPv6 based on source IPv4 address draft-perkins-sourceipnat-01 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 April 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. Perkins, Ed. Expires April 15, 2010 [Page 1] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 Abstract A method is proposed to enable communications between an IPv4-only node in today's Internet and an IPv6-only node, initiated by the IPv4-only node. The communication depends on allocation of a flow record and address triggered by a DNS query received for the target v6-only node. DNS query conventions can be agreed upon to provide a natural model for resolving IPv4 queries for IPv6-only nodes. The NAT mechanism proposed demultiplexes multiple sessions through the same dynamically allocated IP address, using flow records matching the source address of incoming packets. This is in contrast to the use of ports in NAT-PT boxes, which inhibits the support of incoming traffic towards a node behind the NAT-PT. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Outgoing flows, initated by an IPv6-only device. . . . . . . . 8 5. Denial of Service . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Using NAT for the DNS resolution . . . . . . . . . . 13 Appendix B. Some observations about dual-stack solutions . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Perkins, Ed. Expires April 15, 2010 [Page 2] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 1. Introduction As long as it is more difficult to deploy IPv6 nodes than IPv4 nodes in today's Internet, adoption of IPv6 is going to be slow. The use of NAT in today's Internet has created certain expectations and operational conveniences, but at the cost of some important features. In particular, communications are often not really bidirectional since the device whose IP address is to be translated typically has to initiate the communication. In order to encourage the adoption of IPv6, it is likely to be important to enable IPv6-only nodes to provide services to the existing IPv4-dominant Internet. Otherwise, if services can be provided for today's Internet only by assigning IPv4 addresses to the service-providing nodes, there is decreased economic incentive for moving to IPv6. The approach proposed in this document should be considered a specialized form of flow management, where flows are identified by source and destination IP addresses (usually also including additional information including ports). The NAT box manages the flows, allocating and deallocating resources, and managing the traffic (albeit intrusively) according to the mutual needs of the source and destination networks. Using the techniques proposed in this specification, communication between IPv4 nodes and IPv6 nodes can be accomplished with minimal requirements on the nodes and infrastructure: o no dual stack o no restriction to port-based communications o no tunneling o no changes to IPv4 or IPv6 hosts Moreover, the approach is scalable because each IPv4 address used by for the incoming flows can be shared by many different IPv6-only devices. The degree of scalability is determined by the rate of arrival for new incoming connection requests, and to a lesser extent by the number of simultaneous connection requests initiated from any particular IPv4 host. Perkins, Ed. Expires April 15, 2010 [Page 3] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Perkins, Ed. Expires April 15, 2010 [Page 4] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 3. Overview Suppose that an operator wishes to support a large population of IPv6-only nodes. Also, suppose that the operator requires that the IPv6 nodes should have free access to the existing IPv4 Internet, and that customers in the existing Internet should also have free access to service-providing nodes in the IPv6-only domain, as well as to any of the other nodes in the domain for which such incoming communications would be valuable. This might, for instance, greatly simplify real-time gaming and VoIP. Here is a proposed sequence of events. Let v6dev.foo.net be the FQDN for a v6-only node in the operator's domain. When a node in the IPv4 Internet wishes to establish a communication with v6dev, it sends a IPv4 DNS query to the name server (denoted fooNS) for foo.net. Suppose that the fooNS is programmed to supply an IPv4 address for such IPv4 DNS queries, but there is no such IPv4 address record available. Then, fooNS contacts the NAT box to get the required IPv4 address; in this context, the NAT box has the function of address allocation. Then fooNS creates a DNS reply with the appropriate A record. Importantly, fooNS does NOT store this A record for v6dev. Every distinct DNS query for v6dev could conceivably get a distinct IPv4 address allocation. The cache time for the A record is set to the minimum (either 0 or 1, depending on policy). When fooNS sends the request to the NAT box (call it SIPNAT) for an address allocation, SIPNAT allocates the address (call it v6dev-IPv4) and creates a flow record with the following information: o v6dev-IPv4 o the time when v6dev-IPv4 was allocated o the IPv6 address of v6dev o which nameserver made the request It also sets the status of the address allocation as "pending", and sets a timeout (call it BIND_TIMEOUT) by which the allocation has to be "established". In due time, a packet will arrive at v6dev-IPv4, which is the address of a network interface of SIPNAT. Assuming this happens before the expiration of BIND_TIMEOUT, SIPNAT "establishes" the allocation by associating the following additional information with v6dev-IPv4: o the source address of the incoming packet (call it CNv4, for "correspondent node IPv4") Perkins, Ed. Expires April 15, 2010 [Page 5] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 o the source port of the incoming packet o the time of arrival o the updated status of "established" o a new timeout, "WAIT_TIME" Then, SIPNAT does the address translation as detailed below and delivers the IPv6 result to v6dev. The translation is performed as follows: Suppose the incoming IPv4 packet has: == , where v6dev-IPv4 is an address of SIPNAT. Then the outgoing IPv6 packet gets: == The same rules apply for ICMP, GRE, and other protocols. Ports remain unchanged. If it is desired to use another IPv6 prefix to identify CNv4 to v6dev, the rule above can be easily modified as long as v6dev is configured appropriately. Whichever prefix is used, v6dev will use it to send packets back through SIPNAT, which then performs the reverse translation for delivery to CNv4 in the IPv4 Internet. If, after the allocation is established, it happens that no packets flow between v6dev and CNv4, then v6dev-IPv4 is deallocated for the purpose of communications between v6dev and CNv4. v6dev-IPv4 may remain in use for other purposes. SIPNAT waits for WAIT_TIME to receive or send a packet on the (v6dev, CNv4) flow before deallocating the flow. Under the assumption that fooNS has not cached v6dev-IPv4 as the IPv4 address of v6dev.foo.net, there is no need to notify fooNS about the deallocation. If, in the future, the no-cache assumption is relaxed, a notification of the deallocation would be needed. When the NAT box has allocated all of its available IPv4 addresses for active or pending communications, it begins to overload the available IPv4 addresses. Each IPv4 address can be allocated for use of multiple distinct communications. The same IPv4 address can be used for numerous different IPv6-only nodes, or even for multiple distinct flows to the same IPv6-only device. Each such flow is identified by source and destination IPv4 address and port numbers, Perkins, Ed. Expires April 15, 2010 [Page 6] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 along with possibly other information to be specified. Each new IPv4 DNS query for one of the IPv6-only nodes served by SIPNAT will trigger another allocation of one of SIPNAT's IPv4 addresses. It is not clear what the maximum degree of overload should be; it will depend on the flow management performance of the IPv4 network interfaces of the NAT box. When a new allocation (call it again v6dev-IPv4) has been made for one of SIPNAT's IPv4 addresses, incoming packets have to be inspected to determine whether they contain a new IPv4 source address, not yet associated with any other flow using v6dev-IPv4. If such a new source address is detected, the new allocation is "established", the new data is recorded, and the timeout for the new flow is set to WAIT_TIME. In a nutshell, the incoming sessions are demultiplexed into the IPv6- only domain based on incoming IPv4 source address, not based on incoming source port number. Given the prevalence of NATs in today's Internet, the source port number takes on additional importance, because the same IPv4 address could actually be used by multiple source computers with their IP addresses hidden from the Internet. Because of this, the source port number should be used as an additional demultiplexing index. In this way, multiple instances of the same source IPv4 address could be used at the same NATv4 address as long as port numbers were available and different for the different instances of that IPv4 source address. Perkins, Ed. Expires April 15, 2010 [Page 7] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 4. Outgoing flows, initated by an IPv6-only device. These can be handled in any of the ways proposed, but perhaps the simple v6v4 NAT proposals are most appropriate here. Problems with v4-mapped addresses and other difficulties associated with NATs are noted in RFC 4966, but it should also be pointed out that a majority of today's Internet citizens do not seem to be overly concerned with these limitations. We should make it our first goal to make these typical users equally or more happy with IPv6, even if the NAT solution is inherently restrictive. In fact, different outgoing NAT boxes can be used for the outgoing flows, as long as the incoming flow maintains enough traffic to avoid expiration of WAIT_TIME. Perkins, Ed. Expires April 15, 2010 [Page 8] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 5. Denial of Service The v4-->v6 translation relies on the availability of IPv4 interfaces on the NAT box for which no new flow allocation is "pending". If a packet arrival at such a pending IPv4 interface were to cause that interface to immediately become unavailable for establishing v4-->v6 flows, there would be an easy opportunity for an attacker to mount a denial of service attack against the domain served by the source IP (SIPNAT) NAT function. Namely, the attacker could simply spray random IPv4 packets to all of the publicly accessible IPv4 network interfaces of the SIPNAT. In order to combat this denial of service vulnerability it is necessary to avoid the loss of the pending resource. This can be done most easily by requiring pending flows to remain pending until no packets with new source IP addresses have been received at the pending address for BINDING_WAIT time. Equivalently, this means that such a pending allocation has its BINDING_WAIT timeout restarted every time a packet arrives at the IPv4 network interface with a previously unestablished source address. A malicious attacker can still mount a denial of service attack, but it would then require a much more sustained effort. The result would be that any new pending flow allocation might collect quite a few new flow records, which would all then have to be maintained for WAIT_TIME before deallocation. But the requirement that the attacker maintain the attack for a longer time should make it easier to trace back the offending packets back to their source. Furthermore, frequently offending source IP prefixes might well be blacklisted. Packets from blacklisted prefixes could be discarded to avoid these unwanted effects. Perkins, Ed. Expires April 15, 2010 [Page 9] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 6. Security Considerations Any scheme which uses an allocation scheme for IPv4 addresses on the NAT box, such that the allocated resource even temporarily impacts new allocations, is vulnerable to a denial of service attack. In the case of SIPNAT, this DoS attack takes the form of flooding the DNS Request mechanism. Such malicious flooding could have the effect of depriving the IPv4 allocation for legitimate DNS Requests from legitimate correspondents. Allocations in the pending state are vulnerable to false establishment by malicious nodes flooding packets to all of the existing IPv4 addresses of the SIPNAT box (see Section 5). There are methods to ameliorate such attacks, such as rate limiting requrests or making restrictions on the possible source IP addresses that can satisfy the flow establishment. The technique of leaving the flow pending momentarily even after a candidate packet has arrived to establish the flow, should also greatly reduce the vulnerability to this attack. Perkins, Ed. Expires April 15, 2010 [Page 10] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 7. Acknowledgments Thanks to Vijay Devarapalli, who provided useful ideas to make important improvements in the proposal. Thanks to Mark Andrews, who offered the solution of extending the availability of "pending" flow allocations, by restarting the BIND_TIMEOUT. Perkins, Ed. Expires April 15, 2010 [Page 11] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Perkins, Ed. Expires April 15, 2010 [Page 12] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 Appendix A. Using NAT for the DNS resolution If the NAT box is used as the authoritative name server for a special subdomain of foo.net, say for example v6only_domain.foo.net, then this design can be carried out without requiring changes to the existing DNS infrastructure. It is a matter of discussion whether or not it would be desirable to recommend the isolation of such v6-only devices and their transient A records to such subdomains. Perkins, Ed. Expires April 15, 2010 [Page 13] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 Appendix B. Some observations about dual-stack solutions From the standpoint of utility for conserving IPv4 address space during the transition to IPv6, dual-stack designs do not offer the advantages that are sometimes claimed. There are three likely possibilities for a dual-stack implementation o The IPv4 address is globally unique. This is very undesirable to make as a requirement, since then we have accomplished nothing towards the goal of making available more network-layer addresses. o The IPv4 address is a private address, and there is a NAT box at the border of the dual-stack domain. In this case, we have NAT. Since IPv6-only hosts can work just fine with NATs, why require dual stack? o The IPv4 address is a private address, and the dual-stack node is required to do tunnel processing on incoming v6-addressed packets that it receives. This amounts to a substantial implementation burden and, when communications occurs over a wireless medium, even more overhead. Nevertheless, dual-stack hosts are very useful when there is a need for network nodes to offer IPv6-only applications as well as IPv4- only applications. In this scenario, the node should host a dual- stack implementation. Then, over time, as all the applications migrate to IPv6, the need for configuring the IPv4 part of the dual- stack platform will decrease until at some point the IPv4 configuration may be disregarded entirely. Perkins, Ed. Expires April 15, 2010 [Page 14] Internet-Draft Source IP NAT (SIPNAT) for IPv6 October 2009 Author's Address Charles E. Perkins WiChorus Inc. 3590 N. 1st Street, Suite 300 San Jose, CA 95134 USA Email: charliep@computer.org Perkins, Ed. Expires April 15, 2010 [Page 15]