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]