Subject: RE: ocean: do not boil

From: Margaret Wasserman <[email-masked]>
Date: Thu, 26 Sep 2002 04:52:17 -0400

At 04:07 AM 9/26/02, Bound, Jim wrote:
>every input I get is that they don't want NAT and want it to go away as 
>soon as possible.

To be replaced by NAT-PT?

What is the technical advantage to running an IPv6-only internal network
that uses NAT-PT to reach external IPv4-only services, as opposed to running
a shared IPv4/IPv6 network with IPv4 NAT?

[Please give _technical_ reasons, like X works with NAT-PT, but doesn't
work with IPv4 NAT...  I understand that some folks have emotional/marketing/
other reasons for wanting to use something they think of as "pure IPv6", and
we may need to deal with that attitude in the marketplace.  I'd just like to
put that aside for a moment and understand the technical differences between
these two solutions.]

I've been thinking about this a lot, and I have come up with the following
thoughts:

Network set-up is fairly similar in these two cases:

         - An IPv4/IPv6 network with IPv4 NAT requires:
                 - Setting up an IPv4 NAT box(es).  This includes
                         providing at least one globally routable
                         IPv4 address (to use as the source address
                         for translated packets).
                 - Configuring routers with IPv4 and IPv6
                         prefixes and default routes,
                         including IPv4 default routes
                         that lead out through the NAT box(es)
                 - Setting up an IPv4 DHCP server
                 - Running dual-stack hosts and routers

         - An IPv6-only network with NAT-PT requires:
                 - Setting up a NAT-PT box(es).  This includes
                         providing at least one globally routable
                         IPv4 address (to use as the source address
                         for translated packets).
                 - Configuring routers with IPv6 prefixes and default
                         routes, plus static routes to send traffic
                         addressed to IPv4 mapped addresses out through
                         the NAT-PT box(es)
                 - Running special DNS resolver code on the hosts and/or
                         configuring DNS servers to return AAAA IPv4 mapped
                         addresses for any A records.

Please note that both solutions require IPv4 service at the translation
point, including at least one globally routable IPv4 address.

Once the network has been set-up, these two choices _should_ work the
same for IPv4 traffic sent outside the site.  However, there are a
few of key differences:

         - The IPv4 NAT solution supports the use of IPv4-only
                 services within the site, whereas NAT-PT only
                 supports IPv4 communication with the outside (there
                 is no internal IPv4 routing).

         - The NAT-PT solution does not require running a DHCP server
                 or assigning private IPv4 prefixes to internal networks.

         - The NAT-PT solution involves changes to DNS (either to
                 resolver on each host, or to the server), and the IPv4
                 NAT solution does not.

Are there some other technical advantages to the NAT-PT solution that I
am missing?

How will hosts know that they are running in a NAT-PT environment,
and that they shouldn't send IPv4 traffic?  Will they default to
using IPv4-mapped addresses whenever they don't have IPv4 addresses
configured?  What would be the implications of this behaviour
(if any) in the event of a DHCP failure on an IPv4-only or IPv4/IPv6
network that is running these same implementations?

Is the routing set-up necessary to support multiple NAT-PT boxes the
same as the routing set-up needed to support multiple IPv4 NATs?  What
are the key differences, if any?

I am concerned about the DNS modifications needed to make NAT-PT work
correctly.  We know that applications that currently work behind an
IPv4 NAT will work properly with the IPv4 NAT choice.  Are we _sure_
that all of those applications will work properly in the NAT-PT case?
Who has explored this in detail, and what did you find?

BTW, I think it is _very_ appropriate for the working group to be
analyzing different solution choices at this point.  Two of our scenario
documents are nearly complete (3GPP and unmanaged) and work is already
underway on the analysis documents.  Those analysis documents will
contain our recommended solutions for different scenarios, so it
makes perfect sense for us to discuss which solutions we will
recommend and why.

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Sep 2002 14:04:27 +0200 (MEST)

Overall these are good questions.
However, some details are muddled due to us having both NAT-PT and NAT64
and they work slightly differently. Example below.

There is also a larger issue to keep in mind when comparing NATv4 and 
transition specific NATs (whether NAT-PT, nat64, or something else).
Presumably there is a gradual evolution of the ALG support in NATv4
boxes (special support for special application protocols).
There is a danger in having a separate transition specific NAT in that
it might lag behind the NATv4 ALG support. Hence folks might get less
things to work with the transition specific NAT until IPv6 sales volume
makes the transition specific NAT be ahead of NATv4 in terms of
special ALGs.
For that reason it might make to look very hard at the use of off the shelf
NATv4 technology combined with an IPv6 router.

