Re: [v4v6interim] The NAT64 prefix

On 2008-10-03 01:13, Arifumi Matsumoto wrote:
>>>
>> I don't see how you get from what I said to what you said...
>>
>> But now that you bring it up: the reason to make sure fake AAAA
>> records aren't generated when real AAAA records exist is that we don't
>> want to have the situation where a host uses translated connectivity
>> if there's also native connectivity.
>>
>> However, if the address selection rules work well enough it MAY be
>> useful to present both a native address and an address that will go
>> through a translator to the application so that if the native address
>> doesn't work the app can try the translated address. However, we know
>> there are hosts out there today that don't implement RFC 3484 fully
>> (at all?) (i.e., Macs) so generating fake AAAA records where real ones
>> exist in a DNS64 (-like) box is a very bad idea.
> 
> I agree with you most of the parts, but let me comment on this point.
> 
> Regardless of the existence of RFC 3484 non-compatible hosts, replying a
> synthesis AAAA with a genuine AAAA should be an operator's choice ? As
> far as there is some benefit, such as fault-tolerance, to have these two
> AAAA records, and we don't have strong motivation to prohibit it
> universally, it's better to leave this decision up to an operator of the
> site or the translator box.

There's also the rather strange case where the genuine AAAA record leads
to a routing black hole, and the synthetic AAAA leads to a working
translator. Although that should not happen, it *will* happen during
the early years of IPv6 deployment.

    Brian
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim