Subject: RE: on NAT-PT

From: "Christian Huitema" <[email-masked]>
Date: Wed, 4 Dec 2002 18:50:15 -0800

> >An IPv6 host doesn't have to be dead. If it has a piece of logic that
> >combines a "nat-pt prefix" with the IPv4 destination address, then it
> >can send the packet over IPv6 to that fabricated destination, and
rely
> >on the NAT-PT to do the translation job.
> 
> 	it seems to me that modifying an IPv6 host for transition
purposes
> 	is not an option.  basically it makes IPv6 hosts aware of NAT-PT
(or
> 	whatever) translation in the middle, hence similar to RSIP
model.

I don't believe we should have a black-and-white attitude regarding
this. I don't think that hosts developers can ignore that a transition
is going on, at least during the next few years. Clearly, the best way
for a host to support the transition is to be simply dual stack. Do you
want to preclude hosts taking an in-between position, i.e. not
dual-stack but still nat-pt aware? 

-- Christian Huitema

---

From: [email-masked]
Date: Thu, 05 Dec 2002 11:57:49 +0900

>>it seems to me that modifying an IPv6 host for transition purposes
>>is not an option.  basically it makes IPv6 hosts aware of NAT-PT (or
>>whatever) translation in the middle, hence similar to RSIP model.
>dual-stack but still nat-pt aware?=20

	that describes my position - "NAT-PT/whatever aware" node is not
	an option.  it might look okay as shortterm workaround but will hurt
	us in the future.

	FYI, we have been there already - KAME DNS resolver code had an
	environment variable for setting address-translation prefix on the
	client side, we noticed that it is a bad thing, and it got removed.
	so this is from actual operational experience.

itojun

---

From: Alain Durand <[email-masked]>
Date: Mon, 09 Dec 2002 10:45:05 -0800

>	so this is from actual operational experience.
Is there any paper documenting this 'operational practice'
and why you consider it a 'bad thing' ?
I would like to understand better why you claim that it is 'universally'
a bad thing and not just 'a bad thing' within your local environment.

    - Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 10 Dec 2002 08:08:13 +0900

>a bad thing and not just 'a bad thing' within your local environment.

	unfortunately there's no documentation.
	this is universally bad because
	(1) it requires every node to configure the translation prefix manually
	(kills spirit of autoconfigured hosts), or to cook up DHCPv6 option for
	it (horrid idea),
	(2) NAT or NAT-PT has to be invisible to the client, instead of
	explicitly visible (otherwise, why bother rewriting protocol contents?),
	and
	(3) the idea where client is aware of things that happen in the middle
	is exactly the same as RSIP.

	our changelog shows that the feature (to specify translation prefix
	via environment variable, which in turn controls getaddrinfo(3)) was
	dropped in January 2000.
	
itojun

Sun Jan 23 13:24:00 JST 2000  [email-masked]
	* kame/libinet6/getaddrinfo.c: remove #ifdef FAITH (and use of
	  environment varaible GAI).  this has been broken for a long time
	  (means noone is using it), and this shouldn't be here.
	  if you would like to set FAITH'ed prefix, use totd or /etc/hosts.

---

From: Alain Durand <[email-masked]>
Date: Mon, 09 Dec 2002 15:26:18 -0800

>	(kills spirit of autoconfigured hosts), or to cook up DHCPv6 option for
It could be a well know prefix. You won't have to configure a special 
prefix for that.

>	explicitly visible (otherwise, why bother rewriting protocol contents?),
I do no think so, au contraire. This is a last resort to enable 
IPv6-only apps
on Ipv6-only node to communicate with their Ipv4 only peers.
Requiring such nodes (or apps?) to have special knowledge that something
is needed to "bridge" to the other world does not seems unreasonable to me.
This is what we mean by "IPv6 nodes will have to pay the burden of the 
transition".

>	is exactly the same as RSIP.
You'll be aware that things will happen. You will not have
to negotiate it, and that makes a big difference.

>	via environment variable, which in turn controls getaddrinfo(3)) was
You can always put it back in ;-) Remember, this is for IPv6-only nodes,
the kind that is not yet largely deployed.

    - Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 10 Dec 2002 22:54:20 +0900

>It could be a well know prefix. You won't have to configure a special 

	that's much more sick.

>You can always put it back in ;-)

	i don't think so.