> network that is running these same implementations?

 - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA records,
   thus the host doesn't do anything special.

 - A host with NAT64 support would receive A records thus presumably it
   would determine to send using IPv6 based on the fact that it doesn't
   have any configured IPv4 addresses (or no IPv4 routers in the routing
   table, or an implementation specific knob).

    Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 09:27:53 -0400

> a shared IPv4/IPv6 network with IPv4 NAT?

it's a tradeoff - NAT-PT is probably slightly less functional to apps (will 
cause a few more apps to break than NATs do) but in exchange for using it
you get to get rid of all IPv4 traffic on your local network.

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 09:29:09 -0400

this doesn't prevent IPv4 traffic - it only eliminates one source of
IPv4 addresses.  DNS is not the only such source.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 26 Sep 2002 09:58:16 -0400

Hi Erik,

>and they work slightly differently. Example below.

I agree.  In retrospect, I probably should not have tried to lump
the NAT-PT and NAT64 cases together, because of the DNS differences that
you have outlined.

>NATv4 technology combined with an IPv6 router.

Right.  We should at least consider parallel IPv4 and IPv6 infrastructure
as part of the solution space when customers need to access IPv4 and IPv6
services from the same site.

We may need to compare this solution to other solutions on a case-by-case
basis, depending upon the scenario we are discussing, especially if there
are significant differences in scalability, performance, etc.

>    thus the host doesn't do anything special.

And, if the application tries to send to an IPv4 address?  Would it just
fail with "no route to address", or something like that?

>    table, or an implementation specific knob).

Right, and this is the part that raises my concerns...  In order for a
dual-stack node to exist in this environment, it would need to have two
different "modes" of operation -- one where all A records are translated
to AAAA records (if behind NAT-PT), and one where the A records result
in IPv4 traffic (when on an IPv4 network).  How would the node decide
which "mode" it should be using?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 26 Sep 2002 10:00:38 -0400

>you get to get rid of all IPv4 traffic on your local network.

What is the advantage of getting rid of all IPv4 traffic on the local
network, since it will just be replaced with translated IPv6 traffic?

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Sep 2002 16:02:57 +0200 (MEST)

> fail with "no route to address", or something like that?

I think so; at least I don't recall seeing this case discussed.

> which "mode" it should be using?

One way is to determine the mode based on whether the node has an
IPv4 address. Thus the node tries to use DHCPv4 to get an IPv4 address
and if that fails it assumes it is IPv6 only and operates in the nat65 mode.
Of course, if the IPv4 address can be assigned using autonet (i.e. link-local
IPv4 addresses), then this needs to be taken into account when trying to
automate this mode selection.
But operationally I suspect always assigning IPv4 addresses, whether link-local
or private RFC 1918 space, and using an IPv4 NAT is simpler since there is one
less mode to worry about.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 10:02:52 -0400

> network, since it will just be replaced with translated IPv6 traffic?

I don't really know, since I don't manage networks.  But I can imagine
that it's somewhat saner to have only one IP protocol to monitor and 
only one set of host-to-address bindings to deal with.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Sep 2002 16:13:01 +0200 (MEST)

> IPv4 addresses.  DNS is not the only such source.

Yep. But it is far from clear to me that NAT-PT handles the case when an
IPv4 address is used by an application (whether it came from some application
protocol payload or elsewhere). I think this is just the NAT+ALG issue
restated; if IP addresses appear in the payload of packets an ALG is needed in
the NAT to map those IP addresses.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Sep 2002 16:15:46 +0200 (MEST)

> you get to get rid of all IPv4 traffic on your local network.

But you can get rid of the local IPv4 traffic (i.e. no need to configure 
local IPv4 routing) by tunneling IPv4 in IPv6 locally and using the DSTM
DHCP options for getting such tunnels configured.

This requires implementing more stuff on the nodes, and it adds
tunneling overhead on the wire.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 10:17:40 -0400

> the NAT to map those IP addresses.

actually there are cases where IP addresses in the payload work fine 
through NAT (the app deals with scoped addresses by passing around
multiple addresses and since it can't tell which addresses are valid
in which scope it tries multiple addresses, doing its own identity 
checks to make sure it's got the right host) 

but such apps might still have v4 assumptions wired into them - 4 byte
addresses, etc.

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 10:19:53 -0400

> DHCP options for getting such tunnels configured.

yes you can, and this makes far more sense to me than using NAT-PT.  
in most cases tunneling seems far better than messing with DNS.

it would be interesting to see all of these scenarios compared side-by-side.

Keith

---

From: Suresh K Satapati <[email-masked]>
Date: Thu, 26 Sep 2002 09:24:05 -0700 (PDT)

>                          addresses for any A records.

DNS-ALG does this. resolver code does not have to chang in NAT-PT case

>                  resolver on each host, or to the server), and the IPv4

