Re: on NAT-PT

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

>>>> 	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),
>>> It could be a well know prefix. You won't have to configure a special
>>> prefix for that.
>> 	that's much more sick.
>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