[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.
>
>