One document matched: draft-mrw-behave-nat66-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1071 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1071.xml'>
<!ENTITY rfc1624 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1624.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc2993 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml'>
<!ENTITY rfc3587 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml'>
<!ENTITY rfc4193 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc4864 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml'>
]/>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="full3978" docName="draft-mrw-behave-nat66-01.txt">
<front>
<title abbrev="NAT66">IPv6-to-IPv6 Network Address Translation (NAT66)</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Sandstorm Enterprises</organization>
<address>
<postal>
<street>14 Summer Street</street>
<city>Malden</city> <region>MA</region>
<code>02148</code>
<country>USA</country>
</postal>
<phone>+1 781 333 3200</phone>
<email>mrw@lilacglade.org</email>
<uri>http://www.sandstorm.net</uri>
</address>
</author>
<author fullname="Fred Baker" initials="F.J."
surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<phone>+1-408-526-4257</phone>
<email>fred@cisco.com</email>
</address>
</author>
<date month="November" year="2008" />
<area>Transport</area>
<workgroup>BEHAVE WG</workgroup>
<abstract>
<t>
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Address Translation (NAT66) function that provides the address
independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while
minimizing, but not completely eliminating, the problems associated
with NAT44.
</t>
<t>
This document also describes an address mapping option for NAT66 that
offers the topology hiding benefit associated with NAT44 at the cost
of additional state in the NAT66 device.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"/>.
</t>
</section>
<section title="Introduction">
<t>
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Address Translation (NAT66) function that provides the address
independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while
minimizing, but not completely eliminating, the problems associated
with NAT44.
</t>
<t>
NAT66 does not include a port mapping function, and both of the defined
address mapping mechanisms use checksum-neutral algorithms. This
avoids the need for a NAT66 device to re-write transport layer
headers, making it feasible to deploy new or improved transport layer
protocols without upgrading NAT66 devices. Because NAT66 does not
involve re-writing transport-layer headers, NAT66 will not interfere
with encrypting the full IP payload in many cases.
</t>
<t>
The default NAT66 address mapping mechanism is purely algorithmic, so
NAT66 devices do not need to maintain per-node or per-connection
state, allowing deployment of more robust and adaptive networks than
can be deployed using NAT44. Since the default NAT66 mapping can be
performed in either direction, it does not interfere with inbound
connection establishment, thus allowing internal nodes to participate
in direct peer-to-peer applications.
</t>
<t>
This document also defines an address mapping option for NAT66 that
offers the topology hiding benefit associated with NAT44. This
mechanism involves the configuration or dynamic maintenance of some
per-node state in the NAT66 device. So, when used with this optional
address mapping mechanisms, NAT66 will have greater negative impact on
direct peer-to-peer applications, and on the robustness and
reliability of the network. These trade-offs are discussed later in
the document.
</t>
<t>
Although NAT66 compares favorably to NAT44 in several ways, it does
not eliminate all of the architectural problems associated with IPv4
NAT. <xref target="RFC2993"/>. NAT66 involves modifying IP headers in
transit, so it is not compatible with security mechanisms that involve
end-to-end encryption of the IP header or mechanisms, such as AH, that
provide integrity protection for the IP header. NAT66 may interfere
with the use of application protocols that transmit IP addresses in
the application-specific portion of the IP packet. These applications
currently require application layer gateways (ALGs) to work correctly
through NAT44 devices, and similar ALGs may be required for these
applications to work through NAT66 devices. The use of separate
internal and external address prefixes creates complexity for DNS
deployment, due the desire for internal nodes to communicate with
other internal nodes using internal addresses, while external nodes
need to obtain external addresses to communicate with the same nodes.
Typically, this results in the deployment of "split DNS", which has
it's own set of architectural implications [Ref Needed].
</t>
</section>
<section title="Motivations">
<t>
In defining the NAT66 mechanism, it is not our goal to encourage the
implementation or use of NAT66. There are significant technical
problems associated with the deployment of any type of NAT, and the
IETF does not recommend the use of NAT. We strongly encourage anyone
who is considering the implementation or deployment of NAT66 to read
RFC 4864 <xref target="RFC4864"/>, and to carefully consider the
alternatives described in that document, many of which will cause
fewer problems than NAT66.
</t>
<t>
We are documenting NAT66 because we believe that some people will
choose to implement and deploy IPv6 NAT, in spite of our
recommendation not to do so. Some enterprises may choose to deploy
IPv6 NAT to gain provider independent internal addressing or to
simplify site multihoming. Others may consider the trade-offs and
choose IPv6 NAT as a topology hiding mechanism. In other cases,
administrators may choose to deploy IPv6 NAT to parallel their
IPv4 NAT-based network architecture. Our goal is to define an
IPv6-to-IPv6 NAT mechanism, NAT66, that will minimize the negative
impacts of IPv6 NAT, in the event that some implementers do choose to
implement an IPv6 NAT mechanism, and some network administrators do
choose to deploy it.
</t>
</section>
<section title="NAT66 Overview">
<t>
NAT66 may be implemented in an IPv6 router to map one IPv6 address
prefix to another IPv6 address prefix as each IPv6 packet transits the
router. A router that implements a NAT66 function is referred to as a
NAT66 device.
</t>
<t>
In its simplest form, a NAT66 device will be attached to two network
links, one of which is an "internal" network link attached to a leaf
network within a single administrative domain, and the other of which
is an "external" network with connectivity to the global Internet.
All of the hosts on the internal network will use addresses from a
single, locally-routed prefix, and those addresses will be translated
to/from addresses in a globally-routable prefix as IP packets transit
the NAT66 device.
</t>
<t>
The following picture shows a NAT66 device attached to two networks.
In this example, the internal network uses IPv6 Unique Local
Addresses (ULAs) <xref target="RFC4193"/> to represent the internal
IPv6 nodes, and the external network uses globally routable IPv6
addresses to represent the same nodes.
</t>
<figure>
<artwork>
<![CDATA[
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+---------+
| NAT66 |
| Device |
+---------+
|
|
--------------------------------------
Internal Netowrk: Prefix = FD01:0203:0405:/48
]]>
</artwork>
</figure>
<t>
When a NAT66 device forwards packets in the "outbound" direction, from
the internal network to the external network, NAT66 overwrites the
IPv6 source address (in the IPv6 header) with a corresponding address
from the external prefix. When packets are forwarded in the "inbound"
direction, from the external network to the internal network, the IPv6
destination address is overwritten with a corresponding address in the
internal prefix. Using the prefixes shown in the diagram above, as an
IP packet passes through the NAT66 device in the outbound direction, the
source address prefix (FD01:0203:0405:/48) will be overwritten with
the external address prefix (2001:0DB8:0001:/48). In an inbound
packet, the destination prefix (2001:0DB8:0001:/48) will be
overwritten with the internal network prefix (FD01:0203:0405:/48). In
both cases, it is the local IPv6 address that is overwritten; the
remote IPv6 address remains unchanged. Nodes on the internal network
are said to be "behind" the NAT66 device.
</t>
<t>
NAT66 can also be used between two private networks. In these
cases, both networks may use ULA prefixes, with each subnet in one
network mapped into a corresponding subnet in the other network, and
vice versa. Or, each network may use ULA prefixes for internal
addressing and global unicast addresses on the other network. [TBD,
add pictures of these examples].
</t>
<t>
In some cases, more than one NAT66 device may be attached to a
network. In this case, they two NAT66 devices may be configured with
the same internal and external prefixes, or they may be configured
with the same internal prefix and different external prefixes. [TBD,
add pictures of these examples.]
</t>
</section>
<section title="NAT66 Address Mapping Mechanisms">
<t>
This document defines two address mapping functions that can be used
in NAT66 devices. To comply with this specification, NAT66 devices
MUST implement the Two-Way Algorithmic Address Mapping. NAT66 devices
SHOULD implement the Topology Hiding Option.
</t>
<t>
The Two-Way Algorithmic Address Mapping mechanism and the Topology
Hiding Option both use 1:1 (one-to-one) mappings, meaning that a given
internal address is always mapped to the same external address.
</t>
<t>
When the Two-Way Algorithmic mapping is used, no per-node or per-flow
state is maintained in the NAT66 box. Both inbound and outbound
packets are translated algorithmically, using only information found
in the IPv6 header. Due to this property, the Two-Way Algorithmic
Address Mapping can support both outbound and inbound connection
establishment without the need for state-priming or rendevous
mechanisms. This is a significant improvement over NAT44 devices, but
it also has significant security implications which are described in the
Security Considerations section.
</t>
<t>
The Topology Hiding Option is intended to obscure the subnet
information found in the internal IPv6 address prefix from external
view, so that an external node cannot determine the structure of the
internal network by looking at traffic outside of the NAT66 device.
This features is called "topology hiding", and it is one of the
benefits associated with NAT44. Because it is not possible to derive
the full internal address simply by looking at the external address,
the NAT66 device needs to maintain state in order to copy the correct
internal address into inbound packets. This also means that inbound
connection establishment will not work properly unless special
provisions are made to enable inbound connectivity, such as
configuring static state in the NAT66 device.
</t>
<section title="Checksum-Neutral Mapping">
<t>
The NAT66 address mapping mechanisms described in this document are
checksum-neutral, which means that they result in IP headers that will
generate the same pseudo-header checksum when the checksum is
calculated using the standard Internet checksum
<xref target="RFC1071"/>. Any changes that are made during
translation of the IPv6 prefix are offset by changes to other parts of
the IPv6 address. This results in the transport layers (such as TCP
and UDP) calculating the same IPv6 pseudo header checksum for both the
internal and external forms of the same packet, which avoids the need
for the NAT66 device to modify the transport layer headers.
</t>
<t>
The NAT66 address mapping mechanisms both use the same technique to
ensure that they produce checksum-neutral transformations. When a
changes is made to one of the fields in the IPv6 pseudo-header
checksum, the checksum field in the transport layer header may become
invalid. Fortunately, an incremental change in the area covered by
the Internet standard checksum <xref target="RFC1071"/> will result in
a well-defined change to the checksum value <xref target="RFC1624"/>.
So, a checksum change caused by modifying one part of the area covered
by the checksum can be eliminated by making a complementary change to
a different 16-bit field covered by the same checksum.
</t>
<t>
To produce a checksum neutral transformation, the NAT66 device
calculates the 16-bit one's complement sum of the internal and
external IPv6 prefixes. The difference between the original and
mapped prefix checksums is calculated using 16-bit one's complement
arithmetic, and the difference is added to a 16-bit value in another
area of the local IPv6 address, thus resulting in an IPv6 header that
will have the same pseudo-header checksum as the original header.
Although the same mechanism is used to ensure that both of the NAT66
mappings are checksum-neutral, there are differences in which parts of
the IPv6 header are mapped and where the complementary change is made.
</t>
<section title="Two-Way Algorithmic Address Mapping">
<t>
The Two-Way Algorithmic Address Mapping MUST be implemented on all
NAT66 devices. This mapping consists of mapping an internal IPv6
prefix, typically a ULA, to/from an external prefix, typically a
globally-routable unicast address, and making a complementary
modification to 16 subnet bits in bits 49 through 64 of the local IPv6
addresss. The same transformation is performed in both the inbound
and outbound directions, so the only state that is needed on the NAT66
box to peform this transformation is knowledge of the internal and
external address prefixes in use.
</t>
<t>
For the network shown in the example diagram in the NAT66 Overview
section above, we might have the following example:
</t>
<t>
Internal Prefix: FD01:0203:0405:/48
External Prefix: 2001:0DB8:0001:/48
</t>
<t>
If a node with internal address FD01:0203:0405:0001::1234 sends an
outbound packet through the NAT66 device, the resulting external
address will be 2001:0DB8:0001:D550::1234. The resulting address is
obtained by calculating the checksum of both the internal and external
48-bit prefixes, sutracting the internal prefix from the external
prefix using one's complement arithmetic and adding the result to the
16-bit subnet field (in this case 0x0001).
</t>
<t>
To show the work:
</t>
<t>
The one's complement checksum of FD01:0203:0405 is 0xFCF5.
The one's complement checksum of 2001:0DB8:0001 is 0xD245.
Using one's complement math, 0xD245 - 0xFCF5 = 0xD54F.
The subnet mask in the original packet is 0x0001.
Using one's complement math, 0x0001 + 0xD54F = 0xD550.
</t>
<t>
So, the value 0xD550 is written in the 16-bit subnet mask area,
resulting in a mapped external address of 2001:0DB8:0001:D550::1234.
</t>
<t>
When a response packet is received, it will contain the destination address
2001:0DB8:0001:D550::0001, which will be mapped using the same mapping
algorithm, back to FD01:0203:0405:0001::1234.
</t>
<t>
In this case, the difference between the two prefixes will be calculated as
follows:
</t>
<t>
Using one's complement math, 0xFCF5 - 0xD245 = 0x2AB0.
The subnet mask in the original packet = 0xD550.
Using one's complement math, 0xD550 + 0x2AB0 = 0x0001.
</t>
<t>
So the value 0x0001 is written into the subnet field, and the internal
value of the subnet field is properly restored.
</t>
<t>
This mapping results in no modification of the Interface Identifier
(IID), which is held in the lower half of the IPv6 address, so it will
not interfere with future protocols that may use unique IIDs for node
identification.
</t>
<t>
Use of this mapping is restricted to cases where both the internal and
external prefixes are 48 bits long (a /48) or shorter, leaving at
least 16 subnet bits that can be modified to ensure checksum
neutrality. This may not be a significant limitation in practice,
because it is expected that most NAT66 devices will be used to map
between a provider-allocated external prefix of /48 or shorter and a
ULA that uses the same prefix length as the external prefix. In cases
where one or both prefixes are longer than a /48, the Topology Hiding
Option can be used.
</t>
</section>
<section title="Topology Hiding Option">
<t>
The topology hiding option SHOULD be implemented on all NAT66 devices.
It is very similar to the Two-Way Algorithmic Address mapping, except
that the subnet bits in the destination address are mapped to zero in
the outbound direction and are restored to their original value in the
inbound direction. To remove the restriction on prefixes that have at
least 16 bits of subnet space available, the checksum adjustment is
made in the last 16 bits of the IP header, thus modifying the IPv6
Interface Identifier. Because the Interface Identifier may no longer
be unique, the "u" bit <xref target="RFC4291"/> is cleared in the IID.
This changes is also taken into account in the checksum adjustment.
</t>
<t>
For the network shown in the example diagram in the NAT66 Overview
section above, we might have the following example:
</t>
<t>
Internal Prefix: FD01:0203:0405:/48
External Prefix: 2001:0DB8:0001:/48
</t>
<t>
If a node with internal address FD01:0203:0405:0001::1234 sends an
outbound packet through the NAT66 device, the resulting external
address will be 2001:0DB8:0001:0000:0002::E782. The resulting
address is obtained by calculating the checksum of both the internal
and external 48-bit prefixes and subtracting the internal prefix
checsum from the external prefix checksum. If the "u" bit is cleared
in the original address (the IID has universal scope), set the bit in
the mapped address and add 0xFFFD to the checksum difference
calculated above. Then, add the checksum difference to the value o the last
16 bits of the IPv6 address.
</t>
<t>
To show the work:
</t>
<t>
The one's complement checksum of FD01:0203:0405:0001 is 0xFCF4.
The one's complement checksum of 2001:0DB8:0001:0000 is 0xD245.
Using one's complement math, 0xD245 - 0xFCF4 = 0xD550.
The original address has the "u" bit clear, so 0xD550 + 0xFFFD = 0xD54E.
The last 16 bits of the original address are 0x1234.
Using one's complement math, 0x1234 + 0xD54E = 0xE782.
</t>
<t>
So, when the prefix is mapped, the "u" bit is set in the IID, and the
value 0xE782 is written into the last 16 bits of the address, this results
in a mapped external address of 2001:0DB8:0001:0000:0002::E782.
</t>
<t>
When a response packet is received, it will contain the destination address
2001:0DB8:0001:0000:0002::E782. Unfortunately that address does not contain
enough information to do an algorithmic reverse transformation, as the subnet
bits were zeroed out when the external address was selected. Therefore, the
NAT66 will need to consult its internal state to perform the reverse address
mapping.
</t>
<t>
The internal state used for this mapping could consist of dynamic
per-node mapping state, as is maintained in most NAT44 devices today,
or it could consist of a static mapping of external addresses to internal
addresses. If dynamic state is used, inbound connections to
nodes that have not yet communicated externally will fail, because
there will be no state to perform the inbound mapping. NAT66
implementations SHOULD provide a means for network administrators to
configure static mapping state to allow inbound mapping when the
Topology Hiding Option is in use.
</t>
<t>
Note: We could place the checksum adjustment in the 16-bit subnet
field, if the prefixes are /48 or less, thus avoiding the need to
modify the IID in those cases. Is that worth doing? We can't blindly
overwrite the 16-bit following prefix no matter where they are,
because of the need to maintain the "u" and "g" bits in the 7th and
8th bits of the IID.
</t>
</section>
</section>
</section>
<section title="Prefixes for Internal Addressing">
<t>
IPv6 includes a form of local addressing called Unique Local Addresses
(ULAs) <xref target="RFC4193"/>, and it is RECOMMENDED that ULAs be
used to address network nodes that are located on an internal network
serviced by a NAT66 device.
</t>
<t>
NAT66 devices MUST support manual configuration of internal and
external address prefixes, and MUST NOT place any restrictions on
those prefixes except that they be valid IPv6 unicast address
prefixes, as described in <xref target="RFC4291"/>, and that they
meet the requirements outlined in this document.
</t>
<t>
NAT66 devices that do not have a manually configured internal prefix
SHOULD randomly generate a ULA prefix for the internal network and
advertise that prefix in router advertisements. NAT66 boxes with more
than one internal interface SHOULD assign a subnet number to each
link, and include the subnet number in router advertisements on the
corresponding link. NAT66 devices that generate a ULA prefix MUST
generate the prefix using a random number as described in RFC4291
<xref target="RFC4193"/>, and SHOULD store the randomly generated
prefix is non-volatile storage for continued use.
</t>
</section>
<section title="A Note on Port Mapping">
<t>
In addition to overwriting IP addresses when packets are forwarded,
NAT44 devices often overwrite the source port number in outbound
traffic, and the destination port number in inbound traffic. This
mechanism is called "port mapping".
</t>
<t>
The major benefit of port mapping, and perhaps its only significant
benefit, is that it allows multiple computers to share a single IPv4
address. A large number of internal IPv4 addresses (typically from the
10.0.0.0/8 prefix) can be mapped into a single external, globally
routable IPv4 address, with the local port number used to identify
which internal node should receive each inbound packet. This address
amplification feature should not be needed in IPv6, where every
attached network should be assigned at least a /48 prefix, leaving
room for 16 subnet bits and a 64 bit Interface Identifier
<xref target="RFC3587"/>.
</t>
<t>
Since port mapping requires re-writing a portion of the transport
layer header, it requires NAT66 devices to be aware of all of the
transport protocols that they forward, thus stifling the development
of new and improved transport protocols. Modifying the transport
layer header is incompatible with security mechanisms that encrypt the
full IP payload, and restricts the NAT66 device to forwarding
trasnport layers that use weak checksum algorithms that are easily
recalculated in routers. Since there is significant detriment caused
by modifying transport layer headers and very little, if any, benefit
to the use of port mapping in IPv6, NAT66 devices that comply with
this specification MUST NOT perform port mapping.
</t>
</section>
<section title="Security Considerations">
<t>
When NAT66 is deployed using the two-way, algorithmic address mapping,
it allows direct inbound connections to internal nodes. While this
can be viewed as a benefit of NAT66 vs. NAT44, it does open internal
nodes to attacks that would not be possible in a NAT44 network.
Although this situation is no worse, from a security standpoint, than
running IPv6 with no NAT, some enterprises may assume that a NAT66
device will offer similar protection to a NAT44 device. For this
reason, it is RECOMMENDED that NAT66 devices include an IPv6 firewall
function, and the firewall function SHOULD be configured by default to
block all incoming connections. Administrators could then enable
inbound connectivity for specific ports by reconfiguring the firewall.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no IANA considerations.
</t>
</section>
<section title="Acknowledgements">
<t>
The checksum-neutral algorithmic address mapping described in this
document is based on e-mail written by Iljtsch Van Beijnum. A
similar mapping mechanism to the one described in this document
was previously described in a document that can be found here:
http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf.
[TBD, move to an informative reference].
</t>
<t>
The following people provided advice or review comments that
substantially improved this document: Ed Jankiewicz, .
</t>
<t>
This document was written using the xml2rfc tool described in RFC 2629
<xref target="RFC2629"/>.
</t>
</section>
<section title="Change Log">
<section title="Changes Between -00 and -01">
<t>
There were several minor changes made between the -00 and -01 versions
of this draft:
<list style="symbols">
<t> Added Fred Baker as a co-author.</t>
<t> Minor mathematical corrections.</t>
<t> Added AH to paragraph on NAT security issues. </t>
<t> Added additional NAT topologies to overview (diagrams TBD). </t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1071;
&rfc1624;
&rfc2119;
&rfc3587;
&rfc4193;
&rfc4291;
</references>
<references title="Informative References">
&rfc2629;
&rfc2993;
&rfc4864;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:59:36 |