[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: on NAT-PT
The following text is an extract from
draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with
address translation:
An obvious candidate for enabling communication between IPv4-only and
IPv6-only hosts is "network address translation, protocol
translation"
[NAT-PT]. The NAT-PT mechanisms has two components, address
translation
and address discovery: address translation is the processing of IP
packets by a NAT; address discovery is the mechanism by which an
IPv4-
only or IPv6-only host discovers the "translated address" at which
packets for their correspondent should be addressed. The NAT-PT
specification proposes to solve address discovery by using a DNS ALG,
as
specified in section 4 of [NAT-PT].
This section makes an important assumption: it assumes that the
NAT-PT
acts as a bridge between two networks, one IPv6-only and the other
IPv6-
only. As a result, the DNS-ALG will translate a DNS request for a
AAAA
record coming from the IPv6 host into a request for an A record, and
vice
versa. The problem is that address translation does not know if the
traffic originates from an IPv4 only/IPv6 only node or from a dual
stack
node. When a dual stack node A wants to communicate with an IPv4 only
host B, the dual stack host A gets either the IPv4 address of B
(preferred) or an IPv6 address which is some kind of translation of
the
IPv4 address of B. This latter situation is not wanted, because it
means
unnecessary translation between IPv4 and IPv6. This is shown in the
table
below.
============================================================
| + A | | | |
| + | IPv4 only | dual stack | IPv6 only |
| B + | | | |
============================================================
| | | | |
| IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 |
| only | address | address | address |
| | | | |
------------------------------------------------------------
| |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX|
| dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or |
| stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 |
| |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX|
------------------------------------------------------------
| | | | |
| IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 |
| only | address | address | address |
| | | | |
============================================================
The boxes with XXX-es are the cases where address translation could
result in unwanted translation.
In short, the problem is that inserting the DNS-ALG function in a
gateway might be beneficial in the IPv4-only to IPv6-only scenario, but
is detrimental in the scenarios that involve dual stack hosts. Since
there is likely to be many more dual stack hosts than IPv6 only hosts,
this means that NAT-PT as its stands is detrimental to IPv6 transition.
-- Christian Huitema
> -----Original Message-----
> From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com]
> Sent: Wednesday, December 04, 2002 12:45 PM
> To: itojun@iijlab.net
> Cc: v6ops@ops.ietf.org
> Subject: Re: on NAT-PT
>
> Itojun,
>
> thanks for your comments below; sorry for the very late reply!
>
> -----Original Message-----
> From: ext itojun@iijlab.net [mailto:itojun@iijlab.net]
> Sent: 28 November, 2002 06:47
>
> there are some concerns raised in the working group meeting
> with respect to NAT-PT. it seems to me that the concerns does
not
> have enough technical ground (or there are some confusions in
> understanding how NAT-PT works). i don't see the need for
revising
> NAT-PT at all. some clarifications on the document might be
nice,
> but no major re-work is needed, IMHO.
>
> draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9:
>
> > NAPT-PT introduces a number of limitations that are expected to
be
> > magnified within the 3GPP architecture. Some of these limitations
> > are listed here:
> > 1. NAPT-PT is a single point of failure for all ongoing
> > connections.
> > 2. Additional forwarding delays due to further processing,
when
> > compared to normal IP forwarding.
> > 3. Problems with source address selection due to the inclusion
of
> > a DNS ALG on the same node [NATPT-DNS].
> > 4. NAPT-PT does not work (without application level gateways)
for
> > applications that embed IP addresses in their payload.
> > 5. NAPT-PT breaks DNSSEC.
> > 6. NAPT-PT does not scale very well in large networks.
>
> (1), (2), and (4) are inherent problem with NAT. it is
unavoidable.
> if you wish to avoid this, you'll need to make cellular node a
dual
> stack node and make them use IPv4 directly (instead of using
IPv6-
> to-
> IPv4 translation).
>
> JW: Right.. I am afraid that the dual stack won't work for all the
> scenarios (like IMS scenario 1). Furthermore, availability of public
IPv4
> addresses is not too good in many large (3GPP) networks; use of
private
> v4 addresses together with v4 NATs won't make the situation better..
Do
> you think that listing these problems in our document is ok? Should we
> write some clarifying text that v4 NAT has same type of problems (i.e.
not
> only NAT-PT)?
>
> (3) is incorrect, see below.
>
> (5) - when you rely upon DNS responses created on the fly, as
well
> as
> a box that rewrites your data traffic, why this is a
show-stopper?
>
> JW: Well, I wouldn't necessarily say that it is a showstopper, the
problem
> is just mentioned here.
>
> (6) - see below.
>
> > To minimize the problems associated with NAPT-PT, the following
> > actions are recommended:
> > 1. Separate the DNS ALG from the NAPT-PT node.
> > 2. Ensure that NAPT-PT does not become a single point of
> > failure.
> > 3. Allow for load sharing between different translators.
That
> > is, it should be possible for different connections to go
> > through different translators. Note that load sharing
alone
> > does not prevent NAPT-PT from becoming a single point of
> > failure.
> > There are certain ways to fix the problems with NAPT-PT, one
> > suggestion is [NAT64].
>
> (1) is not correct. NAT-PT RFC does not specify where to place
DNS-
> ALG.
> DNS-ALG and NAT-PT translation part can reside on different
boxes.
> when there's only one IPv4 address available to the site,
there's no
> other choice than to collocate DNS-ALG and the translation part.
> (RFC2766 seems to talk about this situation only, which might be
> the source of the confusion)
>
> JW: OK... What would be your (text) suggestion; forgetting this
> recommendation? Alain D. commented in his mail that the DNS-ALG part
in
> the "v6 to v4" case needs to removed from the NAT-PT document.
>
> (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in
> translation part). SIIT could be another choice, but there are
> some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in
> the use of IPv4 mapped address on wire.
>
> JW: Thanks for the pointer; I agree that avoiding it to become a
single
> point of failure is not an easy task.
>
> (3) is not correct. you can place the following boxes and
perform
> load
> balancing between NAT-PT translation part. see RFC3142 page 5
for
> more details.
> - multiple NAT-PT translation part, configured with different
NAT-PT
> translation prefix, and
> - DNS-ALG that returns addresses crafted from multiple different
> NAT-PT
> translation prefix randomly
>
> JW: I will have a look at RFC3142.
>
> Thanks,
> -Juha W.-
>
> P.S. I agree with Brian Carpenter that we need a document discussing
the
> issues with NAT-PT; after that we can see more clearly, how (/
whether) we
> shall revisit the NAT-PT RFC.