both NAT and NAT-PT do not involve any changes to DNS resolver/server

> Are there some other technical advantages to the NAT-PT solution that I

technically, network has IPv6-only traffic. router either runs dual-stack+v4NAT
or dual-stack+NAT-PT; both may not be equal in terms of complexity, as Erik
already mentioned the ALG factor which is more in v4NAT today than in
NAT-PT.

there are clearly operational advantages, as mentioned already by folks.

> and that they shouldn't send IPv4 traffic?

the problem here is dual-stack behavior is not clear. i tend to think they
would try to resolve using a AAAA first and then A, there might be
implementations that are doing A first, then AAAA

there is a problem for dual-stacks that are behind a NAT-PT, which i will
come to later.

> are the key differences, if any?

no differences.

> that all of those applications will work properly in the NAT-PT case?

as i said, no DNS modifications are needed. just like in v4NAT, one would
point host resolver to a NAT-PT box. apps will work as they were with
v4NAT, as long as ALG support is there with NAT-PT

> Who has explored this in detail, and what did you find?

while Alain did explore this, there are solutions to overcome most
problems that Alain pointed out except DNS-SEC.

Now the dual-stack problem: with NAT-PT, dual-stack will always be forced
to use a IPv6-mapped address (translation path) that the DNS-ALG
synthesized for a v4 destination. dual-stack could very well use IPv4 to
talk to the destination, but is forced to use IPv6+NAT-PT because of
DNS-ALG's current behavior. this is assuming dual-stack is sending AAAA
first, and then A; but not true for other cases.

-Suresh

---

From: Suresh K Satapati <[email-masked]>
Date: Thu, 26 Sep 2002 11:38:18 -0700 (PDT)

> which "mode" it should be using?

Node should not be aware of presence of NAT-PT.
It is entirely config dependent. If one chooses to point the resolver to a v4 DNS
server, for which it doesnt have to go through a NAT-PT, then the problem is solved.
On the other hand, one could still use a mapped address for the IPv6 DNS server,
which is reachable only through NAT-PT.

Comments ??

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 26 Sep 2002 11:41:30 -0700 (PDT)

> network, since it will just be replaced with translated IPv6 traffic?
You dont have to run IPv4 routing protocols along with IPv6 routing
protocols, which IMO, is an operational advantage.

Senthil

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 16:27:55 -0400

DNS-ALG and NAT-PT both change DNS results for some hosts, which breaks
apps that reasonably expect a consistent view of DNS.

don't use NAT brain-damage as an excuse to break DNS also.

---

From: Suresh K Satapati <[email-masked]>
Date: Thu, 26 Sep 2002 13:57:57 -0700 (PDT)

seems like people still have a hard time accepting the need of
NAT-PT/dns-alg; hopefully scenarios work will change that mindset.

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Sep 2002 18:02:46 -0400

> NAT-PT/dns-alg; hopefully scenarios work will change that mindset.

no doubt that there's some need for these things, but there's also a 
need for IPv6 to work better that IPv4+NAT.

the scenarios work should indeed help to make the relative needs clear.

---

From: Tim Chown <[email-masked]>
Date: Fri, 27 Sep 2002 00:07:00 +0100

> only one set of host-to-address bindings to deal with.

But are we in a position now to be able to monitor and manage a network over 
IPv6 only?  (I haven't yet seen much discussion of this in v6ops, as an 
operational issue, or does it belong elsewhere?)

Tim

---

From: Alain Durand <[email-masked]>
Date: Thu, 26 Sep 2002 18:10:26 -0700

> network, since it will just be replaced with translated IPv6 traffic?

This all thread is focussing at today's network.
Does it make any sense in _today's_networks_
to turn off private v4 and translate v6-only instead?
Maybe not.
Simple reason: what works and what does not work
is 99% the same, so no need to change for something
that is still unproven technology.

However, the real question is for network in the future.
Please, let's think for a minute at 5 or 10 years for now,
when IPv6 will be mainstream technology, but a lot
of the Internet is still IPv4 only.

Say that someone want to build a large network from scratch,
whre hosts usually communicates with each other but
need from time to time to communicate with IPv4 'things'.
Do you want to tell this person that he/she needs to also deploy
IPv4?

    - Alain.

---

From: [email-masked]
Date: Fri, 27 Sep 2002 13:26:44 +0900

