TOC 
Network Working GroupK. Moore
Internet-DraftNetwork Heretics
Expires: September 10, 2009March 09, 2009


IPv4/v6 NAT With Explicit Control (NAT-XC)
draft-moore-nat-xc-02

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 September 10, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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 can be used by both IPv4 clients wishing to communicate via IPv6, and IPv6 clients wishing to communicate via IPv4. NAT-XC appears to be usable in a wide variety of scenarios requiring communication across IPv4/IPv6 boundaries.



Table of Contents

1.  Introduction
2.  Functional Description
    2.1.  Terminology
    2.2.  Translator
    2.3.  Control Point
3.  Control Protocol
    3.1.  Protocol Design Goals
    3.2.  Bindings and Translation
    3.3.  Leases
    3.4.  Sending Requests
    3.5.  Security
    3.6.  Framing of requests and responses sent using TCP and TLS over TCP
    3.7.  Protocol Messages
        3.7.1.  Create Binding
        3.7.2.  Renew Lease
        3.7.3.  Delete Binding
        3.7.4.  Change Binding
        3.7.5.  Get Binding List
        3.7.6.  Binding Notification messages
        3.7.7.  Keepalives
    3.8.  Attributes
        3.8.1.  XOR-*-ADDRESS
        3.8.2.  XOR-PIGGYBACK-PACKET
        3.8.3.  REQUESTED-TTL
        3.8.4.  CREATE-BINDING-OPTIONS
        3.8.5.  CREATE-BINDING-RESPONSE-FLAGS
        3.8.6.  BINDING-ID
        3.8.7.  LEASE-ID
        3.8.8.  LEASE-TTL
        3.8.9.  DELETE-BINDING-DELAY
4.  Control Point Implementation
    4.1.  Application Control Over Bindings
    4.2.  Control Point implemented in a Network Library
    4.3.  Control Router
    4.4.  Use of ALGs - and avoiding unnecessary ALGs
5.  Inspiration and Related Work
6.  Using NAT-XC
    6.1.  Use cases
    6.2.  "How do I get my applications working across IPv4/IPv6 boundaries?"
7.  Security Considerations
8.  IANA Considerations
9.  Informative References
§  Author's Address




 TOC 

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:

This mechanism is believed to have the following benefits:



 TOC 

2.  Functional Description



 TOC 

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 is responsible for establishing and maintaining the bindings used by an application. 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.


+----------+
|  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 (Signal Path Between Client and Peer Applications). The path taken by a packet sent by the Client Application to the Peer Application is described as follows:

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.

Note: the author's intention is to rewrite this document using the concept of a "transport address" to avoid the need, in most cases, to refer to an address and port.



 TOC 

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:

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 for which it provides services to clients, a Translator has a Control Address and Port (CAP) to which Control Protocol messages may be sent. Note that a Translator may have more than one CAP. 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.



 TOC 

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 Points) from which Translator Bindings may be managed:

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.

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.



 TOC 

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.



 TOC 

3.1.  Protocol Design Goals



 TOC 

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. (Other combinations may be reserved and unavailable for either use). 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 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 (Nordmark, E., “Stateless IP/ICMP Translation Algorithm (SIIT),” February 2000.) [RFC2765], except that address mapping is as follows:
When a packet arrives at the Translator, its transport protocol, IP destination address, and transport protocol destination port are inspected.

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.



 TOC 

3.3.  Leases





 TOC 

3.4.  Sending Requests

Communications between a Control Point and a Translator are accomplished using different mechanisms depending on the nature of the request.



 TOC 

3.5.  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 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.



 TOC 

3.6.  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.



 TOC 

3.7.  Protocol Messages

The intention is to define NAT-XC control protocol as a usage of STUN (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389]. It seems appropriate to leverage STUN because there are usage scenarios in which there will be a legacy v4 NAT between the Control Point and the Translator, and STUN is designed to work around some of the payload damage that some NATs are known to cause. The NAT-XC Control Protocol therefore consists of some new STUN methods and some new attributes to be used with those methods.



 TOC 

3.7.1.  Create Binding

The CreateBindingRequest message 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.

CreateBindingRequest messages for TCP MUST be sent over the Control Channel to the CAP. The source address and port used by the Control Point 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.

CreateBindingRequest messages 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.

The following attributes apply to CreateBindingRequest messages:



The CreateBindingResponse message contains the following attributes:



 TOC 

3.7.2.  Renew Lease

The RenewLeaseRequest message is to be used to renew the lease on one or more Bindings that are already established.

Attributes included with the RenewLeaseRequest message are:

LEASE-ID. This attribute is REQUIRED.

REQUESTED-TTL. This attribute is OPTIONAL.

