[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: on NAT-PT
Jun-ichiro itojun Hagino wrote:
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.
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.
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.
existing NAT-PT product (like from Yokogawa) is much more robust than
what you are proposing.
Nice commercial advertizing.
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.
Also very bad, this breaks DNSsec.
- Alain.