Network Working Group K. Moore Internet-Draft Network Heretics Expires: May 1, 2009 October 28, 2008 IPv4/v6 NAT With Explicit Control (NAT-XC) draft-moore-nat-xc-00 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 1, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). All Rights Reserved. Moore Expires May 1, 2009 [Page 1] Internet-Draft NAT-XC October 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. Moore Expires May 1, 2009 [Page 2] Internet-Draft NAT-XC October 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 being maintained by the translator using observations of traffic 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 normal use case 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 1, 2009 [Page 3] Internet-Draft NAT-XC October 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 before vital applications can communicate across the IPv4/IPv6 realm 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). Since NAT-XC applications have the means to both be aware of network translation and to explicitly manage the translation, it is no longer necessary to expect the NAT to inspect and modify traffic containing endpoint IP addresses. In many cases, applications written to a dual-stack model can work through NAT-XC without modification, as the API or kernel stack can provide the application with the appearance of direct access to public IPv4 and IPv6 networks through normal API calls, even if the local network does not have such access. To accommodate applications that are written to an IPv4-only model, ALGs can be provided by the local host or the local network. This allows ALGs to be "plugged in" where needed, without requiring that they be implemented in the NAT. Since such ALGs can also be limited in scope, this also minimizes the potential for negative effect of ALGs on applications which do not need them. 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 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 Moore Expires May 1, 2009 [Page 4] Internet-Draft NAT-XC October 2008 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 can also report failed requests), while trying still 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, and for which such access is permitted by network policy. NAT-XC accomplishes this by permitting hosts on IPv6-only networks to still be able to both initiate communications to, and receive communications from, peers with only IPv4 access, and hosts on IPv4-only networks to be able to initiate communications to, and receive communications from, peers with only IPv6 access. In an Internet where NAT-XC is widely deployed, but some IPv4 nodes remain, the "lowest energy" state that is functional would appear to be a state where applications are either written to be dual stack or NAT-XC aware (depending on their requirements), and networks are IPv6 only. Other configurations are also functional, including IPv4 only networks and dual-stack networks, but are more complicated. Therefore it is assumed that networks will migrate to the lowest energy state. Moore Expires May 1, 2009 [Page 5] Internet-Draft NAT-XC October 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 1, 2009 [Page 6] Internet-Draft NAT-XC October 2008 +----------+ | Client | | Host | | +------+ | (optional) | |Client| | .......... | | App | | : legacy : | +------+ |---->[P0]---->: NAT : +----------+ :........: IPvX | src:PrCA:PrCP | dst:TLA:TLP v IPvX [P1] src:PuCA:PuCP | dst:TLA:TLP | v +--------+ | Trans- | +----------+ | lator |---->[P2]---->| Peer | +--------+ | Host | IPvY | +------+ | src:TRA:TRP | | Peer | | dst:PA:PP | | App | | | +------+ | +----------+ Figure 1 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 Translator Local Address (TLA) and a TCP or UDP destination port called the Translator Local Port (TLP). Note that the 3-tuple consisting of (PrCA, TLA, TLP) 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 1, 2009 [Page 7] Internet-Draft NAT-XC October 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 TLA and TLP. If so, it will translate the incoming IPvX packet into an IPvY packet that is originated from a Translator Remote Address (TRA) and Translator Remote Port (TRP) 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 TRA and destination port TRP. The Translator then looks for a Binding associated with TRA and TRP. If it finds one, it translates the packet into one with source address TLA and source port TLP, with destination address PuCA and destination port PuCP. The packet arrives at 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 Translator Local Address and Port (TLA, TLP) o Translator Remote Address and Port (TRA, TRP) o Peer Address and Port (PA, PP) Note that an Address may either be an IPv4 address or an IPv6 Moore Expires May 1, 2009 [Page 8] Internet-Draft NAT-XC October 2008 address. The Public Client Address and the Translator Local Address associated with a Binding must be in the same address realm. Likewise, the Translator Remote Address and the Peer Address must be in the same address realm. It is generally expected that the Translator Local Address and the Translator Remote 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 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 Moore Expires May 1, 2009 [Page 9] Internet-Draft NAT-XC October 2008 Points) from which Translator Bindings may be managed: o An Application may be explictly 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"). 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"). o A Control Box located in the signal path between the Client Host and the Translator. Unlike other kinds of Control Points, the Control Box appears to the network as a router. Such a Control Box infers bindings based on traffic analysis and heuristics, in a manner similar to legacy NAT devices. (Such a Control Box 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 Box configuration is thus considered a "last resort" mechanism, and it should be used sparingly.) (NB: I'm looking for a better name than Control Box 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 Translator Remote 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 also be a Control Box between that Host and the Translator. In this case the Control Point that is earliest in the signal path (closest to the Client Application) is the one that controls the Bindings for that Application. The Control Protocol has a mechanism to allow the earliest Control Point to notify downstream Control Points that a binding is being managed from upstream. There are tradeoffs associated with different locations for Control Points. In particular, a Control Box arrangement requires explicit Moore Expires May 1, 2009 [Page 10] Internet-Draft NAT-XC October 2008 configuration to establish a binding that listens for traffic from a remote realm. Also, a Control Box 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 Box 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 1, 2009 [Page 11] Internet-Draft NAT-XC October 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. 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 explcitly 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 Box. 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 conbination appears in any Binding. The Translator maintains a set of Bindings which it uses to translate Moore Expires May 1, 2009 [Page 12] Internet-Draft NAT-XC October 2008 packets from one realm to another. A Binding is an n-tuple consisting of the following: o Transport Protocol (e.g. UDP, TCP) o Public Client Address and Port (PuCA, PuCP) o Translator Local Address and Port (TLA, TLP) o Translator Remote Address and Port (TRA, TRP) o Peer Address and Port (PA, PP) The PA, PP, and TLP parameters of a Binding may be "wildcards" which can match any address or port. A Binding consisting of PA, PP, and TLP 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, TLA, TLP) and a combination of peer-side binding parameters (TRA, TRP, 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 Translator Local Address MUST be from the same realm. Similarly, the Translator Remote 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], 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 Moore Expires May 1, 2009 [Page 13] Internet-Draft NAT-XC October 2008 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, TLA = IP destination address, TLP = destination port) for the incoming packet. o If such a Binding is found, the inbound packet is translated to a new packet with (source address = TRA, source port = TRP, destination address = PA, destination port = TRP). 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 (TRA = destination address, TRP = 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 = TLA, source port = TLP, destination address = PuCA, destination port = PuCP). If no such Binding is found, the Translator searches for a Binding matching (TRA = destination address, TRP = destination port, PA = *, PP = *). If such a Binding is found, a new Binding is created with the same PuCA, PuCP, TLA, TRA, and TRP 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 TLP of the new binding is chosen by the translator from the list of ports available to it for Translator use, subject to the constraint that the (transport protocol, TLA, 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. Moore Expires May 1, 2009 [Page 14] Internet-Draft NAT-XC October 2008 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 [TLS] over TCP. This channel is used to 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 Box, 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 kernel 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. Moore Expires May 1, 2009 [Page 15] Internet-Draft NAT-XC October 2008 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 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. 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 knowedge (or lack thereof) of the Control Point's identity. Authenticate Requests and Responses MUST be sent over the Control Channel. Moore Expires May 1, 2009 [Page 16] Internet-Draft NAT-XC October 2008 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. Credential Request and Response Binding Requests for UDP ports MUST be sent over UDP to the CAP, and some other requests MAY be sent over UDP ports. The Credential Request message allows a Request sent over UDP to be authenticated. First the Control Point authenticates itself to the Translator using the Authenticate Message, then it issues a Credential Request. The Credential Response 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. credential_request { (no parameters) } credential_response { Integer Status; BinaryString encryption_key; Integer Timeout; } 3.6.3. Binding Request and Response A Binding 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. Binding 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 Moore Expires May 1, 2009 [Page 17] Internet-Draft NAT-XC October 2008 a TCP Binding MUST be the same as the Private Client Address and Port (PrCA, PrCP) which will be used with that Binding. Binding 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 Binding Request. If the Binding 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 binding_request { Address PrCA; // Private Client Address Port PrCP; // Private Client Port Address TRA; // Remote Translator Address (*) Port TRP; // Remote Translator Port (*) Address PA; // Peer Address (**) Port PP; // Peer Port (**) Integer RequestedLeaseTTL; optional PiggyBackPacket; } (*) The TRA and/or TRP 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. binding_response { Integer Status; Address PrCA; Port PrCP; Boolean LegacyNATisPresent; Address TLA; Port TLP; Address TRA; Port TRP; Address PA; Port PP; String BindingID; Integer LeaseTTL; } Moore Expires May 1, 2009 [Page 18] Internet-Draft NAT-XC October 2008 3.6.4. Renew Binding Request and Response The Renew Binding Request 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 Request and Response 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. change_binding_request { String BindingID; Address newPrCA; Port newPrCP; Integer RequestedLeaseTTL; } change binding_response { Integer Status; Address PrCA; Port PrCP; Boolean LegacyNATisPresent; Address TLA; Port TLP; Address TRA; Port TRP; Address PA; Port PP; Integer LeaseTTL; } Moore Expires May 1, 2009 [Page 19] Internet-Draft NAT-XC October 2008 3.6.6. Request Binding List and Response The purpose of this request 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. So in order to maintain the part of the communications path of a UDP conversation between the Control Point, through the legacy IPv4 NAT, to the Translator, it may be necessary to send UDP messages between the PuCA,PuCP and TLA,TLP (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 1, 2009 [Page 20] Internet-Draft NAT-XC October 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 illusion of direct access to both public IPv4 and public IPv6 networks, the application can know its public addresses (TRA, TRP) and its peer addresses (PA, PP) via the normal API calls (e.g. getlocalname, getpeername). Address referrals, IP address logging, etc., should work fine. Note that IP address based access control should also work, 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, the trick is to provide those ALGs for applications that need them, while not having them interfere with applications that do not need them. - For the case of apps that are explicitly aware of NAT-XC and interact directly with the Translator, ALGs should not be an issue. - 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. - There is potential for an ALG implemented in a Control Box to interfere with an application. For instance, a DNS ALG implemented in a Control Box can provide incorrect and misleading results for a dual-stack app. A Control Box that implements ALGs SHOULD have them disabled by default, and SHOULD be configurable to enable them on a fine-grained 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 Box, 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.) Moore Expires May 1, 2009 [Page 21] Internet-Draft NAT-XC October 2008 There also needs to be a mechanism by which a Control Point that exists earlier in the signal path can disable or bypass ALGs implemented by a downstream Control Box. Moore Expires May 1, 2009 [Page 22] Internet-Draft NAT-XC October 2008 5. Inspiration and Related Work Ideas for NAT-XC came from various places. o SOCKS 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 was 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 1, 2009 [Page 23] Internet-Draft NAT-XC October 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 not support both IPv4 and IPv6, o The local network may not supply routing to both the public IPv4 and IPv6 networks, or o The local network may be behind a NAT and using 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 realm boundaries using NAT-XC?" 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 1, 2009 [Page 24] Internet-Draft NAT-XC October 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 NAT-XC Translators for use by your customers. o If you are a server operator, you can: * update your servers' kernels 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 Box o If you are an ordinary personal computer user, you can * upgrade your kernel to support NAT-XC, or * install a NAT-XC aware dynamic library. Moore Expires May 1, 2009 [Page 25] Internet-Draft NAT-XC October 2008 7. Security Considerations Security considerations are still being determined. However, several major issues have already been identified. o There is a need for the Translator to be able to require authentication, especially when the Translator is not provided by the enterprise network or that network's ISP. service. 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. Moore Expires May 1, 2009 [Page 26] Internet-Draft NAT-XC October 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 standardzied 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 1, 2009 [Page 27] Internet-Draft NAT-XC October 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 1, 2009 [Page 28] Internet-Draft NAT-XC October 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 1, 2009 [Page 29] Moore Expires May 1, 2009 [Page 30]