Network Working Group K. Moore Internet-Draft Network Heretics Expires: May 7, 2009 November 3, 2008 IPv4/v6 NAT With Explicit Control (NAT-XC) draft-moore-nat-xc-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 7, 2009. Moore Expires May 7, 2009 [Page 1] Internet-Draft NAT-XC November 2008 Abstract This document describes a mechanism called NAT-XC (for NAT with Explicit Control) for translating between IPv4 and IPv6. NAT-XC is distinguished from other IPv4/IPv6 translations schemes in that it separates the translation between IPv4 and IPv6 from the management of address bindings for such a translation; and is designed to allow applications to be explicitly aware of, and control, their address bindings. NAT-XC appears to be usable in a wide variety of scenarios requiring communication across IPv4/IPv6 boundaries. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Functional Description . . . . . . . . . . . . . . . . . . . . 6 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Translator . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Control Point . . . . . . . . . . . . . . . . . . . . . . 9 3. Control Protocol . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Protocol Design Goals . . . . . . . . . . . . . . . . . . 12 3.2. Bindings and Translation . . . . . . . . . . . . . . . . . 12 3.3. Sending Requests . . . . . . . . . . . . . . . . . . . . . 14 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Framing of requests and responses sent using TCP and TLS over TCP . . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Protocol Messages . . . . . . . . . . . . . . . . . . . . 16 3.6.1. Authenticate . . . . . . . . . . . . . . . . . . . . . 16 3.6.2. Get Ticket . . . . . . . . . . . . . . . . . . . . . . 17 3.6.3. Bind . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.4. Renew Binding . . . . . . . . . . . . . . . . . . . . 19 3.6.5. Change Binding . . . . . . . . . . . . . . . . . . . . 19 3.6.6. Get Binding List . . . . . . . . . . . . . . . . . . . 20 3.6.7. Binding Notification messages . . . . . . . . . . . . 20 3.6.8. Keepalives . . . . . . . . . . . . . . . . . . . . . . 20 4. Control Point Implementation . . . . . . . . . . . . . . . . . 22 4.1. Use of ALGs - and avoiding unnecessary ALGs . . . . . . . 22 5. Inspiration and Related Work . . . . . . . . . . . . . . . . . 24 6. Using NAT-XC . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. "How do I get my applications working across IPv4/IPv6 boundaries?" . . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Informative References . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Moore Expires May 7, 2009 [Page 2] Internet-Draft NAT-XC November 2008 1. Introduction This document describes a mechanism called NAT-XC (or NAT with Explicit Control) for translating between IPv4 and IPv6, with the following characteristics: o The translation is explicitly controlled (e.g. its address bindings are created, maintained, and discarded) from a remote location using a well-defined protocol, rather than having the bindings maintained at the point at which translation occurs using traffic analysis and heuristics. o Such control may be accomplished from any of several points, including from one of the endpoints participating in a conversation, or even (when necessary or desirable) by an application. o Any party wishing to conduct a conversation across address realm boundaries, may arrange for the translation without knowledge of, or cooperation by, other parties. o While the most common deployment of NAT-XC is assumed to locate the translation at the periphery of an enterprise network or within the enterprise's ISP, such translation may occur, via explicit arrangement, at any location on the network which has both public IPv4 and public IPv6 network access. o An application using the translator to accept inbound traffic from a remote address realm, is able to be informed of its endpoint addresses in that realm, as well as the endpoint addresses of its peers. This mechanism is believed to have the following benefits: o Deployability. This single mechanism is adaptable to suit a wide variety of application configurations, network constraints, and operator requirements. Because the translation can be accomplished at a wide variety of network locations, operators have a great deal of flexibility as to how they arrange for such translation. The mechanism can accommodate IPv4-only networks, IPv6-only networks, legacy hosts without IPv4 capability, applications written to a dual-stack model, and applications written to an IPv4-only model. The mechanism can also function when the client host is behind a legacy IPv4 NAT. Because NAT-XC is able to translate packets for either IPv4-only Moore Expires May 7, 2009 [Page 3] Internet-Draft NAT-XC November 2008 or IPv6-only clients, it allows either of two hosts wishing to communicate (one using IPv4, the other using IPv6) to make itself accessible to the other. NAT-XC also avoids the need to upgrade multiple components of the network before any application can communicate across the IPv4/ IPv6 boundary. Any of several mechanisms can be used to adapt an application to use a NAT-XC translator; and the NAT-XC translator itself can either be provided locally, or by the network's ISP, or outsourced to a third party. o Minimizes the need for ALGs (including DNS ALG). In many cases, NAT-XC permits applications written to a dual-stack programming model to function as if they had direct access to both native IPv4 and native IPv6 networks. Applications written to a dual-stack model are presumed to be aware of both IPv4 and IPv6, and therefore, to also be aware of details of using higher-level protocols with IPv4 and IPv6 (e.g. address literals, DNS AAAA records, FTP EPRT vs. PORT, and so forth). However, some applications, such as those written to an IPv4-only model, will not be aware of these differences, and will thus need protocol translation to be implemented ALGs in order to effectively interoperate with peers speaking only IPv6. However ALGs, when applied indiscriminately to all traffic, can interfere with the interoperation of applications that do not need ALGs. The NAT-XC architecture minimizes unnecessary use of ALGs as follows: First, by separating the management of address bindings from the address translation, it becomes possible for the address binding management to be implemented closer to the application. So a network library or network stack that supports NAT-XC can provide a means to enable or disable ALGs on a per-application basis. Second, the NAT-XC architecture allows the bindings to be managed by the application itself, pre-empting any binding management that might otherwise be provided by lower layers. This makes it possible for an application to explicitly disable ALGs that might have otherwise interfered with its interoperation. o Provides a predictable programming environment for applications. With NAT-XC it is possible for application vendors and authors to ship a single application binary that will work correctly across IPv4/IPv6 realm boundaries in a wide range of customer environments, ranging anywhere from a dual-stack host with access to both public IPv4 and public IPv6, to a IPv4-only host running on an IPv4-only network located behind a legacy NAT. Such an Moore Expires May 7, 2009 [Page 4] Internet-Draft NAT-XC November 2008 application would be able to use a NAT-XC translator provided by the customer's network if one existed, or be explicitly configured to use a remote NAT-XC translator with which the operator had arranged to use. o Separates network security policy from address translation. An application request for an address binding can be refused with an error indicating that such communication is a violation of local policy. This provides a means for applications to be aware of the difference between security policy, and the limitations imposed by a traditional NAT. Such an application can then report failures due to security policy to its operator or user (and the NAT-XC translator can also report failed requests), while continuing to work around other network limitations or problems that are not policy related. o Encourages a desirable end-state for the Internet. NAT-XC is designed to ease the transition to an Internet in which IPv6 network access is sufficient for a host in order to reach all other hosts of interest (when not prohibited by network policy). In the near term, NAT-XC allows applications to communicate across the IPv4/IPv6 boundary without requiring major changes to the hosts and networks on which they reside. In the long term, NAT-XC allows applications to operate on an IPv6-only network even if they still need to occasionally communicate with hosts using IPv4. NAT-XC thus reduces the near-term burden of transition, while still permitting cross-realm operation, and allows changes to a network's infrastructure to be decoupled from IPv6 transition and deferred until a later date. It appears that, in a future Internet where NAT-XC were widely supported by software, the greatest functionality with the least overhead would be achieved by a configuration where most applications were written to a dual-stack model, and where most enterprise networks were IPv6-only. Other configurations could be similarly functional, but have greater overhead. It is assumed that networks would eventually migrate to the configuration with lower operational cost. Moore Expires May 7, 2009 [Page 5] Internet-Draft NAT-XC November 2008 2. Functional Description 2.1. Terminology NAT-XC defines a Translator, which mediates between a Client Application and one or more other Address Realms to which the Client Application lacks direct access. The translation allows the Client Application to communicate with a Peer Application. The Translator is controlled by a Control Protocol. Control Protocol messages are exchanged between the Translator and the Control Point. The Control Point for a particular binding may be located at any one of several locations along the signal path between the Client Application and the Translator, or at the Client Application itself. (Note that the use of the term Client Application does not imply that the application has a client role in the sense of the client-server model. The Client Application may originate outbound connections or accept inbound connections, or both.) Control Protocol messages sent by a Control Point are addressed to a Control Address and Port (CAP) assigned to the Translator. Such packets are not translated, but are used to control Translator operation. Moore Expires May 7, 2009 [Page 6] Internet-Draft NAT-XC November 2008 +----------+ | Client | | Host | | +------+ | (optional) | |Client| | .......... | | App | | : legacy : | +------+ |---->[P0]---->: NAT : +----------+ :........: IPvX | src:PrCA:PrCP | dst:LTA:LTP v IPvX [P1] src:PuCA:PuCP | dst:LTA:LTP | v +--------+ | Trans- | +----------+ | lator |---->[P2]---->| Peer | +--------+ | Host | IPvY | +------+ | src:RTA:RTP | | Peer | | dst:PA:PP | | App | | | +------+ | +----------+ Figure 1: Signal Path Between Client and Peer Applications The signal path between the Client Application to Peer Application is shown in Figure 1. The path taken by a packet sent by the Client Application to the Peer Application is described as follows: o The Client Application emits packets from the Client Host with a Private Client Address (PrCA) as the IP source address and a Private Client Port (PrCP) as the TCP or UDP source port. These packets are sent to an IP destination address called the Local Translator Address (LTA) and a TCP or UDP destination port called the Local Translator Port (LTP). Note that the triple consisting of (PrCA, LTA, LTP) is different for each Peer Address and Peer Port with which the Client Application communicates. o Since the NAT-XC Protocol is designed to permit use of a legacy IPv4 NAT between the Client Host and the Translator, an IP packet sent to a Translator by a Client Host may arrive at the Translator with a different source address and port than the ones originally specified by the Client Host. These addresses are referred to as the Public Client Address (PuCA) and Public Client Port (PuCP). (The destination address and port of IP packets sent to the Moore Expires May 7, 2009 [Page 7] Internet-Draft NAT-XC November 2008 Translator from the Client Host must be the same as originated by the Client Host.) o When a packet from a Client Host is received by the Translator, it determines whether there is a Binding established for that particular PuCA and PuCP and LTA and LTP. If so, it will translate the incoming IPvX packet into an IPvY packet that is originated from a Remote Translator Address (RTA) and Remote Translator Port (RTP) and sent to a Peer Address (PA) and Peer Port (PP). The path taken by a packet sent by the Peer Application to the Client Application is similar. It originates with source address PA and source port PP, is sent to the Translator at destination address RTA and destination port RTP. The Translator then looks for a Binding associated with RTA and RTP. If it finds one, it translates the packet into one with source address LTA and source port LTP, with destination address PuCA and destination port PuCP. (In the case where the Client Application is listening for incoming traffic from Peers for which there is no prior Binding, a new LTA and LTP will be assigned for use with a new Peer, and a new Binding will be created specifically for use with that Peer.) The translated packet will then be sent to the Client Host with destination address PrCA and destination port PrCP. The description above is not intended to forbid the use of administrative controls on communication between endpoints. If so configured, the Translator may refuse to forward traffic between particular endpoint addresses and ports, even when a Binding exists. 2.2. Translator A Translator may be located at any point which has both public IPv4 and public IPv6 network access. One or more public IPv4 addresses and one or more public IPv6 addresses will be routed to the Translator. A Translator translates between IPv4 and IPv6 packets, in both directions, according to Bindings which have been established. A Binding associates the following with one another: o Transport Protocol (e.g. UDP, TCP) o Public Client Address and Port (PuCA, PuCP) o Local Translator Address and Port (LTA, LTP) Moore Expires May 7, 2009 [Page 8] Internet-Draft NAT-XC November 2008 o Remote Translator Address and Port (RTA, RTP) o Peer Address and Port (PA, PP) Note that an Address may either be an IPv4 address or an IPv6 address. The Public Client Address and the Local Translator Address associated with a Binding must be in the same address realm. Likewise, the Remote Translator Address and the Peer Address must be in the same address realm. It is generally expected that the Local Translator Address and the Remote Translator Address associated with a Binding will be in different address realms. In discussions of NAT-XC, "Client" refers to some party for whom access to a remote address realm is needed. A Translator may serve IPv4 clients (providing them with access to the public IPv6 network), IPv6 clients (providing them with access to the public IPv4 network), or both. It is possible for both ends of a conversation to be Clients of the same Translator. For each realm that it serves, a Translator has a Control Address and Port (CAP) to which Control Protocol messages may be sent. It is anticipated that a well-known address and port will be requested from IANA for use with the NAT-XC Control Protocol as the default CAP, as this will allow the use of NAT-XC without site-specific configuration. However, a Translator may accept Control Protocol messages at any address and port at which it can receive packets, and a Control Point may be explicitly configured to use a particular CAP. Unlike traditional NAT devices, the Translator does not act as the default router for any address realm. The Translator MAY appear to the network as a router in either or both of the public IPv4 and public IPv6 address realms, but packets sent to the Translator from the Client Host or a Peer Host are sent directly to an IP address assigned to the Translator. Similarly, there is no "inside" or "outside" to a NAT-XC Translator, nor even the notion of "sides" in the definition of the Translator. Client-originated traffic is distinguished from Peer-originated traffic via the destination address and port. i.e. the Translator designates certain address and port combinations to be used as the destination of Client-originated traffic. Packets arriving at these address and port combinations which was not originated by a Client will not be translated or forwarded. 2.3. Control Point A Control Point is the point from which Bindings are requested and managed. Depending on circumstances, the Control Point may exist at a variety of locations between the Client Application and the Moore Expires May 7, 2009 [Page 9] Internet-Draft NAT-XC November 2008 Translator. Bindings are created and managed via a Control Protocol. Binding requests are sent by the Control Point to a Control Address and Port (CAP) on the Translator. The following examples illustrate different locations (i.e. Control Points) from which Translator Bindings may be managed: o An Application may be explicitly coded to generate NAT-XC Control Messages, or it may be statically linked to a library which generates NAT-XC Control Messages as part of its implementation of network access. In either case the Application is the Control Point. o An Application may be bound at run time to a library which generates NAT-XC Control Messages as part of its implementation of network access, in which case the library is the Control Point. (also known as "Bump in the API" or "BitA"). o Support for NAT-XC may be included in the network stack of the host platform, in which case the network stack is the Control Point. (also known as "Bump in the Stack" or "BitS"). o A Control Router located in the signal path between the Client Host and the Translator. Unlike other kinds of Control Points, the Control Router appears to the network as a router. Such a Control Router infers bindings based on traffic analysis and heuristics, in a manner similar to legacy NAT devices. (Such a Control Router may also implement a DNS ALG or other ALGs to accommodate IPv4-only hosts or applications not written to a dual stack model. The Control Router configuration is thus considered a "last resort" mechanism, and it should be used sparingly.) (NB: I'm looking for a better name than Control Router for this.) o For legacy "server" Applications in the "client-server" sense (that is, Applications that accept inbound traffic) it is possible for a separate process to manage one or more Bindings in the Translator so that traffic sent to a particular Remote Translator Address and Port will be forwarded to a Private Client Address and Port. This allows such "server" Applications to accept traffic from other address realms. It is possible for more than one of these mechanisms to be in place. For instance, an Application which is NAT-XC aware may run on a network stack which is also NAT-XC aware, and there may also be a Control Router between that Host and the Translator. In this case the Control Point that is closest to the Client Application is the one that controls the Bindings for that Application. Moore Expires May 7, 2009 [Page 10] Internet-Draft NAT-XC November 2008 There are tradeoffs associated with different locations for Control Points. In particular, a Control Router arrangement requires explicit configuration to establish a binding that listens for traffic from a remote realm. Also, a Control Router cannot easily distinguish between traffic from dual-stack applications and IPv4- only applications, and so it does not reliably know when to intercept traffic using ALGs that compensate for such legacy applications. On the other hand, the other mechanisms all require that some change be made on each host supporting an application that wishes to communicate across realm boundaries. And a Control Router can be very useful for accommodating an occasional legacy application, host, or network appliance, as long as it is configured so as not to adversely affect other network traffic. Moore Expires May 7, 2009 [Page 11] Internet-Draft NAT-XC November 2008 3. Control Protocol This is an ROUGH sketch of what the Control Protocol for use between a Control Point and a Translator might look like. Many details have not been worked out yet. 3.1. Protocol Design Goals o Permit operation of most dual-stack applications by intercepting existing API calls. o Permit applications to explicitly control translation bindings when necessary. o Permit use of NAT-XC with unmodified dual stack or legacy IPv4- only applications using any of BitA, BitS, or a Control Router. o Defer control of NAT-XC to the most upstream Control Point in the signal path. o Allow enterprise networks to avoid per-host configuration, but allow individual host or application operators to use NAT-XC even without local network support. o Facilitate operation from hosts with IPv4 only (or IPv6 only) stacks. o Permit operation through legacy IPv4 NAT. 3.2. Bindings and Translation A Translator has one or more public IPv4 addresses routed to it, and one or more public IPv6 addresses routed to it. Each of those addresses has potentially 2**16 TCP and 2**16 UDP ports which can be used. A Translator MAY be a host which performs other functions and/or provides other services in addition to being a Translator. If so, some of the TCP and/or UDP ports may be reserved for other purposes and not be available to the Translator. Of the (transport protocol, address, port) combinations available to the Translator, the Translator will mark some of them as for use by Clients, and others for use by Peers. Any (transport protocol, address, port) combination currently used in a Binding must be marked in such a way. The designation of a (transport protocol, address, port) combination as Client or Peer may not be changed while the combination appears in any Binding. The Translator maintains a set of Bindings which it uses to translate Moore Expires May 7, 2009 [Page 12] Internet-Draft NAT-XC November 2008 packets from one realm to another. A Binding is an 9-tuple consisting of Transport Protocol (e.g. UDP or TCP), Public Client Address and Port (PuCA, PuCP), Local Translator Address and Port (LTA, LTP), Remote Translator Address and Port (RTA, RTP), and Peer Address and Port (PA, PP). The PA, PP, and LTP parameters of a Binding may be "wildcards" which can match any address or port. A Binding consisting of PA, PP, and LTP which are "wildcards" is used to permit new inbound conversations from potential Peers to a Client. Normally when such a binding exists, the Client Host will be "listening" for traffic at the PrCA and PrCP corresponding to the PuCA and PuCP associated with that binding. Other information (e.g. lease timeout, binding ID, client ID, access permissions) may also be associated with the Binding, but the details of these are implementation-specific. For any Transport Protocol, there is at most one unique, one-to-one, bidirectional mapping between a combination of client-side binding parameters (PuCA, PuCP, LTA, LTP) and a combination of peer-side binding parameters (RTA, RTP, PA, PP). The Client Address and Peer Address SHOULD be from different realms - e.g. either the Client Address IPv4 and the Peer Address is IPv6, or vice versa. The Public Client Address and the Local Translator Address MUST be from the same realm. Similarly, the Remote Translator Address and Peer Address MUST be from the same realm. NOTE: Translation between public IPv6 addresses is strongly discouraged. Use of this protocol to translate between public IPv4 and private IPv4, or between different private IPv4 realms, is for further study. Translation between IPv4 and IPv6 is generally as defined in SIIT [RFC2765], except that address mapping is as follows: When a packet arrives, its transport protocol, IP destination address, and transport protocol destination port are inspected. o If the transport protocol is not supported, an appropriate ICMP (v4 or v6) Destination Unreachable message SHOULD be generated in response. o If this (transport protocol, address, port) combination is marked for use by Clients, the Translator searches for a Binding matching the transport protocol and (PuCA = source address, PuCP = source port, LTA = IP destination address, LTP = destination port) for the incoming packet. Moore Expires May 7, 2009 [Page 13] Internet-Draft NAT-XC November 2008 o If such a Binding is found, the inbound packet is translated to a new packet with (source address = RTA, source port = RTP, destination address = PA, destination port = RTP). If no such Binding is found, an ICMP Destination Unreachable message SHOULD be generated. o If this (transport protocol, address, port) combination is marked for use by Peers, the Translator searches for a Binding matching the transport protocol and (RTA = destination address, RTP = destination port, PA = source address, PP = source port). If such a Binding is found, the inbound packet is translated to a new packet with (source address = LTA, source port = LTP, destination address = PuCA, destination port = PuCP). If no such Binding is found, the Translator searches for a Binding matching (RTA = destination address, RTP = destination port, PA = "wildcard", PP = "wildcard"). If such a Binding is found, a new Binding is created with the same PuCA, PuCP, LTA, RTA, and RTP as the one matching the inbound packet. The PA and PP of the new binding are the source address and source port, respectively, from the inbound packet. The LTP of the new binding is chosen by the translator from the set of available ports, subject to the constraint that the (transport protocol, LTA, port) are marked for Client use. Finally, the inbound packet is translated according to the newly created binding. Note that whenever a new Binding is created, a Binding Information message is sent to the Control Point. It is possible for both endpoints of a conversation to use the same Translator at the same time, and thus, for the packet to need to be translated twice. It is therefore necessary for the Translator to detect this case. It is assumed that the right thing to do here is to avoid translating the packet between IPv6 and IPv4 (and back again) and instead, just translate the addresses without changing the packet format. This case needs further study. 3.3. Sending Requests Communications between a Control Point and a Translator are accomplished using different mechanisms depending on the nature of the request. o A Control Channel may be established between a Control Point and the Translator's Control Address and Port (CAP). The Control Channel uses TLS [RFC5246] over TCP. This channel is used to Moore Expires May 7, 2009 [Page 14] Internet-Draft NAT-XC November 2008 establish credentials for the authentication of client requests sent over UDP, for Binding Information messages sent from the Translator to the Control Point, and other purposes. The Control Channel is not required to be maintained at all times, and Bindings MUST be maintained for the duration of their leases even if the Control Channel fails for some reason. o However, due to the requirement that NAT-XC work when a legacy IPv4 NAT exists between the Client Host and the Translator, Bind Request messages for UDP MUST be sent to the CAP via UDP from the PuCA and PuCP. This is because the Translator must be able to establish the Binding in terms of the PrCA and PrCP, and these are only known by sending traffic through the legacy IPv4 NAT from the same transport protocol, Client source address, and port that will be used by later traffic between the Client and the Peer. o In addition, when a Binding Request is issued for a new client- originated conversation by a Control Router, it is necessary for the new Binding to be established before the initial packet is translated. For this reason, the Control Point MAY include a "piggybacked" packet to be translated onto a Binding Request or Renew Binding Request. This facility SHOULD NOT be used by other kinds of Control Points. Discussion: There is a possibility that some kinds of middleware boxes (e.g. traffic filters) may block TCP connections unless they first see a SYN packet from the host initiating the SYN. If, say, a NAT-XC aware TCP stack were to use piggybacking to send an initial SYN packet while establishing a Binding in the Translator, and the middleware box were placed between the host and the Translator, the middleware box would not see a SYN packet, and might disrupt subsequent traffic from the host. 3.4. Security As details have obviously not been worked out, the main purpose of this section is to explicitly acknowledge the necessity of designing security into this protocol from day one. There are many cases (perhaps all of them) where communications between a Control Point and a Translator will need to be authenticated, and perhaps encrypted. At the moment, it is naively assumed that TLS can be profiled to provide adequate Translator-to- Control Point authentication and encryption for the Control Channel. Authentication by the Control Point to the Translator, when needed, can be accomplished either using TLS client certificates or a username/password like mechanism similar to that used with TLS by several application protocols (e.g. POP, IMAP). However, there is a Moore Expires May 7, 2009 [Page 15] Internet-Draft NAT-XC November 2008 conflict between the goal of providing zero configuration for Control Points and providing the authentication needed to avoid man-in-the- middle attacks over TLS. For other communications between the Control Point and the Translator, it is (again, naively) assumed that a symmetric encryption key obtained via the Control Channel (and subject to renewal at intervals) can be used to both authenticate and encrypt those communications, in a manner similar to that used by Kerberos. 3.5. Framing of requests and responses sent using TCP and TLS over TCP Protocol messages sent via UDP have an obvious framing - one request or response per UDP datagram. Protocol messages sent via TCP require framing in order to separate one protocol message from another. For now it is assumed that, when sent over TCP, each request or response message can be prefixed by a 16-bit request or response length in network byte order. 3.6. Protocol Messages This is a summary of the protocol messages believed to be needed at this time. Not specified are fields common to all requests or responses, such as authentication, request/response ID, and so forth. Also not specified for now are the presentation format of these messages. As currently envisioned, there are three types of messages used in the NAT-XC control protocol: Requests, Responses, and Notifications. Requests are sent from a Control Point to a Translator and are used to request that the translator perform certain actions or provide information. Responses are sent from a Translator to a Control Point and are used to inform the Control Point about the results of a request. Notifications are sent from a Translator to a Control Point to inform the latter of significant events, such as new Bindings being established. They are not directly associated with any Request. 3.6.1. Authenticate The purpose of this request is to permit a Control Point to establish its identity to the Translator, and to permit a Control Point to establish the Translator's identity. This request is optional; however, the Translator MAY refuse to grant or renew certain Binding Requests, or refuse to translate traffic, based on its knowledge (or lack thereof) of the Control Point's identity. Authenticate Requests and Responses MUST be sent over the Control Moore Expires May 7, 2009 [Page 16] Internet-Draft NAT-XC November 2008 Channel. A zero-length password implies that the Translator should attempt to authenticate the client using information from lower layer protocols, e.g. TLS client certificates, or IPsec. authenticate_request { UTF8String control_point_identity; BinaryString control_point_password; } authenticate_response { Integer Status; } 3.6.2. Get Ticket Bind Requests for UDP ports MUST be sent over UDP to the CAP, and some other requests MAY be sent over UDP ports. A Ticket obtained via the Get Ticket function can be used to authenticate a Request sent over UDP to be authenticated. Here's how this works: First the Control Point establishes a TLS Control Channel connection to the Translator. It then authenticates itself to the Translator using the Control Channel and the Authenticate function. Then it uses the Get Ticket function to obtain a Ticket. The Ticket is then used to authenticate the request that is sent via UDP. The Ticket contains a symmetric encryption key which is used to encrypt requests and responses sent over UDP, and a timeout value which establishes the amount of time that the symmetric key can be used. Once the timeout has expired it is necessary to obtain new credentials in order to authenticate requests over UDP. Credential Requests and Responses MUST be sent over the Control Channel. get_ticket_request { (no parameters) } get_ticket_response { Integer Status; BinaryString ticket; Integer Timeout; } Moore Expires May 7, 2009 [Page 17] Internet-Draft NAT-XC November 2008 3.6.3. Bind A Bind Request requests the Translator to establish a Binding between the Client Host's Public Address and Port (PuCA, PuCP) and a Remote Address and Port available to the Translator. Bind Requests for TCP MUST be sent over the Control Channel to the CAP. The source address and port used by the Control Port to request a TCP Binding MUST be the same as the Private Client Address and Port (PrCA, PrCP) which will be used with that Binding. Bind Requests for UDP MUST be sent over UDP to the CAP. The source address and port used by the Control Port to request a UDP Binding MUST be the same as the Private Client Address and Port (PrCA, PrCP) which will be used with that Binding. A PiggyBack Packet MAY be included with a Bind Request. If the Bind Request is successful, this packet will be translated and sent by the Translator just as if it had been sent by the Client Host. The source IP address and source port of the PiggyBack Packet MUST be the same as the PrCA and PrCP, and the destination IP address and port of the PiggyBack Packet. (The Translator MAY accept the Bind Request while refusing to forward the PiggyBack packet, in which case it will return a Status of {TBD} in the Bind Response message). bind_request { Address PrCA; // Private Client Address Port PrCP; // Private Client Port Address RTA; // Remote Translator Address (*) Port RTP; // Remote Translator Port (*) Address PA; // Peer Address (**) Port PP; // Peer Port (**) Integer RequestedLeaseTTL; optional PiggyBackPacket; } (*) The RTA and/or RTP may be a "wildcard" to permit the translator to assign any available address or port to the binding. (**) The PA and PP may both be a "wildcard" to establish a binding to be used for incoming connections. Moore Expires May 7, 2009 [Page 18] Internet-Draft NAT-XC November 2008 bind_response { Integer Status; Address PrCA; Port PrCP; Boolean LegacyNATisPresent; Address LTA; Port LTP; Address RTA; Port RTP; Address PA; Port PP; String BindingID; Integer LeaseTTL; } 3.6.4. Renew Binding The Renew Binding function is to be used to renew the lease on a binding that is already established. renew_binding_request { String BindingID; } renew_binding_response { Integer Status; Integer LeaseTTL; } 3.6.5. Change Binding The Change Binding Request is to be used when, for whatever reason. the Client Host has changed its PuCA. (For instance, if its IPv4 DHCP server has changed its address.) Note that this is of limited applicability for many kinds of Control Points, because a TCP stack that has open TCP connections in terms of the host's old IP address will not change the local address associated with those connections. However this request may be useful for Control Points implemented within a host's TCP stack. Moore Expires May 7, 2009 [Page 19] Internet-Draft NAT-XC November 2008 change_binding_request { String BindingID; Address newPrCA; Port newPrCP; Integer RequestedLeaseTTL; } change binding_response { Integer Status; Address PrCA; Port PrCP; Boolean LegacyNATisPresent; Address LTA; Port LTP; Address RTA; Port RTP; Address PA; Port PP; Integer LeaseTTL; } 3.6.6. Get Binding List The purpose of this function is to allow a Control Point to request a list of all of the Bindings which it currently has established. This request may be useful, for instance, when the Control Channel has been broken, or in general, to synchronize views between the Control Point and the Translator. (not yet specified) 3.6.7. Binding Notification messages Any time a new Binding is established, or a Binding expires, or a Binding is changed, a Binding Notification message is sent to the Control Point by the Translator over the Control Channel. This message is not a response to an explicit request, but is sent asychronously. (not yet specified) 3.6.8. Keepalives When communicating using UDP via a legacy IPv4 NAT, it may be necessary to occasionally send traffic that will maintain the legacy IPv4 NAT's binding, in a manner similar to that employed by Teredo [RFC4380]. So in order to maintain the part of the communications path of a UDP conversation between the Control Point, through the Moore Expires May 7, 2009 [Page 20] Internet-Draft NAT-XC November 2008 legacy IPv4 NAT, to the Translator, it may be necessary to send UDP messages between the PuCA,PuCP and LTA,LTP (in either direction) which are NOT translated or forwarded to the Peer. Similarly it may be necessary to send UDP messages from the Translator through the legacy IPv4 NAT to the PuCA, PuCP which are discarded before they reach the Client Application. There needs to be some way to construct a UDP packet which will appear normal to the legacy NAT and be passed through it, but which the Translator can recognize as a packet that should not be forwarded. It is assumed that IP options will not work for this purpose. One way to do this might be for the Control Point and Translator to choose a random number of sufficient length to be very unlikely to appear in a conversation. Any UDP packet of exactly that length, containing exactly that random number, would be discarded. This needs further study. (not yet specified) Moore Expires May 7, 2009 [Page 21] Internet-Draft NAT-XC November 2008 4. Control Point Implementation As stated above, the Control Point may be located at any of several locations in the signal path between the Client Host and the Translator. This section discusses some details of Control Point implementation which are understood at this time. 4.1. Use of ALGs - and avoiding unnecessary ALGs It is hoped that in most cases Application Layer Gateways (ALGs) will not be needed. In particular, since NAT-XC can often provide an application with the appearance of direct access to both public IPv4 and public IPv6 networks, the application can know its public addresses (RTA, RTP) and its peer addresses (PA, PP) via the normal API calls (e.g. getlocalname, getpeername). Address referrals, IP address logging, etc., should work fine. In addition, source IP addresses may still be used for access control, but this requires that trust be extended to the Translator and to the entire communications path between the Control Point and the Translator. However, ALGs will still be needed for some applications, especially those written for an IPv4-only programming model. ALGs MAY therefore be provided at the Control Point. But since ALGs can actually interfere with the operation of applications that don't need them, it is necessary to provide means to explicitly enable and disable them. For Control Points which implement ALGs, a default setting of "ALGs disabled" is strongly encouraged. In addition, it MUST be possible for applications to disable ALGs. o For the case of apps that are explicitly aware of NAT-XC and interact directly with the Translator, ALGs should not be an issue. o For the case of Control Points implemented on the Client Host (BitA, BitS), it SHOULD be possible to explicitly configure whether any particular ALGs can be enabled. Ideally this would be done on a per-application basis. This could be done, say, by setting an environment variable when launching the application, or by marking the application in a particular way that could be recognized by the Control Point. o There is potential for an ALG implemented in a Control Router to interfere with an application. For instance, a DNS ALG implemented in a Control Router can provide incorrect and misleading results for a dual-stack app. Furthermore a Control Router cannot reliably distinguish between different applications' traffic nor determine which applications need ALGs and which do not. Moore Expires May 7, 2009 [Page 22] Internet-Draft NAT-XC November 2008 A Control Router that implements ALGs SHOULD have them disabled by default, and SHOULD be configurable to enable them on a per-host basis. For instance, it should be possible to enable ALGs for an IPv4-only host and have them be disabled for dual-stack hosts. (It is possible to imagine a small Control Router, designed for use only with a single host, with a switch to turn ALGs needed by v4-only apps either "on" or "off". That would at least allow control of ALGs on a per-host basis.) However, because per-host configuration can be wrong, and because different applications on the same host may be affected differently by ALGs, it seems necessary to provide a mechanism by which upstream Control Points can disable or bypass ALGs implemented in Control Routers on a per-application basis. Moore Expires May 7, 2009 [Page 23] Internet-Draft NAT-XC November 2008 5. Inspiration and Related Work Ideas for NAT-XC came from various places. o SOCKS [RFC1928] is a mechanism that was originally designed to permit IPv4 access over a serial line to hosts lacking a network connection. It was later adapted as a means to establish communications through a firewall. o The author designed a general purpose NAT traversal solution for the NetSolve distributed computing project, which used connection forwarding and was similar to TRT. Like NAT-XC, the NetSolve mechanism was designed to be usable with minimal changes to existing code. o RSIP [RFC3103] is a mechanism for providing access to the public IPv4 realm from within a private IPv4 realm. NAT-XC is similar, but because IPv4 and IPv6 use different packet formats with different sized addresses, because the two kinds of addresses are separate spaces which do not overlap, and because many applications nowdays are written to handle the two different kinds of addresses explicitly, many of the limitations associated with RSIP do not appear to impact NAT-XC. Moore Expires May 7, 2009 [Page 24] Internet-Draft NAT-XC November 2008 6. Using NAT-XC 6.1. Use cases NAT-XC can be used to facilitate access across IPv4/IPv6 realm boundaries in a variety of cases. Note that the inability of an application to communicate with both IPv4 and IPv6 peers can be due to any of several different factors: o The application may be written only to an IPv4 programming model, o The host may lack either an IPv4 or an IPv6 stack, o The local network may lack support for either IPv4 or IPv6, o The local network may not provide routing to both the public IPv4 and IPv6 networks, or o The local network may be behind a legacy IPv4 NAT and use private IPv4 addressing. NAT-XC was designed to permit cross-realm communications in all of the cases above. e.g.: o Public IPv4 access from an IPv6-only network. o Public IPv6 access from an IPv4-only network. (6to4 and Teredo address this problem in a different way, via tunneling rather than address/packet translation.) o Dual Stack application operating on IPv4-only host, needing access to IPv6. o Dual Stack application operating on IPv6-only host, needing access to IPv4. (assumed to be rare) o IPv4-only application talking with public IPv6 hosts. (DNS ALG and perhaps other ALGs required.) o Applications explicitly aware of NAT-XC. 6.2. "How do I get my applications working across IPv4/IPv6 boundaries?" This section is intended to illustrate the ways in which ANY of various parties can act to use NAT-XC to ease IPv4/IPv6 transition, independently of one another. This is a contrast to the traditional IPv6 transition model where multiple parties (user, server operator, Moore Expires May 7, 2009 [Page 25] Internet-Draft NAT-XC November 2008 network operator, ISPs) ALL have to act to provide IPv6 access. o If you are the developer of an application, you can: * modify your application to explicitly support NAT-XC (if provided by the customer), or * relink your application with a library that intercepts network API calls and makes use of NAT-XC (if provided by the customer), or * if your application is dynamically linked (i.e. it makes use of a separate library that is loaded at run time to implement network access), you can ship a library that is compatible with NAT-XC as a replacement for the previous one. You can even (if you wish) provide a NAT-XC Translator for use by your customers. o If you are a server operator, you can: * update your servers' operating systems to support NAT-XC, or * for dynamically linked applications, install a NAT-XC aware networked library on your servers. You have the option of providing your own NAT-XC Translator or making arrangements with a third party to provide that service. o If you are a network operator, you can * make arrangements for your network to have a NAT-XC Translator (either by installing one, or by arrangement with your ISP, or by making arrangement with a third-party Translator and tunneling Control Protocol traffic to that Translator.), and * optionally, install a Control Router o If you are an ordinary personal computer user, you can * upgrade your operating system to support NAT-XC, or * install a NAT-XC aware dynamic library, or * upgrade your software to versions that explicitly support NAT-XC, or Moore Expires May 7, 2009 [Page 26] Internet-Draft NAT-XC November 2008 * install a NAT-XC Control Router between your computer and the network, and configure it to establish connections with a third-party Translator. Moore Expires May 7, 2009 [Page 27] Internet-Draft NAT-XC November 2008 7. Security Considerations Security considerations are still being determined. The following issues have been identified. o There is a need for the Translator to be able to require authentication, and to impose access controls on Bindings, especially when the Translator is not provided by the enterprise network or that network's ISP. o There is a need to provide encryption for the Control Protocol. o NAT-XC provides the capability of individual hosts and applications to source traffic from addresses outside the enterprise network and receive traffic sent to addresses to outside the enterprise network. In some cases network operators will want to prevent, or control, such traffic - and in some cases they have a legitimate interest in doing so. This tussle needs to be addressed explicitly in the document. o More generally, NAT-XC impacts any network that analyzes or filters traffic based on IP address. Locally-provided Translators may log, analyze, or filter traffic based on local policies, and networks MAY attempt to block connections to external Translators. However the Control Channel is encrypted, and nothing prevents an application and an external Translator from agreeing to use a different port for Control Channels. Also, there is no reliable mechanism for distinguishing between Control Channel traffic and other traffic that might be sent over TLS. o Applications using IP source addresses as authentication tokens, will be extending trust to the Translator and to the entire signal path between the Application and the Translator. Especially when the Translator is located on an external network, this may introduce new opportunities for source address spoofing. Moore Expires May 7, 2009 [Page 28] Internet-Draft NAT-XC November 2008 8. IANA Considerations This document is a long way from being a formal protocol specification, much less a published one. However in the event that this protocol were ever standardized or approved on an experimental basis, IANA would be requested to assign a well-known port for use with NAT-XC, and to assign an IP address which could be used as a default address for use with NAT-XC. Moore Expires May 7, 2009 [Page 29] Internet-Draft NAT-XC November 2008 9. Informative References [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Moore Expires May 7, 2009 [Page 30] Internet-Draft NAT-XC November 2008 Author's Address Keith Moore Network Heretics 25 Market Square, Ste B Knoxville, TN 37902 US Email: moore@network-heretics.com Moore Expires May 7, 2009 [Page 31] Internet-Draft NAT-XC November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Moore Expires May 7, 2009 [Page 32]