>Remember, this is for IPv6-only nodes,

	it also applies to IPv6/v4 dual stack nodes with IPv4 not configured.

itojun

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Dec 2002 09:20:30 -0800

On Tuesday, December 10, 2002, at 05:54 AM, Jun-ichiro itojun Hagino 

>> It could be a well know prefix. You won't have to configure a special
Could you please elaborate why?

	- Alain.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Dec 2002 14:07:47 +0900

>Could you please elaborate why?

	the failure mode with your proposal is a disaster.  what happens if
	your site do not provide IPv6-to-IPv4 translation with the hardcoded
	prefix?  your IPv6-only machine will try to connect to non-existent
	prefix, and the packet will travel to somewhere unknown.
	and with your plan, it seems that you are planning to reuse the same
	prefix in multiple locations (at least in different sites, and could be
	multiple locations within a site).  it will lead to unstable
	translation service as routing to the hardcoded prefix can flap and
	the packet to hardcoded prefix can reach a different translation box,
	the other translation box does not have the state info for the
	traffic, and the connection will be killed.

	existing NAT-PT product (like from Yokogawa) is much more robust than
	what you are proposing.
	DNS-ALG box and NAT-PT translation box are separate.  each of the
	NAT-PT translation box T1, T2, ... Tn are configured with certain
	(seaprate) IPv6 prefixes for each, P1, P2, .. Pn.  DNS-ALG box
	monitors which NAT-PT translation boxes are alive.  DNS-ALG will return
	fabricated AAAA response (for actual A response from the outside DNS
	authoritative server) using prefix Pi, when Ti is alive (it does not
	return AAAA with Pj if Tj is dead).

itojun

---

From: Alain Durand <[email-masked]>
Date: Thu, 19 Dec 2002 13:37:28 -0800

>	prefix, and the packet will travel to somewhere unknown.
This prefix would have to be non globally routable
and should be filtered out at site boundary to avoid this issue.
This is not something catastrophic.

Actually, this is very similar to what you, Dave Thaler and I are proposing
for DNS stub resolver configuration.

>	traffic, and the connection will be killed.
Yes, but the next one will succeed. I think of this as a good property,
as in case of failure, not everything is lost, just current connections.

>	existing NAT-PT product (like from Yokogawa) is much more robust than
Nice commercial advertizing.

>	return AAAA with Pj if Tj is dead).
So what happens if a host has started a communication using Pi/Ti
and Ti goes down? The communication dies and each subsequent
communications to the same destination fail until the DNS
cache on the host is flushed. This is a much worse failure mode
than the one discussed above.

Also very bad, this breaks DNSsec.

    - Alain.

---

From: [email-masked]
Date: Fri, 20 Dec 2002 09:29:04 +0900

>for DNS stub resolver configuration.

	with DNS stub resolver configuration, only DNS resolver will be
	affected.  what you are proposing here will affect every application
	that use DNS resolver (since the DNS resolver attaches magic prefix
	to all the responsees from DNS).  there's big difference.

>as in case of failure, not everything is lost, just current connections.

	what is the "next one" in your text above?  i was not talking about
	a connection attempt, but an existing TCP connection suddenly shut down
	by routing changes.

>Nice commercial advertizing.

	what's wrong with you?  what is wrong in stating the state of the
	implementation exist in the real world?  just to be clear, i have no
	commercial relationship whatsoever with yokogawa.

	if i see you mention any name of product in the future discussion,
	everyone will know how your way of discussion is unfair.

>than the one discussed above.

	yes, if Ti goes down, connections that went through Ti will go down.
	however, many of the host resolver implementation do not cache DNS
	responses (luckily for translators, unluckily for DNS), so the next
	connection attempt will use something other than Ti.

	if you attack NAT-PT on this point, your proposal must have no state
	at all in your translation boxes.  from seeing NAT64 proposal i don't
	think it true.  if you are not talking about NAT64, go back to your
	cube and write a draft, then discuss.

>Also very bad, this breaks DNSsec.

	(i think i have repeated this too many times)
	when you rely on intermediate device which rewrites your packet,
	what kind of protection do DNSsec really provide?  and when you
	fabricate address by attaching some hardcoded prefix onto the value
	returned from DNSsec?
	with the lack of deployment of DNSsec, and the likelihood of
	deployment is so low, i don't think your popular claim "it breaks
	DNSsec" is realistic.

