Subject: RE: on NAT-PT

From: "Christian Huitema" <[email-masked]>
Date: Wed, 4 Dec 2002 14:04:19 -0800

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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 12:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: on NAT-PT
> 
> Itojun,
> 
> thanks for your comments below; sorry for the very late reply!
> 
> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> 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.

---

From: [email-masked]
Date: Thu, 05 Dec 2002 08:48:41 +0900

>draft-huitema-ngtrans-unmaneval-01.txt, section 3.2.1: the problem with
(snip)
>this means that NAT-PT as its stands is detrimental to IPv6 transition.

	i don't think you have checked my initial posting.
	header is attached as an evidence.

itojun

---
To: [email-masked]
Subject: on NAT-PT
From: [email-masked]
Date: Thu, 28 Nov 2002 13:46:37 +0900
Sender: [email-masked]

	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.

itojun

(snip)
draft-huitema-ngtrans-unmaneval-01.txt, page 4:

>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

	"and the other IPv4-only", i suppose.

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

	the answer is simple - don't use DNS-ALG if you are a dual stack node.
	use DNS-ALG as your recursive resolver only when you are IPv6 only
	node (hence you use NAT-PT translation part if the ultimate
	destionation is IPv4-only).