[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: on NAT-PT



hi christian,
i don't think this a problem in na(p)t-pt, but more a problem in the way
dns-alg works. for instance, if we could configure the dns-alg in such a way
that it does the following:
1)maintain a table which maps the source ip address of the dns query and the
type of query ("A" or "AAAA")
2)generate a dual-query ("A" + "AAAA") every time a dns query is detected.
3)when it intercepts a dns response it should 
->translate the "A" response to "AAAA" response if the original quey was
"AAAA" and the response is "A" only
->translate the "AAAA" response to "A" response if the original query was
"A" and the response is "AAAA" only
->forward the "A" response only , if the original query was "A" and a dual
response is received.
->forward the "AAAA" response only , if the original query was "AAAA" and a
dual response is received.

regards
Anand Thakur
HCL Perot Systems
A-14 Sector-57,Noida
tel ext. - 3257
mobile:9811748512

> -----Original Message-----
> From:	Christian Huitema [SMTP:huitema@windows.microsoft.com]
> Sent:	Thursday, December 05, 2002 3:34 AM
> To:	juha.wiljakka@nokia.com; itojun@iijlab.net
> Cc:	v6ops@ops.ietf.org
> Subject:	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.
> 
>