Re: on NAT-PT

[itojun@iijlab.net]

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

	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.

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

>>	existing NAT-PT product (like from Yokogawa) is much more robust than
>>	what you are proposing.
>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.

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

	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