itojun

---

From: Alain Durand <[email-masked]>
Date: Fri, 20 Dec 2002 11:14:25 -0800

[email-masked] wrote:

>	affected. 
And all application that rely on DNS... regardless of the destination.

> what you are proposing here will affect every application
It only affecst v6-only applications on v6-only nodes that
want to sent packet to v4-only nodes. Regular communication
with IPv6 hosts is not affected.

>	a connection attempt, but an existing TCP connection suddenly shut down
I think we are concerned about different things.
You express concerns about maintening an existing connection
in the event of a NAT box failure,
I'm concerned about mainteting 'usability of the Internet'
in the event of this failure. Many connections in the Internet
are short lived or can be easily restarted.
Example: in typical Web browsing usage, connections are very short.
To load a particular page, usually there are several connections
happening under the hood. If one fails, that's no big deal,
maibe a picture or an icon will not display and the user
will do 'refresh'. If we can make sure that when
the user does 'refresh', this new connection actually
works, I think we would have achieved a reasonable
level of reliability.

>	connection attempt will use something other than Ti.
This is not true for every implementation. In particular, ours does cache.
I do not think it is a good think to build a protocol based on the 
assumption
that DNS stub resolvers are stupid and do not cache.

>	at all in your translation boxes.
>
I disagree. Re-read my paragraph about web browsing.
Stateless is always better, but if we need to introduce state,
we have to make sure that we mimimalized the impact in
case of problem.

NAT-PT DNS-alg as you describe introduces state
in the stub resolver on a per-name resolution basis.
Even if the stun resolver does not cache, the application
that ask for the resolution may very well do.

Using a well know prefix (a la NAT64, but not necessarily ::ffff:0:0)
put state in the NAT box on a per-connection basis.
If the box fails, current connections are trashed, but new
ones can be routed to a new box.

>	(i think i have repeated this too many times)
I repeat it because it is true.

>	what kind of protection do DNSsec really provide? 
>
Using NAT-PT DNS ALG, the node does not know it is using
NAT, so it cannot differentiate DNSsec does not work because
I'm behind NAT-PT from DNSsec tells me something fishy
happened. Remember, DNSsec will still work fine for 'regular'
IPv6 name to address translation for regular IPv6 addresses.

> and when you
DNSsec signature can still be checked in the stub resolver
before the wkn prefix is attached.

>	deployment is so low, i don't think your popular claim "it breaks
How can you make such a public statement! How can you say publically
we are deploying IPv6 and do not care about DNSsec!
This makes no sense to me...

    - Alain.

---

From: [email-masked]
Date: Tue, 24 Dec 2002 11:25:52 +0900

so you don't apologize for attacking me on "product advertisement"?
	how nice.

>with IPv6 hosts is not affected.

	even though it is for limited scope, what you are proposing is harmful.

>works, I think we would have achieved a reasonable

	i'm not convinced at all with your argument on TCP lifetime (that
	TCP lifetime is short and it is okay to terminate one as people will
	re-connect).  translators cannot make assumptions on TCP lifetime.
	even if you are proposing it for HTTP-only translators, i object -
	starting HTTP/1.1 they reuse TCP connection for multiple HTTP requests
	and you can't assume that the TCP lifetime is short.

>assumption that DNS stub resolvers are stupid and do not cache.

	DNS-ALG can respond with shorter DNS TTL for fabricated responses
	to minimize the impact to resolvers that perform caches, in case of
	failure in one of the translator boxes.

>ones can be routed to a new box.

	i disagree with the above.  see below.  what you are proposing is RSIP.

	on TCP lifetime discussion, see above (about 40 lines before).

>IPv6 name to address translation for regular IPv6 addresses.

	the nodes MUST NOT know that there is a middlebox.  never.  if the end
	nodes has to be aware of middleboxes, it's not IP.  it's called RSIP.
	this is why i have been objecting your idea to alter resolver in the
	end nodes.

>before the wkn prefix is attached.

	you have been ignoring my comment (i made this comment months ago)
	to use "AD is secure" for the response from DNS-ALG.

>This makes no sense to me...

	this is a operational group.  you need to face the operational reality,
	instead of acting as an armchair detective.

itojun