Attributes included with the RenewLeaseResponse message are:

LEASE-TTL. This specifies the new TTL associated with that lease ID.



 TOC 

3.7.3.  Delete Binding

The DeleteBindingRequest message is to be used to cancel a Binding that is already established. The following attributes may be used:

BINDING-ID. This attribute is REQUIRED

DELETE-BINDING-DELAY. This attribute MAY be used to specify the amount of time (in milliseconds) during which the binding will be maintained for existing connections. This is, for example, to allow for TCP FINs and FIN ACKs to continue to traverse the Translator so that both ends will be aware that the connection was cleanly closed. If the Client has round-trip time estimates available for a particular connection, that information can be used to specify an appropriate delay. This attribute is OPTIONAL. If omitted, a default value will be used. Translators SHOULD limit the amount of delay which a client can request, so that the client cannot use this mechanism to specify a longer lease than might otherwise be available.

The DeleteBindingResponse message contains the following attribute:

DELETE-BINDING-DELAY. This is the actual delay assigned by the Translator after which it will delete this binding.



 TOC 

3.7.4.  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.

Attributes applicable to a ChangeBindingRequest message are:

BINDING-ID. The ID of the existing Binding. REQUIRED.

XOR-PRIVATE-CLIENT-ADDRESS. The new Private Client Address and Port. REQUIRED.

REQUESTED-TTL. The requested TTL for the new Binding. OPTIONAL.



Attributes included in a ChangeBindingResponse message are the same as defined for a CreateBindingResponse message.



 TOC 

3.7.5.  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, though it is expected that a parameter will be LEASE-ID, and the request will list all bindings associated with that LEASE-ID.)



 TOC 

3.7.6.  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)



 TOC 

3.7.7.  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 (Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” February 2006.) [RFC4380]. 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 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)



 TOC 

3.8.  Attributes



 TOC 

3.8.1.  XOR-*-ADDRESS

