One document matched: draft-van-beijnum-modified-nat-pt-01.txt
Differences from draft-van-beijnum-modified-nat-pt-00.txt
Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: May 17, 2008 November 14, 2007
Modified Network Address Translation - Protocol Translation
draft-van-beijnum-modified-nat-pt-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 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
A smooth transition from IPv4 to IPv6 requires that either all hosts
are upgraded to dual stack before the first hosts can become IPv6-
only, or that there be some mechanism for IPv6-only hosts to talk to
IPv4-only hosts. Expecting the former within a reasonable timeframe
isn't realistic, based on current adoption of dual stack combined
with the latest projections for the IPv4 depletion that point to a
date early in the next decade. And the IETF has recently deprecated
the main mechanism that allows the latter: NAT-PT.
van Beijnum Expires May 17, 2008 [Page 1]
Internet-Draft Modified NAT-PT November 2007
This document proposes modifications to NAT-PT that address the
reasons why the mechanism was deprecated. This should allow future
deployment of the modified NAT-PT as an IPv4-to-IPv6 transition
mechanism, giving operators the option to run their networks largely
IPv6-only.
1. Introduction
The original NAT-PT mechanism outlined in [RFC2766] couples three
underlying techniques to arrive at a comprehensive solution that
allows IPv6-only hosts to initiate connections or associations
towards IPv4-only hosts:
o Stateless IP and ICMP Translation [RFC2765]
o Network Address / Port Translation
o A DNS Application Layer Gateway [RFC2694]
Basically, when an IPv6 host wants to connect to a service, it looks
up the associated host/service name in the DNS. If no AAAA records
are available for the name in question, the DNS ALG synthesizes an
AAAA record based on the A record for the host/service and a prefix
that's routed to a translation device. The IPv6 host initiates
communication towards the resulting IPv6 address. The associated
packets end up at the translator, which recovers the original IPv4
destination address, translates between IPv6 and IPv4, performs IPv4
NAT and sends the resulting packet to the IPv4 destination. Return
packets are translated back and sent to the IPv6 host.
[RFC4966] explains why this is problematic. The main objections boil
down to hosts being exposed to an unexpected environment, issues with
referrals in the absense of relevant Application Layer Gateways,
generation of synthetic DNS responses that may be harmful if not
properly contained and constraints on network topology.
This document proposes two different approaches to mitigate this
problem: one where the IPv6-side is aware of the translation, and one
where the IPv4-side is aware of the translation. The former is
useful to give hosts with only IPv6 connectivity access to the IPv4-
only internet, the latter is an easy way to make services available
over IPv6 with very few changes to the IPv4 infrastructure providing
that service.
Although this document goes into some detail, it's intended as a
discussion document; as such, not every aspect is completely worked
out. Readers are encouraged to also review [I-D.carpenter-shanti].
van Beijnum Expires May 17, 2008 [Page 2]
Internet-Draft Modified NAT-PT November 2007
In some circles, a distinction is made between Network Address
Translation (NAT) which only translates just addresses, and Network
Address/Port Translation (NAPT) which translates both addresses and
TCP/UDP port numbers. No such distinction is made here; "NAT" is
used to refer to both types of translation.
2. Operation with modifications on the IPv6 side
There are two modifications possible. The only one mandated by this
document is the use of A records.
3. Use of A records
In the original NAT-PT design a DNS ALG would create synthetic AAAA
DNS records for FQDNs that only have A records. This behavior is no
longer supported; IPv6 hosts that want to communicate with IPv4 hosts
must now look up the A records themselves and create a synthetic IPv6
destination address from the IPv4 address bits and a /96 prefix that
is routed to the translator. The /96 prefix and hence the
translation device used may be configured administratively, but an
anycasted default prefix (TBD) is made available so that IPv6 hosts
can use a topologically close translation device without
configuration.
3.1. Use of a synthetic IPv4 source address
Optionally, IPv6-only hosts may support IPv4 (and IPv6-mapped IPv4)
socket calls for compatibility with applications that don't support
native IPv6 communication and/or need to be aware of the fact that
communication is happening over IPv4 and is subject to NAT. A
natural way to indicate this is through the use of an IPv4 source
address from [RFC1918] space.
An IPv6-only host implementing IPv4 compatible socket calls picks one
of its global scope IPv6 addresses as the source address for MNAT-PT.
It then generates a local IPv4 address in the prefix 172.31.0.0/16,
where the lower 16 bits are chosen such that a TCP or UDP checksum
computed over the IPv6 addresses that appear on the wire are the same
as those resulting from the synthetic IPv4 source address and the
IPv4 destination address.
This means that the value of the lower 16 bits in the synthetic IPv4
address are generated through the one's complement addition of the
16-bit words that make up the 96 bit prefix used for IPv4
destinations reachable through the translator and the selected IPv6
source address. Then, a one's complement subtraction of the value
van Beijnum Expires May 17, 2008 [Page 3]
Internet-Draft Modified NAT-PT November 2007
44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix.
The result of this is that TCP and UDP checksums computed over both
the IPv4 and MNAT-PT IPv6 representations of packets destined for the
translator are the same. UDP packets MUST have a valid checksum.
The resulting synthetic IPv4 address is internally used as the source
address in all IPv4 processing.
3.2. Operation
Packets towards to-be-translated IPv4 destinations are transmitted
over the network as usual. The translation device performs SIIT
translation and IPv4 NAT. The possible artificial IPv4 source
address is ignored during these steps, since it is not required by
either of them except as a means to (de)multiplex packets to/from
different hosts. However, since different hosts served by the same
translation device may have selected the same artificial IPv4
address, (de)multiplexing based on this value won't work well. So
the SIIT and NAT functions must be integrated such that the NAT
(de)multiplexes based on the real IPv6 source address rather than the
artificial IPv4 address.
4. Operation with modifications on the IPv4 side
In complex networks, such as large scale content distribution
networks, it is very hard to upgrade the entire infrastructure to
IPv6. In these cases, it can be beneficial to deploy SIIT at the
edge of an administrative domain in order to make services available
over IPv6 while maintaining a largely unmodified IPv4 network
internally. Since it's not possible to encode an IPv6 address into
an IPv4 address, operation is slightly differently here: a range of
IPv4 addresses dynamically mapped to the IPv6 addresses that the IPv4
host communicates with. Mappings can created in several ways:
1. When an incoming packet from an IPv6 host arrives
2. When the IPv4 host explicitly request a mapping over a control
connection
3. When the IPv4 host sets up a TCP session to the translation
device and requests a mapping in-band (like the HTTP CONNECT
method)
4. As a side effect from DNS lookups
Because 3. is already readily available in HTTP proxies and [RFC4966]
outlines problems with DNS ALGs and also because this doesn't support
van Beijnum Expires May 17, 2008 [Page 4]
Internet-Draft Modified NAT-PT November 2007
referrals by address, 3. and 4. will not be discussed any further.
4.1. Mapping creation for incoming IPv6 packets
When an incoming IPv6 packet arrives, the translation device selects
an available IPv4 address from the pool of addresses (presumably,
these are [RFC1918] addresses). It then either maps the IPv6 source
address to the selected IPv4 address regardless of protocol and port
information, or it creates a mapping for a single UDP association or
TCP session. The former has the advantage that multiple sessions/
associations can be translated without creating more mapping state,
and that non-UDP/TCP protocols can be accommodated. Overloading IPv4
addresses from the pool allows for more mappings for a given pool
size. The destination IPv6 address is replaced with the IPv4 address
for the intended host. Optionally, it is possible to have one IPv6
destination address map to more than one IPv4 address; in this case,
the translation device also tracks which IPv6 destination address is
forwarded to which IPv4 destination.
The IPv4 host receiving the translated packets can either operate as
an unmodified IPv4 host, in which case it can run protocols that
don't embed IP addresses in the communication. However, if addresses
must be embedded, the IPv4 host must be made aware of the
translation, recover the original IPv6 addresses used and present
these to the application. The IPv6 addresses are recovered through a
control connection towards the translation device.
4.2. Explicit mapping creation
Explicit mapping creation over a control connection happens when the
IPv4 host wants to initiate communication towards an IPv6
destination. (Note that when IPv4 addresses from the pool aren't
overloaded, it's possible for the IPv4 host to set up new sessions
towards an IPv6 host it's already communicating with.) When
applications on the IPv4 host use connect(), send() and similar
primitives towards IPv6 destinations, the TCP/IP stack must delay
these calls while it asks the translation device to create a mapping
towards the requested destination. When the mapping is created, the
TCP/IP stack continues to process the socket calls but creates IPv4
packets towards the pool address that belongs to the created mapping.
5. The control connection
Optionally, A control connection is used to create mappings, recover
real addresses, perform authentication and detect loss of state in
the translation device. Very likely, a suitable existing light-
weight protocol can be reused for this.
van Beijnum Expires May 17, 2008 [Page 5]
Internet-Draft Modified NAT-PT November 2007
Discussion: do we want to perform generic NAT traversal functions
though the control connection, or do we want to use existing uPnP and
NAT-PMP protocols for this? There are security issues with these
protocols, but they are widely used in home networks. The use of
protocols like STUN is also possible, but these aren't widely
deployed in home networks.
6. Disadvantages
The disadvantage of this mechanism is that it requires the host on
one side of the connection and NAT-PT devices to be modified to
support the mechanism. As such, deployment is non-trivial.
7. Advantages
There are several advantages. An important one is that NAT issues
only come up when the host is communicating towards IPv4 addresses.
As such, it's trivial for applications to limit NAT workaround code
to sessions towards IPv4 destinations and assume global
addressability for IPv6 destinations. Since there is no DNS ALG,
there are no issues with possible leakage of synthetic AAAA records.
Both IPv4 applications that use IPv4 socket calls and IPv6
applications that use IPv6 socket calls with IPv6-mapped IPv4
addresses can work over MNAT-PT. Alternatively, light-weight
implementations may omit all IPv4 code except the ability to resolve
A records.
7.1. Advantages over providing real NATed IPv4 connectivity
An obvious way to enjoy many of the same benefits would be to build a
network that supports both IPv6 and IPv4 with NATed connectivity.
However, this means that there must be an IPv4 network infrastructure
in place in the form of IPv4 routers and IPv4 address provisioning
(DHCP). Today, this is easy to do in smaller installations if there
is a single public IPv4 address available. However, in larger
networks the planning of private IPv4 addressing can become
cumbersome, and when IPv4 addresses are scarce, it may be unavoidable
to implement multiple levels of NAT. Multiple levels of NAT at the
very least impose the limits of the most restrictive NAT, and also
make hole punching that is used to be able to receive incoming
connections much harder as a single set of port numbers must be
shared by a larger number of hosts. NAT traversal technologies may
or may not support multiple layers of NAT.
With MNAT-PT, it's only necessary to provision IPv6 connectivity and
addressing, which is easier to plan for because unlike IPv4, a
van Beijnum Expires May 17, 2008 [Page 6]
Internet-Draft Modified NAT-PT November 2007
standard /64 IPv6 subnet supports arbitrary numbers of hosts. The
translation device that performs NAT and the hosts making use of the
MNAT-PT service can be located with few topological constraints, so
multiple layers of NAT are much easier to avoid.
8. Evaluation of RFC4966 concerns
This section provides an overview of the issues raised in [RFC4966]
and how they apply to the use of modified NAT-PT with modifications
on the IPv6 side.
8.1. Issues with Lack of Address Persistence
To-be-translated IPv4 destination addresses map to the same IPv6
destination address until the host selects a different /96 prefix.
However, if addresses are stored in their IPv4 form, this doesn't
lead to broken referrals. Issues with mapping persistence from the
IPv4 side to the IPv6 side are the same as with regular NAT and can
be solved in the same way: by having the application or OS set up a
persistent mapping that allows incoming connections.
8.2. DoS Attacks on Memory and Address/Port Pools
Denial-of-service issues are mostly the same as with regular NAT.
When a non-anycast translator is used, it's likely that
authentication through a control connection is required, allowing for
easy rejection of to-be-translated traffic coming from addresses that
don't have an active control connection. However, unless the IPv6
source host and the translator are prepared to set up an IPsec
tunnel, there is no way to reject to-be-translated traffic which
spoofs the source address of a host with an active control
connection. If the source host uses an IPv6 source address for this
communication that it doesn't use for other types of communication,
only on-path attackers or hosts on the same subnet have easy
knowledge of the source address in question.
8.3. Issues Directly Related to Use of DNS-ALG
N/A.
8.4. Impact on IPv6 Application Development
Applications see regular IPv4 destination addresses for to-be-
translated destinations so they can engage IP version specific code
paths as required. The presence of the [RFC1918] synthetic source
address makes it possible for applications to use NAT workarounds for
to-be-translated destinations. The extra work the application needs
van Beijnum Expires May 17, 2008 [Page 7]
Internet-Draft Modified NAT-PT November 2007
to do here is the same as it would when running on a dual stack host.
Alternatively, TCP/IP stacks may forego implementing the synthetic
IPv4 source address and/or applications may choose to remain ignorant
of whether they're communicating with an IPv4 or IPv6 correspondent.
In those cases, address-based referrals are likely to break for IPv4
destinations unless the MNAT-PT translator employs an Application
Layer Gateway for the protocol that's used.
9. IANA considerations
None at this time.
10. Security considerations
Security considerations need to be worked out in a revision of this
document.
11. References
11.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
11.2. Informative References
[I-D.carpenter-shanti]
Carpenter, B., "Shimmed IPv4/IPv6 Address Network
van Beijnum Expires May 17, 2008 [Page 8]
Internet-Draft Modified NAT-PT November 2007
Translation Interface (SHANTI)", draft-carpenter-shanti-01
(work in progress), November 2007.
Appendix A. Document and discussion information
The latest version of this document will always be available at
http://www.muada.com/drafts/. Please direct questions and comments
to the v6ops mailinglist or directly to the author.
Author's Address
Iljitsch van Beijnum
IMDEA Networks
Av. Universidad 30
Leganes, Madrid 28911
ES
Phone: +34-91-6246245
Email: iljitsch@muada.com
van Beijnum Expires May 17, 2008 [Page 9]
Internet-Draft Modified NAT-PT November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
van Beijnum Expires May 17, 2008 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 03:46:10 |