[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on NAT-PT


itojun@iijlab.net wrote:
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. 
And all application that rely on DNS... regardless of the destination.


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


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

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

   - Alain.