Factors, actions influencing the possibility/timing of IDR for IPv6-basedrouting domains?

[Anthony Roberts]

Good point. I don't think all v6 hosts are getting Google's AAAAs yet, but
I imagine that's going to improve with time as v6 networks become better
connected with each other.

I've been following the BEHAVE NAT64 mailing list -- they've now got a
draft to allow hosts to learn the NAT64 translation prefix and take
appropriate action internally for situations like this where DNS
translation can't occur. Google cache links aren't the only use case that
may be impacted. That won't work for "legacy" v6 hosts that don't support
this, but moving forward at least there's a better developed set of tools
to mitigate these sorts of issues. "Foo is broken in v6" is much worse than
"You need Windows N+1 SP2 to use foo in v6".

-Anthony

On Wed, 24 Jun 2009 15:13:01 -0700, Erik Kline <ek at google.com> wrote:
>> The thing I find encouraging are the NAT64 drafts, as they explicitly
>> acknowledge and address the fact that v4 may be with us for some time to
>> come. That may cause a problem for Google cache links though; you'll see
>> v4
>> connections, and send back links with v4 IPs, but the clients will be
>> relying on DNS translation that won't happen for web links with raw IPs.
>> Good times. :)
> 
> I'm not sure of this being a real problem, at least not the situation
> you describe.  In your example a client has IPv6-only, and gets to
> IPv4 via NAT64 at some point in the network path.  I think in this
> scenario we would just serve AAAAs to these IPv6-only networks and
> side-step the whole issue.