The attributes XOR-PRIVATE-CLIENT-ADDRESS, XOR-PUBLIC-CLIENT-ADDRESS, XOR-LOCAL-ADDRESS, XOR-REMOTE-ADDRESS, and XOR-PEER-ADDRESS are defined as follows:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x|    Protocol   |         X-Port                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Protocol is an Internet Protocol Number as defined by the IANA Internet Protocol Numbers registry. This is the same value as used in the IPv4 "protocol" field or the IPv6 "xxx" (whatever it's called) field. Examples are TCP (6), UDP (17), and SCTP (132).

Note that not all Protocol values are useful or appropriate for bindings in a NAT. Also note that this field's definition differs from the Family field in STUN's MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes. This was done to make NAT-XC more generally applicable.

X-Port and X-Address are as defined in STUN.



 TOC 

3.8.2.  XOR-PIGGYBACK-PACKET

This attribute consists of an IP packet which is obscured in such a way as to deter overzealous legacy NATs from modifying patterns within the packet that happen to look like addresses. Details of such obscuration are TBD.



 TOC 

3.8.3.  REQUESTED-TTL

This is a single 32 bit unsigned integer in network byte order, specifying the requested TTL in seconds.



 TOC 

3.8.4.  CREATE-BINDING-OPTIONS

This attribute consists of one or more 32-bit integers in network byte order. The first integer is used to encode Boolean values as follows:

Bit Mask 0x01: DisableALG. Directs any Control Router acting as a proxy between the Control Point and a Translator to disable any ALGs that apply to the endpoint addresses associated with the Binding.

Bit Mask 0x02: DoubleNAT: In case two endpoints are clients of the same Translator, and both endpoints are connected via a translated address, setting this bit to 1 will cause the response to reflect the complete translation being done. If the bit is set to 0, the response will only reflect a single layer of translation.

Other bits of the first integer, and the contents of additional words of this attribute, are TBD. Clients implementing this version of the specification MUST set the additional bits of the first word to zero, and MUST NOT include additional words in this attribute.



 TOC 

3.8.5.  CREATE-BINDING-RESPONSE-FLAGS

Like CREATE-BINDING-OPTIONS, this consists of one or more 32-bit integers in network byte order. Bits defined so far include: LegacyNATisPresent (word 0, mask 0x01), and ALGisPresent (word 0, mask 0x02).



 TOC 

3.8.6.  BINDING-ID

This consists of a 32-bit unsigned integer in network byte order.



 TOC 

3.8.7.  LEASE-ID

This consists of a 32-bit unsigned integer in network byte order.



 TOC 

3.8.8.  LEASE-TTL

This consists of a 32-bit unsigned integer in network byte order, defining the TTL of the lease in seconds.



 TOC 

3.8.9.  DELETE-BINDING-DELAY

This consists of a 32-bit unsigned integer in network byte order, defining the time in milliseconds during which a binding is requested to be maintained after a DeleteBindingRequest, or the time in milliseconds during which the Translator agrees to maintain the binding when this attribute appears in a DeleteBindingResponse.



 TOC 

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.



 TOC 

4.1.  Application Control Over Bindings

A NAT-XC aware application may explicitly control its own bindings. This is done by generating NAT-XC protocol messages and sending them to the NAT-XC Translator. For example, an application running on an IPv4-only network (or on an IPv4-only host) may still access IPv6 via a NAT-XC Translator. To establish a TCP connection to an IPv6 host, the application would:

Similarly, to listen for inbound IPv6 connections, the application would:

While few applications are expected to need to control their own bindings, this technique does have some interesting advantages. For instance, it allows an application to communicate with IPv6 peers even if the local host or network do not support IPv6.



 TOC 

4.2.  Control Point implemented in a Network Library

One way to manage NAT-XC bindings is to provide a Library which implements the platform's usual network API. The library would issue NAT-XC requests as necessary to provide the application with the appearance of having access to both the native IPv4 and native IPv6 networks.

There are two ways to implement such a library. One is to provide a "dual stack" API which makes both IPv4 and IPv6 visible to the application as separate networks, even if the underlying host stack or network only supported one of those. With such an library, the application would be able to lookup IPv4 or IPv6 addresses in DNS, request IPv4 or IPv6 connections, etc. using normal API calls. The library would make "real" system calls and invoke the translator as necessary to provide the application with the appearance of having access to both networks.

The other way to implement such a library is to map all IPv6 traffic onto IPv4. This would be used to allow an app written to an IPv4-only programming model to exchange traffic with IPv6 peers. In this case several of the usual "tricks" would be needed to provide the application with the illusion that IPv6-only hosts had IPv4 addresses - DNS ALG to return fake IPv4 addresses for hosts with only AAAA records. An additional layer of address mapping within the library (in addition to that provided by the Translator) would be needed to make this work. All of the usual caveats associated with NAT-PT and similar schemes apply here.

A single library could implement both programming models, but would need external configuration (say via an environment variable) to let it know whether to provide a dual stack programming model or an IPv4-only programming model. The dual stack model should be the default.

It is possible that a NAT-XC aware application might be used with a NAT-XC aware library. There are two cases for this. One is when the application wishes to completely manage all of its Bindings by itself and to not have the library get in the way. It is useful if such an application has a way to "turn off" the library so that networking API calls are handled transparently. One "natural" way to do this might be for the library to recognize if the application establishes a TCP connection with the Translator's CAP. This works as long as the library's idea of the Translator's address is the same as the application's idea of the address. A less natural way would be for the application to be able to set an environment variable which could then be recognized by the library to mean "don't intercept networking system calls and let the application manage its own bindings".

The other case is when the application is willing to let the library do the work of maintaining the bindings, but it wants to have visibility into the bindings, lease times, etc. that are being maintained by the library. Such an application might also want to adjust lease times, disable ALGs, etc. For this case it is useful if the library provides additional API calls to give it that visibility. For example, on UNIX, the ioctl(), setsockopt() or getsockopt() functions might be overloaded to allow the application to find out binding information for network sockets. Overloading an existing API function would allow applications to link to that function without the potential of an unresolved symbol error. The application could determine at runtime whether the additional functionality were supported.



 TOC 

4.3.  Control Router



 TOC 

4.4.  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, an application may disable ALGs implemented downstream by issuing a Bind request with the disableALGs option set to TRUE.



 TOC 

5.  Inspiration and Related Work

Ideas for NAT-XC came from various places.



 TOC 

6.  Using NAT-XC



 TOC 

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:

NAT-XC was designed to permit cross-realm communications in all of the cases above. e.g.:



 TOC 

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, network operator, ISPs) ALL have to act to provide IPv6 access.



 TOC 

7.  Security Considerations

Security considerations are still being determined. The following issues have been identified.



 TOC 

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.



 TOC 

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 (TXT).
[RFC2765] Nordmark, E., “Stateless IP/ICMP Translation Algorithm (SIIT),” RFC 2765, February 2000 (TXT).
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, “Realm Specific IP: Protocol Specification,” RFC 3103, October 2001 (TXT).
[RFC4380] Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” RFC 4380, February 2006 (TXT).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” RFC 5389, October 2008 (TXT).


 TOC 

Author's Address

  Keith Moore
  Network Heretics
  PO Box 1934
  Knoxville, TN 37901
  US
Email:  moore@network-heretics.com