>first, and then A; but not true for other cases.

	site -> outside:
	- if the site uses private IPv4 addrss and IPv4 NAT, it doesn't really
	  matter if we use NAT-PT or IPv4 NAT.
	within site
	- DNS-ALG needs to be clever when returning synthesized AAAA address
	  for NAT-PT.  for instance, DNS-ALG could do the following when asked
	  for AAAA of foo.example.com:
		query AAAA for foo.example.com - it's not there
		query A for foo.example.com - it should be there (X)
		if X is within the site, return empty answer section with
			NOERROR (indicate that foo.example.com does not have
			AAAA, and invite client to use IPv4)
		if X is outside the site, return synthesized AAAA record
			for NAT-PT translation.

itojun

---

From: [email-masked]
Date: Fri, 27 Sep 2002 13:34:09 +0900

>Node should not be aware of presence of NAT-PT.

	can't agree more.

itojun

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 00:54:20 -0400

> >Node should not be aware of presence of NAT-PT.

not clear to me; if NAT-PT affects how apps work, maybe they
need to know it's there so they don't make bogus assumptions.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 00:56:49 -0400

>  for instance, DNS-ALG could do the following when asked

synthesized AAAA records should be forbidden.  they make apps think they
have a transparent v6 connection when they don't.

Keith

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 26 Sep 2002 22:20:57 -0700 (PDT)

> 	  matter if we use NAT-PT or IPv4 NAT.

The ALG support on NAT vs NAT-PT would be the difference.

> 			AAAA, and invite client to use IPv4)

How do you determine if X is within the site or outside?

Senthil

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 26 Sep 2002 22:31:33 -0700 (PDT)

> need to know it's there so they don't make bogus assumptions.
One of the projected advantages of NAT-PT is that you dont have to change
the end hosts/apps. You are now suggesting the exact opposite.

Senthil

---

From: [email-masked]
Date: Fri, 27 Sep 2002 14:48:10 +0900

>How do you determine if X is within the site or outside?

	NAT-PT device usually reside at the site border, so you can configure
	what's inside (like 10.0.0.0/8) and what's not.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Sep 2002 08:48:17 +0300 (EEST)

> operational issue, or does it belong elsewhere?)

Depends on what you want to use it for.  At least some router vendors 
already support:

- DNS queries over IPv6
- SSH/telnet over IPv6
- SNMP over IPv6 (I've personally used this too.)
- IPv4 over IPv6 tunnels
- (I'm not aware of the implementation status of Tacacs/Radius situation,
if used, but that could be one element)

So at least most components We've found useful are there.  Not in all the 
implementations, of course.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 06:59:45 -0400

> the end hosts/apps. You are now suggesting the exact opposite.

it wasn't true for NAT; it isn't true for NAT-PT either.
NAT lets you get away without changing *some* hosts/apps;
for the rest operation becomes considerably more difficult.

and for many the whole point of IPv6 is to get away from NAT.

---

From: Steve Deering <[email-masked]>
Date: Fri, 27 Sep 2002 07:48:43 -0700

I agree with Alain: the domain of applicability of NAT-PT (or other
translation approach) is not so much networks/devices that are today
running IPv4, but rather new kinds of networks/devices for which
(for whatever reason) it is undesirable to run both IPv4 and IPv6
in parallel, while still needing some applications to work between
IPv6-only devices and the existing IPv4 Internet.  Examples *might*
be low-cost wireless devices, where dollar- or power-cost of memory
to hold two IP implementations might be the dominant concern, or
the military's "wired warfighter" with his or her body-area network
of IPv6-enabled sensors and weapons, linked into its environment
with IPv6-specific autoconfiguration and ad-hoc routing protocols
(but still needing access to the IPv4 world for some apps, like
email to home).

The specific scenarios where I've found myself suggesting NAT-PT
recently are:

	- for customers who are planning 3G wireless networks,
	  where it is still unclear whether the handset vendors will
	  be producing IPv6-only handsets, or just dual-stack ones.
	  The NAT-PT comes into play only the case of v6-only
	  handsets.

	- for customers who are IPv6 True Believers, whose motivations
	  for deploying IPv6-only hosts and/or networks go beyond just
	  finding the easiest way to add IPv6 to an existing IPv4
	  environment.

And as Alain said, at some point we may reach the stage that some
regular ol' residential and corporate networks are be easier to run
IPv6-only, whether because of strategic choices made by OS-vendors
or specific technical benefits of IPv6 (e.g., being able to get rid
of DHCP servers or whatever).  Translators may become the preferred
way for such networks to maintain access to the v4 world (access that
is no better or worse than what they would get through an IPv4 NAT).

Steve