Re: on NAT-PT

[itojun@iijlab.net]

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

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

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

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

	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.

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

	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.

>>	if you attack NAT-PT on this point, your proposal must have no state
>>	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 disagree with the above.  see below.  what you are proposing is RSIP.

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

>>>Also very bad, this breaks DNSsec.
>>	(i think i have repeated this too many times)
>I repeat it because it is true.
>>	when you rely on intermediate device which rewrites your packet,
>>	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

	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.

>>	fabricate address by attaching some hardcoded prefix onto the value
>>	returned from DNSsec?
>DNSsec signature can still be checked in the stub resolver
>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.

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

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

itojun