behave Working Group C. Perkins, Ed. Internet-Draft WiChorus Inc. Intended status: Standards Track February 17, 2009 Expires: August 21, 2009 Translating IPv4 to IPv6 based on source IPv4 address draft-perkins-sourceipnat-00 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 August 21, 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Perkins, Ed. Expires August 21, 2009 [Page 1] Internet-Draft Source IP NAT for IPv6 February 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Security Considerations . . . . . . . . . . . . . . . 11 Appendix B. Using NAT for the DNS resolution . . . . . . . . . . 12 Appendix C. Dual-stack deprecated . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Perkins, Ed. Expires August 21, 2009 [Page 2] Internet-Draft Source IP NAT for IPv6 February 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 may be compared to 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. Perkins, Ed. Expires August 21, 2009 [Page 3] Internet-Draft Source IP NAT for IPv6 February 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 August 21, 2009 [Page 4] Internet-Draft Source IP NAT for IPv6 February 2009 3. Overview Suppose that an operator wishes to support a large population of IPv6-only nodes. Later, it will be explained why this is preferable compared to dual-stack approaches. 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 fooNAT) for an address allocation, fooNAT 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 fooNAT. Assuming this happens before the expiration of BIND_TIMEOUT, fooNAT "establishes" the allocation by associating the following additional information with v6dev-IPv4: Perkins, Ed. Expires August 21, 2009 [Page 5] Internet-Draft Source IP NAT for IPv6 February 2009 o the source address of the incoming packet (call it CNv4, for "correspondent node IPv4") 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, fooNAT 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 fooNAT 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 fooNAT, 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. fooNAT 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 Perkins, Ed. Expires August 21, 2009 [Page 6] Internet-Draft Source IP NAT for IPv6 February 2009 distinct flows to the same IPv6-only device. Each such flow is identified by source and destination IPv4 address and port numbers, along with possibly other information to be specified. Each new IPv4 DNS query for one of the IPv6-only nodes served by fooNAT will trigger another allocation of one of fooNAT's IPv4 addresses. It is not clear what the maximum degree of overload should be. When a new allocation (call it again v6dev-IPv4) has been made for one of fooNAT'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 is changed 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 August 21, 2009 [Page 7] Internet-Draft Source IP NAT for IPv6 February 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 August 21, 2009 [Page 8] Internet-Draft Source IP NAT for IPv6 February 2009 5. Acknowledgments Thanks to Vijay Devarapalli, who provided useful ideas to make important improvements in the proposal. Perkins, Ed. Expires August 21, 2009 [Page 9] Internet-Draft Source IP NAT for IPv6 February 2009 6. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Perkins, Ed. Expires August 21, 2009 [Page 10] Internet-Draft Source IP NAT for IPv6 February 2009 Appendix A. Security Considerations This is where the Security Considerations will go. Perkins, Ed. Expires August 21, 2009 [Page 11] Internet-Draft Source IP NAT for IPv6 February 2009 Appendix B. 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_domaim.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 August 21, 2009 [Page 12] Internet-Draft Source IP NAT for IPv6 February 2009 Appendix C. Dual-stack deprecated 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. Perkins, Ed. Expires August 21, 2009 [Page 13] Internet-Draft Source IP NAT for IPv6 February 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 August 21, 2009 [Page 14]