Network Working Group Keith Moore
Internet-Draft University of Tennessee
22 February 2001
Expires: 22 August 2001
Running IPv6 over a (potentially-NATted) IPv4 Network
draft-moore-6overnat-00.txt
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Comments regarding this internet-draft should be sent to the
author, whose address appears below.
Abstract
This document describes a protocol (dubbed "6overNAT") for
deploying IP version 6 over a network which supports IP version 4 but
cannot (yet) natively support IP version 6. The target network may be
separated from the public Internet by one or more network address
translators (NATs), and the target network may itself contain NATs.
This protocol is intended to allow IPv6-capable hosts on the private
network to be assigned globally unique and routable IPv6 addresses, and
to allow those hosts to exchange traffic with IPv6 hosts on the public
IPv6 Internet (or given suitable connections, on other private IPv6
networks), without intervening translation of IPv6 addresses.
It is intended that this protocol should allow almost any
IPv4-capable enterprise network to begin using IPv6 over that network
for a small marginal cost and with little effort.
Moore Expires 22 August 2001 [Page 1]
6overNAT INTERNET-DRAFT 22 February 2001
1. Introduction
For a variety of reasons, Network Address Translators (NATs) [1]
are now widely deployed within private networks which are connected to
the public Internet. In addition, some Internet Service Providers
(ISPs) have deployed NATs between their customers and the public
Internet. Because they violate fundamental assumptions of the Internet
Protocol architecture, including the assumption that IP addresses are
globally unique, NATs are now known to cause a large number of
interoperability problems [2,3,4], especially for networked applications
employing more than two communicating parties. On the other hand, the
shortage of address space in IPv4 have made NATs a necessity for IPv4
networks. The Internet has grown so large that with reasonable
allocation schemes there are no longer enough IPv4 addresses for each
host to be assigned one uniquely. The result is that many desirable
kinds of applications are difficult to deploy using IPv4 (as those
applications require specific support at the NATs); sometimes to the
point of making deployment infeasible.
IP version 6 [5] was designed to alleviate the address space
shortage by providing a much larger address space; thus, IPv6 provides a
potential solution to this problem. However, upgrading all components
of a network to support IPv6 "natively" can be quite expensive, and the
products necessary to accomplish this are only now beginning to appear.
This document describes a protocol for tunneling IPv6 traffic over
any existing IPv4 private network (including a network containing NATs
or separated from the public Internet by a NAT), and for providing IPv6
connectivity between hosts on that private network and hosts on other
IPv6 networks, including the public IPv6 Internet. This protocol
attempts to allow incremental deployment of IPv6 and IPv6-based
applications, on a per-host and as-needed basis, at minimum expense. It
is also hoped that existing NATs can be upgraded to support 6overNAT
(just as a NAT vendor might add application-level gateway support for
any UDP-based application), thus facilitating use of IPv6 while
retaining NAT capability for IPv4. An additional goal of this protocol
is to facilitate easy transition from this state to a native IPv6
capability, so that when appropriate conditions exist this can be
accomplished with a minimum of additional effort.
1.1. Related work
The "6overNAT" mechanism defined in this memo is similar to other
mechanisms for using tunneling in the deployment of IPv6. Configured
tunnels are discussed in [7]; they allow IPv6 packets to be transmitted
between two points over an IPv4 tunnel, as long as the underlying
network supports transmission of IPv4 protocol type 41. 6to4 [7] is
similar to configured tunnels, but treats the entire public IPv4
Moore Expires 22 August 2001 [Page 2]
6overNAT INTERNET-DRAFT 22 February 2001
Internet as a large NBMA cloud; this avoids the need for an explicitly
configured tunnel if the destination IPv6 address contains the 6to4
prefix (2002::/16) and the destination can be reached over the public
IPv4 Internet. Both of these mechanisms these are generally applicable
for connecting an enterprise IPv6 network to the public IPv6 Internet or
to other IPv6 networks. By contrast, 6overNAT addresses the problem of
deploying IPv6 within an existing enterprise IPv4 network. A network
that uses 6overNAT locally can utilize any of 6to4, configured tunnels,
or native IPv6, to provide connectivity to external IPv6 networks.
6over4 [8] is another mechanism for supporting IPv6 traffic within
an IPv4 network. It can be used in either public or private IPv4
address space, but it requires that the underlying network support IP
type 41, a single addressing realm, and IPv4 multicast. The presence of
one or more NATs in the target network usually negates at least one of
these conditions. By contrast, 6overNAT is designed to be usable in any
private IPv4 network that can transmit UDP packets, regardless of
whether it uses NATs or supports IPv4 multicast. 6overNAT also attempts
to overcome some of the limitations imposed by typical NATs on the
transmission of UDP datagrams - particularly the tendency of NATs to
"time out" address bindings if they are not used within some interval.
1.2 Choice of 6overNAT vs. other IPv6 Encapsulations
As stated above, 6overNAT can potentially be used over any
enterprise IPv4 network which supports transmission of UDP datagrams,
including (it is hoped) many networks for which an upgrade to IPv6 would
otherwise be difficult or expensive. However, because the various
measures employed by 6overNAT negatively affect its efficiency and
reliability as compared to other encapsulations, 6overNAT may not be the
best choice when other options are available.
- If the underlying network can inherently support native IPv6 (which
is the case for most passive networks and networks employing only
layer 2 switching), and is not partitioned by one or more routers
that lack IPv6 support, then native IPv6 is probably a better
choice.
- If the underlying network can support IPv4 multicast, and is not
NATted, then 6over4 will be more efficient than 6overNAT.
- If the underlying network comprises only a single IPv4 addressing
realm which uses public IPv4 addresses, 6to4 is likely to be a
better choice.
- It will often be possible to run native IPv6, 6to4, or 6over4 over
at least some parts of the underlying network. In a complex
network where portions of the network were capable of supporting
Moore Expires 22 August 2001 [Page 3]
6overNAT INTERNET-DRAFT 22 February 2001
native IPv6 or IPv4 multicast and other portions were not, the
uniformity benefit of using 6overNAT everywhere would have to be
balanced against the benefit of using more efficient mechanisms
when possible.
1.3 Use of 6overNAT in public networks
As currently written, 6overNAT is designed for use within a single
enterprise network rather than on public networks. With the assistance
of an external router located somewhere in the IPv4 Internet, it may be
possible to use all or part of this protocol to establish a tunnel
between a local IPv6-capable network (whether or not using 6overNAT
internally) and one or more external IPv6 networks, over a NATted IPv4
connection. However, such use is outside the currently intended scope
of this protocol, and at best, is for further study.
1.4. Keywords
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [10].
2. Approach
The basic approach is summarized as follows: A "border box" is
installed at some point near the periphery of the private network. (See
Figure 1) The border box is a specialized IPv6 router with several
functions:
o It transmits and receives IPv6 packets using the 6overNAT
encapsulation (IPv6 over IPv4 UDP) described below, as well as
transmitting and receiving IPv6 using other encapsulations (6to4,
configured tunnels, native IPv6) when relaying packets between
6overNAT and external networks.
6overNAT thus uses IPv4 UDP as a link-layer, with the IPv4 address
and port number serving as a 6-octet link-layer address. It is not
required that the IPv4 address be public, nor that the address and
port be transmitted intact between host and border box. So long as
a 6overNAT host can send IPv4 UDP packets to the border box using a
stable and well-known IPv4 address and port, and the border box can
send IPv4 UDP packets back to that host using the source address
and port which accompanied the packet when it was received,
6overNAT will work.
o It listens for and responds to Router Solicitation and Neighbor
Solicitation requests in order to establish "half-configured"
tunnels between itself and local 6overNAT hosts. In order to work
Moore Expires 22 August 2001 [Page 4]
6overNAT INTERNET-DRAFT 22 February 2001
around any potential IPv4 address translation between the border
box and the 6overNAT host, the border box maintains a table of
IPv6-to-IPv4 address bindings.
o It acts as a gateway for Neighbor Discovery [9] requests and
responses - forwarding them intact, forwarding them with
alterations, or responding to them as necessary to create the
illusion of a multicast-capable link layer over a potentially
NATted, non-multicast capable IPv4 network.
o Using Neighbor Discovery, it arranges for the direct routing of
unicast traffic between local 6overNAT hosts in the same IPv4
addressing realm and which (from the IPv6 point-of-view) are
configured to be on the same "link". Using Redirects, it MAY also
arrange for direct routing of traffic between other pairs of
6overNAT hosts, including hosts in different IPv4 addressing
realms.
o It routes (unicast and multicast) packets between local 6overNAT
hosts and hosts on other IPv6 networks just as any other IPv6
router.
6overNAT-capable hosts attached to the private network can then
send IPv6 traffic to the border box by tunneling IPv6 over IPv4 UDP,
using the border box's IPv4 address as the destination address of the
UDP packet. Similarly, the border box will route IPv6 traffic destined
for a local host by encapsulating that traffic in an IPv4 UDP datagram
and sending it to the IPv4 address currently associated with that host.
o When routing packets between external and internal hosts, the
border box will perform the necessary encapsulation and
decapsulation for local hosts (packets tunneled over IPv4 UDP) and
remote hosts (packets transmitted using native IP, configured
tunnels, or 6to4).
Moore Expires 22 August 2001 [Page 5]
6overNAT INTERNET-DRAFT 22 February 2001
................................ ...................................
: :
public IPv6 Internet : : private IPv4 network
: :
: : +----------+
: : | 6overNAT |
+--------+ | host |
+------+ | | +-----+----+
| IPv6 |====================| border |-=-=-=-=-=-=-=-=-=-=-=-=/
| host | | box |
+------+ | |-=-=-=-=-=-=-=-=-=-=-=-=\
+--------+ +-----+----+
: : | 6overNAT |
: : | host |
: : +----------+
: :
................................ ...................................
=== IPv6 connection (may be native, configured tunnel, or 6to4)
-=- IPv6 tunneled over IPv4 UDP (6overNAT)
Figure 1. Oversimplified Illustration of the 6overNAT Mechanism
2.1 Border Box
As described above, the border box provides several functions
necessary to facilitate exchange of IPv6 datagrams between local
6overNAT hosts, and between such hosts and IPv6 hosts on other networks.
The same physical appliance may also provide other functions. For
instance:
o It may serve as a general-purpose IPv6 router, providing IPv6
connectivity to some local hosts via means other than 6overNAT, in
addition to its 6overNAT functions.
o It may implement DHCPv6 and/or Dynamic DNS.
o It may provide support for IPv4 routing (with or without NAT) and
perhaps DHCP.
o It may provide connectivity between IPv4 and IPv6 using NAT-PT [11]
or other means, so long as packets exchanged between IPv6 hosts are
passed transparently (modulo administrative controls) and without
address translation.
o It may implement a firewall which blocks traffic that is
administratively prohibited by locally-specified policy.
Moore Expires 22 August 2001 [Page 6]
6overNAT INTERNET-DRAFT 22 February 2001
A border box is an IPv6 router. This among other things, implies
that normal support for router discovery for use between ordinary hosts
and routers [9] (in addition to the specialized support detailed below),
and support for ICMPv6 [12] are REQUIRED. Depending on the use for which
it is intended, a border box may also need to support routing protocols
to exchange reachability information with other routers.
2.1.1 Operating Environment
Several different operating environments are possible for the
"border box", depending on whether one or more NATs are installed on the
target network. Regardless of the placement of the border box, it is
intended that there be a uniform host protocol for 6overNAT; in other
words, a host supporting 6overNAT should work in any of these
environments. It should also be possible to construct a border box
which is usable with several of these configurations.
2.1.1.1 Border Box Behind A NAT
This configuration assumes that the border box has no native
external IPv6 connectivity, and that its only external IPv4 connectivity
is via a NAT box. Such a border box could be said to be "behind" a NAT
box, where the NAT box partitions the private network from the public v4
Internet or from other v4 networks. This configuration is shown in
Figure 2. In this case the external IPv6 connectivity must be
accomplished by 6to4 [6] and/or an explicitly configured tunnel to an
external relay router [7].
(Note: there may be considerable overlap between the hosts on the
public IPv4 Internet and those on the public IPv6 Internet. In Figure 2
the two networks appear separately, but this is only intended to
illustrate that the relay router exchanges packets between them.)
Moore Expires 22 August 2001 [Page 7]
6overNAT INTERNET-DRAFT 22 February 2001
.................. ................... ...............................
: : : :
public : : public : : private
IPv6 Internet : : IPv4 Internet : : IPv4 network
: : : :
: : : :
+------+ +--------+ +-----+ +--------+ +----------+
| IPv6 |------| relay |+=+=+=+=+=+| NAT |+=+| border |-=-| 6overNAT |
| host | | router | +-----+ | box | | host |
+------+ +--------+ : : +--------+ +----------+
: : : :
.................. ................... ...............................
=== IPv6 connection
+=+ IPv6 tunneled over IPv4 protocol 41 (6to4 or configured tunnel)
-=- IPv6 tunneled over IPv4 UDP (6overNAT)
Figure 2. Border Box Inside the NAT
In order for either 6to4 or the configured tunnel to work properly,
the border box must be assigned a stable and routable IPv4 address; if
the tunnel is over the public Internet, the address must also be a
globally-unique, public (etc...) IPv4 address. The NAT separating the
border box from the external network MUST be configured in such a way
that any incoming traffic for IPv4 protocol type 41 at that address is
routed to the border box. However, it is permissible for the
destination IPv4 address of inbound "external" traffic to be translated
by the time the packet reaches the border box. If there are multiple
NATs between the border box and the external network, the same
constraint applies -- each NAT between the public Internet and the
border box will need to be configured to provide the effect of a stable
external address (at least for IPv4 protocol 41) for the border box.
By contrast, since there are no NATs in this configuration between
the border box and the hosts using 6overNAT, local hosts using IPv6 do
not consume external IPv4 addresses.
Note: Both 6to4 and configured tunnels require the use of IPv4
protocol type 41. If the NAT for a particular network (as well as any
other packet filters which might be in place) cannot be configured to
pass traffic for IPv4 protocol type 41 to the border box, the "Behind
the NAT" configuration is not applicable to that network.
Moore Expires 22 August 2001 [Page 8]
6overNAT INTERNET-DRAFT 22 February 2001
2.1.1.2 Border Box External to NATs
The border box may be located between the public IPv6 Internet (or
other IPv6 networks of interest) and the outermost NAT box, as in Figure
3. In this case the IPv4 UDP tunnel between the border box and the IPv6
hosts that it serves will be subject to address translation by one or
more NATs.
................................ ........... .......................
: : : :
public IPv6 Internet : : IPv4 : : private IPv4 network
: : network : :
: : : :
+------+ +--------+ +-----+ +----------+
| IPv6 |====================| border |-=-| NAT |-=-=-=-=| 6overNAT |
| host | | box | | box | | host |
+------+ +--------+ +-----+ +----------+
: : : :
................................ ........... .......................
=== IPv6 connection
-=- IPv6 tunneled over IPv4 UDP
Figure 3. Border Box external to the NATted network
In this configuration, connectivity between the border box and
external IPv6 networks may be accomplished by any of native IPv6,
configured tunnels, or 6to4. If either of the latter methods are used
the border box MUST have a stable, public, globally-scoped IPv4 address
assigned to it and inbound traffic destined for that address MUST be
routed to the border box.
By contrast, IPv6 traffic originating from the internal network
will be sent to the border box over IPv4 UDP. The border box MUST have
a stable IPv4 address assigned for this purpose (a private address is
acceptable, but the assignment must be stable), and the NATs and/or
routers between the originating hosts and the border box MUST be
configured so that encapsulated IPv6 traffic sent by an originating host
to the border box's IPv4 address will be routed to the border box.
In addition, any responses from the border box to such traffic MUST
be routed to the host with that IPv4 address. However it is understood
that after some interval the intervening NATs may change the binding
between a host and the IPv4 address used by that host. In addition, a
NAT may "forget" the address bindings if it crashes, is restarted, or
suffers a temporary power failure. The 6overNAT protocol attempts to
Moore Expires 22 August 2001 [Page 9]
6overNAT INTERNET-DRAFT 22 February 2001
provide stable IPv6 addressing for local hosts in spite of these
difficulties.
Note that with this configuration, locally-originated packets
arriving at the border box will have been assigned "external" IPv4
addresses by the NAT. Such addresses may well be scarce, and this might
limit the number of internal IPv6 hosts that could be supported by this
configuration. However, since there is no requirement that the source
port used by the internal host be preserved, and 6overNAT uses IPv4
address and port as the link-layer address, NAPT (network address and
port translation) MAY be used instead of ordinary NAT. This will help
conserve external IPv4 addresses.
2.1.1.3 Border Box between NATs
In a multiply-NATted network, a border box may be installed in a
location where it is separated from local hosts by one or more NATs, and
also receives its external connectivity through one or more NATs. In
such a configuration, the operational constraints of both of the above
configurations apply.
2.1.1.4 Border Box in Parallel with the NAT
A border box may be located in parallel with a NAT. Such a border
box would be a router with two interfaces - one on the outside of a NAT,
using public IPv4 and/or IPv6 address space; and the other on the inside
of the NAT, using private address space. This configuration is shown in
Figure 4. Note that while logically the NAT provides connectivity to
the IPv4 network and the border box provides connectivity to the public
IPv6 network, the IPv6 external connectivity can still be provided over
IPv4 using a configured tunnel or 6to4.
Moore Expires 22 August 2001 [Page 10]
6overNAT INTERNET-DRAFT 22 February 2001
................................ ...................................
: :
public IPv4 Internet : : private IPv4 network
+------+ +-----+
| IPv4 |---------------------| NAT |----+
| host | | box | |
+------+ +-----+ |
..............................: : | +----------+
: +---------------| 6overNAT |
............................... : +-=-=-=-=-=-=-=-| host |
: : | +----------+
+------+ +--------+ |
| IPv6 | | border | |
| host |====================| box |-=+
+------+ +--------+
: :
public IPv6 Internet : :
................................ ...................................
--- IPv4 connection
=== IPv6 connection (native, configured tunnel, or 6to4)
-=- IPv6 tunneled over IPv4 UDP (6overNAT)
Figure 4. Border Box in Parallel with a NAT
2.1.1.5 Border Box Co-Located with a NAT
For convenience and improved packaging, a border box can be co-
located with an IPv4 NAT. In this case the box functions as a NAT for
IPv4 traffic and as an IPv6 router (with necessary encapsulation) for
IPv6 traffic. Such a device will presumably use the same hardware
network interfaces for both IPv4 and IPv6 traffic.
NOTE: A (border box + NAT) combination would appear to have an
advantage over other configurations in that the border box would have
direct access to the NAT's internal-external address mapping table, so
it would not need special configuration (as in "border box behind the
NAT") nor would it require occasional NS or RS messages to keep track of
changes in the NAT's address bindings (as in "Border Box External to
NATs"). However, since the network "behind" such a border box might
itself contain NATs, NS/RS messages are still necessary even in this
configuration. Still, a border box which was co-located with a NAT
would likely be cheaper and more reliable than separate components.
Moore Expires 22 August 2001 [Page 11]
6overNAT INTERNET-DRAFT 22 February 2001
3. 6overNAT protocol
The following sections detail the protocol to be used by hosts and
routers when routing IPv6 over UDP.
3.1 Frame Format
6overNAT packets are transmitted as UDP packets [13] within IPv4
[14]. The IPv4 protocol type is 17 (11 hex) for UDP. The IPv4 header
contains the Destination and Source IPv4 addresses, which are the IPv4
addresses used on the local network to denote the endpoints of the
6overNAT tunnel. The UDP Source Port and UDP Destination Port are also
used to denote the endpoints of the 6overNAT tunnel.
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
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ |Version| IHL |Type of Service| Total Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | Time to Live | Protocol 0x11 | Header Checksum |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
H | IPv4 Destination Address |
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A | IPv4 Options ... /
D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E
R ...
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
v / ... IPv4 Opts | Padding |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U | UDP Source Port | UDP Destination Port |
D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P | Length | Checksum |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
To a host's IPv6 stack, a 6overNAT network looks like a multicast-capa-
ble network. It looks like a multicast-capable network so that router
and neighbor discovery and stateless address autoconfiguration will work
in (almost) the same way for a 6overNAT network (pseudo-)interface as
for other kinds of network interfaces.
Moore Expires 22 August 2001 [Page 12]
6overNAT INTERNET-DRAFT 22 February 2001
3.1.1 Maximum Transmission Unit
Since 6overNAT uses UDP as an underlying transport, a 6overNAT
Maximum Transfer Unit (MTU) could potentially be as large as the payload
of the largest valid UDP datagram (65527 bytes). For most link layers,
such an MTU would require fragmentation of the UDP datagram at the IPv4
layer. For the sake of efficiency, the default link MTU assumed by a
host, and the link MTU supplied by a Border Box during Router
Advertisement SHOULD normally be set to the estimated IPv4 MTU
associated with the path between the border box and the host, less the
size of the IPv4 and UDP headers used by that host. An exception would
be when the MTU thus derived were smaller than the minimum IPv6 MTU size
of 1280 bytes [5]. In such cases the link MTU SHOULD be chosen to be no
larger than the maximum payload of a UDP packet composed of the minimum
number of IPv4 fragments required to transmit a UDP packet with a
payload of 1280 bytes (in other words, minimize the maximum number of
IPv4 fragments that are required to make an MTU-sized IPv6 packet.)
When an MTU is specified by a Border Box it SHOULD assume that no
IPv4 or UDP options will be used by the host. A host which adds IPv4 or
UDP options to outgoing 6overNAT packets MAY adjust its own notion of
MTU to allow room for those options.
6overNAT implementations SHOULD NOT set the "do not fragment" (DF)
bit of the encapsulating IPv4 header, as this would thwart MTU discovery
at the IPv6 level.
3.2 Link-Layer Addressing
Discussion of 6overNAT addressing is inevitably cumbersome due to
the number of addresses involved. Not only are there separate IPv6 and
IPv4 layers, the IPv4 source and destination addresses used by tunnel
endpoints may be different at each end of the tunnel due to the presence
of NATs, and the translations between addresses across the NATs are
subject to change at the whim of an intervening NAT.
3.2.1 Initial Address Selection for Hosts
A host using 6overNAT determines its IPv6 link-local, site-local,
and global addresses using any of the mechanisms which would be used by
a normal IPv6 host. A host's addresses may be manually configured, or
configured using Stateless Address Autoconfiguration [15] (with or
without privacy extensions [16]), by DHCPv6, or by any other means
available.
When using Stateless Address Autoconfiguration with 6overNAT, the
interface identifier for an interface using 6overNAT for may be derived
exactly as it would be for an interface using native IPv6, even though
Moore Expires 22 August 2001 [Page 13]
6overNAT INTERNET-DRAFT 22 February 2001
that interface is not being used natively. This would potentially allow
a host or network to migrate from using 6overNAT to native IPv6 without
changing IPv6 addresses.
3.2.2 Derivation of (IPv4) Tunnel Endpoint Addresses
In order to send an IPv6 packet using 6overNAT it is necessary to
determine the IPv4 address and port to be used as the remote tunnel
endpoint. In effect, the address and port form a 48-bit "link-layer"
address. The rules for determining the tunnel endpoint are different for
hosts and border boxes.
3.2.2.1 Derivation of Tunnel Endpoints for Hosts
Before a host can transmit or receive IPv6 traffic using 6overNAT,
it must establish a tunnel with the border box. In order to do this an
IPv4 address and port which, when used as a destination address, will
cause the packet to be routed to the border box, must already be known
by the host, via explicit configuration or some other means. (Note that
because of NAT this destination IPv4 address and port may not be the
ones that are seen by the border box; it's merely the address and port
which happen to reach the border box from within the 6overNAT host's
addressing realm)
The rules that a host uses in determining the "link-layer" address
(i.e. the IPv4 address and port) corresponding to an IPv6 destination
address are as follows:
o For any unicast IPv6 address for which the IPv4 address and port
are known to the host via Neighbor Discovery or Redirects, the IPv4
address and port thus obtained are used.
o For any other IPv6 broadcast or multicast address, the IPv4 address
and port are those used to reach the border box. This (among other
things) ensures that Neighbor Discovery requests are sent to the
border box.
3.2.2.2 Derivation of Tunnel Endpoints for Border Boxes
A border box must maintain a table of the mappings from IPv6
addresses to IPv4 addresses and UDP port numbers at which hosts will
accept 6overNAT traffic. The border box potentially establishes such a
mapping when it receives Neighbor Solicitation or Router Solicitation
requests from that host at its own tunnel endpoint address. Any binding
established is from the IPv6 source address from the incoming request to
the source address and port obtained from the IPv4 header of the
incoming request.
Moore Expires 22 August 2001 [Page 14]
6overNAT INTERNET-DRAFT 22 February 2001
When a border box wishes to send or forward a packet to a 6overNAT
unicast address, it consults this table to find a IPv4 host and port
address from which traffic has recently been received from this host,
and (if an entry is found in the table) uses that host and port address
as the destination for the IPv4 UDP encapsulation.
If there is no entry in the border box's table for that IPv6
destination address, the address is unreachable. Lacking a real
multicast-capable link layer, the border box has no way to perform
Neighbor Discovery for the host.
General handling of packets transmitted to multicast addresses is
TBD. However, packets destined for the all-routers multicast address
are processed by the border box and not forwarded to other hosts. For a
packet destined for a solicited-node multicast address, a separate copy
of that packet is forwarded to each link-layer address which has an
associated IPv6 address that corresponds to that multicast address.
Packets for the all-hosts multicast address are processed only by the
border box, and not forwarded to other hosts.
3.3 6overNAT and Neighbor Discovery
6overNAT uses Neighbor Discovery [9] in a few ways that are perhaps
different than those intended by the designers of that protocol.
6overNAT hosts use ND not only to inform border boxes of their current
IPv4 addresses and to inform them of changes to those addresses (which
may for example occur due to expiration of translations in an
intervening NAT), but also to trick the NATs into not expiring their
address bindings. 6overNAT hosts also use ND to discover link-layer
addresses of other 6overNAT hosts in a similar manner to the way that ND
is used by ordinary v6 hosts. However, unlike the normal use of ND, ND
in the context of 6overNAT requires support from the border box.
Similarly, the border box aids in a host's use of ND for Unreachable
Address Detection.
Within the Neighbor Discovery protocol, 6overNAT composes a link-
layer address as follows: two octets of all zeros, followed by four
octets of IPv4 address (in network byte order), followed by two octets
of port number (also in network byte order). The Length field
corresponding to such addresses is set to 1 (meaning that the address is
eight octets long). The first two octets are reserved for future
extensions - (for instance, to allow border boxes to inform hosts that
native and/or 6over4 routing are available as alternatives to 6overNAT.)
3.3.1 Host support for Neighbor Discovery
A 6overNAT host uses ND on 6overNAT links just as for any other
multicast-capable link, with the following exceptions:
Moore Expires 22 August 2001 [Page 15]
6overNAT INTERNET-DRAFT 22 February 2001
o 6overNAT hosts MUST actively send a Router Solicitation message
when bringing up a 6overNAT interface, in order to establish a
tunnel to a border box. The tunnel cannot be assumed to exist until
the host has received a Router Advertisement message, and it may be
necessary to repeat Router Solicitation messages at occasional
intervals until such a response is received. It is not sufficient
for the host to merely wait on a Router Advertisement message,
because the border box does not know the host's link-layer address
(and so has no way to send the message) until it has received the
Router Solicitation message from the host.
o Once a tunnel is established, 6overNAT hosts MUST send occasional
Neighbor Solicitation requests for the IPv6 address used by the
border box. These messages are intended to maintain the address
translation in any intervening NAT boxes. The intervals between
such messages are TBD (and should probably be randomized) but are
on the order of 1-2 minutes. These messages can be omitted if the
host has both sent and received traffic from the border box within
that interval.
o 6overNAT hosts SHOULD NOT include a source link-layer address
option in an RS message transmitted to a border box, because the
address may be translated by an intervening NAT. Such options, if
included, will be ignored by a border box. Similarly, 6overNAT
hosts MUST ignore a source link-layer address option in an RA
message sent over 6overNAT and instead use the address and port
from the enclosing IPv4 header.
3.3.2 Border Box support for Neighbor Discovery
Because 6overNAT assumes that the underlying IPv4 network may
encompass multiple addressing realms and is not capable of multicast,
border boxes bear much of the burden of supporting Neighbor Discovery.
This section attempts to detail the handling of the Neighbor Discovery
protocol by the border boxes.
In its treatment of Neighbor Discovery, the border box treats requests
between 6overNAT hosts on the same 6overNAT "link" differently than
between hosts on different "links". Two 6overNAT hosts may be on the
same link if they are located within the same addressing realm (i.e.
there are no NATs between them) and if they may freely exchange UDP
packets with one another over IPv4 (e.g. there are no intervening fire-
walls which block UDP packets). Border boxes require explicit configu-
ration in order to determine whether two hosts are on the same "link",
this is done by telling the border box to associate a single "link" with
a particular IPv4 subnet or set of subnets. In the absence of such con-
figuration, the border box will assume that no two 6overNAT hosts are on
the same "link".
Moore Expires 22 August 2001 [Page 16]
6overNAT INTERNET-DRAFT 22 February 2001
3.3.2.1 Router Solicitation and Router Advertisement messages
This special processing applies only to exchange of RS/RA messages
between a border box and a 6overNAT host. In other circumstances, such
as when the border box communicates with IPv6 hosts or routers over
non-6overNAT links, the normal rules for RS/RA apply.
Because the underlying IPv4 layer is assumed to not support
multicast or broadcast, border boxes do not have a way of broadcasting
unsolicited RA messages to 6overNAT hosts. Instead, they periodically
send (via IPv4 unicast) an RA message to each 6overNAT host with which
they have an active tunnel.
Border boxes MUST ignore any source link-layer address option in a
received RS message because the message may have been transmitted
through a NAT. The link-layer address used by the border box will
always be that from the enclosing IPv4 header. Similarly, border boxes
MUST NOT set the source link-layer address option in RA messages
transmitted to 6overNAT hosts.
If the border box is configured to be aware of local IPv4
addressing realms, it SHOULD return in RA messages a list of IPv6
prefixes for which the hosts are in the same IPv4 addressing realm as
the host to which the RA message is being sent, identifying those
prefixes as "on-link". This will tell the 6overNAT host to send NS
messages to determine the IPv4 address and port of those hosts, and
allow direct routing of unicast messages between those hosts.
3.3.2.2 Neighbor Solicitation and Neighbor Advertisement messages
NS messages received by border boxes are processed as follows: If
the IPv6 source address is the unspecified address, any source link-
layer address option is removed (it shouldn't be there anyway), and the
NS message is forwarded to the destination. If the destination is a
solicited-node address, a copy of the NS request will be forwarded to
every link-layer (IPv4 host+port) address of which the border box is
aware whose IPv6 address is compatible with the solicited-node address.
This allows Duplicate Address Detection to work.
If the source address of an NS request is a valid IPv6 interface
address, the table of link-layer addresses is compared with the IPv4
source address and port number of the NS message to determine whether
the border box already knows the link-layer address corresponding to
this interface. If it does, the border box notes that the host is still
alive and using the same link-layer address; this resets the time
interval for sending an RA message to that host. If no entry for the
IPv6 address is found, the border box will establish an entry for that
IPv6 address so that any NA responses can be routed to it, and forward
Moore Expires 22 August 2001 [Page 17]
6overNAT INTERNET-DRAFT 22 February 2001
the NS packet to its destination (if possible). If an entry for that
IPv6 address is found with a different link-layer address, the NS
request is forwarded to that link-layer address to facilitate Duplicate
Address Detection by that host. In all of the above cases, any source
link-layer address option MUST be removed from the NS request before it
is forwarded, unless the border box knows that source and destination
are in the same IPv4 addressing realm.
When routing an NA messages containing the target link-layer
address option and the border box cannot determine that source and
destination are in the same IPv4 addressing realm, the border box will
fill the target link-layer address field with its own address before
forwarding.
Unsolicited NA advertisements received from 6overNAT hosts and sent
to the all-nodes multicast address will not be propagated to hosts,
though the border box will update its address table to reflect the link-
layer address of the host if it has changed.
3.3.2.3 Redirects
Border boxes MAY issue Redirects if they determine that messages
which could be routed directly using IPv4 unicast are instead being
routed through the border box. In general the border box can only issue
a Redirect if the target address and the destination address of the
redirect are in the same IPv4 addressing realm.
3.4 Multicast
The above procedures are intended to implement multicast only to
the extent needed for Neighbor Discovery to work. Implementation of
general-purpose multicast within a 6overNAT network is for further
study.
4. Configuration
In order to exchange packets using 6overNAT, hosts must know an
IPv4 address and port number which, when used as a destination for UDP
packets, will allow those packets to reach the border box. For now,
manual configuration is required. Automatic determination of the local
border box address would be useful, but is for further study. The
default UDP port for border boxes is #### (TBD IANA).
Border boxes must be configured just as any other IPv6 router. The
specific configuration which is needed for a border box to support
6overNAT includes a list of (IPv4 prefix/length, addressing realm)
pairs. The addressing realm component is just a small integer used to
distinguish one addressing realm from another; if the same number
Moore Expires 22 August 2001 [Page 18]
6overNAT INTERNET-DRAFT 22 February 2001
appears in multiple tuples, those hosts are in the same addressing
realm. This list allows the border box to determine whether two
6overNAT hosts are in the same addressing realm, by looking up each of
their prefixes (using the longest-match algorithm) and seeing if their
addressing realms are the same. In the absence of such a list, the
border box must treat each 6overNAT host as if it were on a separate
link, so all 6overNAT traffic will be routed through the border box.
When address prefixes are to be supplied in RA messages, border
boxes should also be supplied with a list of (IPv4 prefix/length, IPv6
prefix/length) pairs. This will allow the border box to assign each
host an IPv6 prefix which is based on its IPv4 prefix as seen by the
border box. This may help facilitate transition to native IPv6.
5. Transition from 6overNAT to Native IPv6
6overNAT is intended as a transition mechanism, not as a permanent
solution for IPv6 deployment. Because 6overNAT imposes some encoding
overhead, is somewhat less reliable, and also less efficient than native
IPv6 routing, increased use of IPv6 within a network will naturally
produce an incentive to switch to native IPv6. 6overNAT is designed to
allow hosts to retain their IPv6 addresses across such a transition. An
IPv6 address prefix assigned to an IPv4 subnet at the time a 6overNAT
border box is configured can be retained when that subnet switches to
native IPv6 routing.
It would be desirable for hosts to be able to automatically
determine whether to use 6overNAT, 6over4, host 6to4, or native IP, in
part so that they could be transitioned from one encapsulation method to
another without having to manually reconfigure each host. This is for
further study.
5. Security Considerations
Security considerations need further study. At first glance,
6overNAT's use of Neighbor Discovery to discover hosts and routers and
transmit reachability information seems no more dangerous than any other
use of this protocol. However, a 6overNAT network might comprise a much
greater number of hosts and cover a much larger area than a typical
multicast-capable layer 2 network, and as such, the security risks might
be greater.
6. IANA Considerations
- A UDP port for 6overNAT needs to be assigned.
Moore Expires 22 August 2001 [Page 19]
6overNAT INTERNET-DRAFT 22 February 2001
7. Author's address
Keith Moore
University of Tennessee, Knoxville
104 Ayres Hall
Knoxville TN, 37996-1301
USA
email: moore@cs.utk.edu
8. References
[1] P. Srisuresh, K. Egevang. Traditional IP Network Address
Translator (Traditional NAT). RFC 3022, January 2001.
[2] T. Hain. Architectural Implications of NAT. RFC 2993, November
2000.
[3] M. Holdrege, P. Srisuresh. Protocol Complications with the IP
Network Address Translator. RFC 3027, January 2001.
[4] K. Moore. Things That NATs Break. internet-draft <draft-moore-
what-nats-break-00.txt>, work in progress.
[5] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, December 1998.
[6] B. Carpenter, K. Moore. Connection of IPv6 Domains via IPv4
Clouds. RFC 3056, February 2001.
[7] R. Gilligan, E. Nordmark. Transition Mechanisms for IPv6 Hosts and
Routers. RFC 2893, August 2000.
[8] B. Carpenter, C. Jung. Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels. RFC 2529, March 1999.
[9] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP
Version 6 (IPv6). RFC 2461, December 1998.
[10] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[11] G. Tsirtsis, P. Srisuresh. Network Address Translation - Protocol
Translation (NAT-PT). RFC 2766, February 2000.
[12] A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification. RFC
2463, December 1998.
Moore Expires 22 August 2001 [Page 20]
6overNAT INTERNET-DRAFT 22 February 2001
[13] J. Postel. User Datagram Protocol. RFC 768, August 1980.
[14] J. Postel. Internet Protocol. RFC 791, September 1981.
[15] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration.
RFC 2462, December 1998.
[16] T. Narten, R. Draves. Privacy Extensions for Stateless Address
Autoconfiguration in IPv6. RFC 3041, January 2001.
Moore Expires 22 August 2001 [Page 21]