One document matched: draft-van-beijnum-modified-nat-pt-00.txt
Network Working Group I. van Beijnum
Internet-Draft IMDEA Networks
Expires: May 15, 2008 November 12, 2007
Modified Network Address Translation - Protocol Translation
draft-van-beijnum-modified-nat-pt-00
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 15, 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. Current levels of dual stack deployment suggest
that 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 15, 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 in order to 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.
van Beijnum Expires May 15, 2008 [Page 2]
Internet-Draft Modified NAT-PT November 2007
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. 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.
van Beijnum Expires May 15, 2008 [Page 3]
Internet-Draft Modified NAT-PT November 2007
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
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
van Beijnum Expires May 15, 2008 [Page 4]
Internet-Draft Modified NAT-PT November 2007
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. 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
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 protocol can be reused for this.
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.
van Beijnum Expires May 15, 2008 [Page 5]
Internet-Draft Modified NAT-PT November 2007
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
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.
van Beijnum Expires May 15, 2008 [Page 6]
Internet-Draft Modified NAT-PT November 2007
8. IANA considerations
None at this time.
9. Security considerations
Security considerations need to be worked out in a revision of this
document.
10. 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.
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.
van Beijnum Expires May 15, 2008 [Page 7]
Internet-Draft Modified NAT-PT November 2007
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 15, 2008 [Page 8]
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 15, 2008 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 09:43:25 |