Thoughts about ipv6 white listing

Jeroen Massar jeroen at
Sat Dec 4 18:46:46 CET 2010

On 2010-12-04 18:32, Andrew Yourtchenko wrote:
> Hi,
> On Sat, Dec 4, 2010 at 4:26 PM, Gert Doering <gert at> wrote:
>> Hi,
>> On Sat, Dec 04, 2010 at 03:36:14AM -0800, George Bonser wrote:
>>> If an AAAA record request arrives by v6, at least I know that both
>>> the client *and* the dns server have v6
>> This seems to be the fundamental mistake.
>> If an AAAA request arrives by v6, all you know is "the client asked for
>> AAAA, and the recursor has v6".
>> You don't know *anything* about the availability and/or brokenness of
>> v6 at the client end.
> To add to Gert's comment: I've done a quick test on my Win7 PC and
> when I attach to the subnet without IPv6, Chrome does not ask for the
> AAAA at - it's not on the wire - so at least for some values of
> "availability of IPv6" and some applications the assumption holds.

Windows (Seven at least) seems to have other tricks on top of RFC3484
like only asking for AAAA when the interface that that DNS server is
specified for has an IPv6 address.

Thus if you have an IPv4 DNS server on one interface with only an IPv4
address and you have a separate interface with an IPv6 address, even
though you have probably perfectly working connectivity it will not ask
for an AAAA.

Guess what is the case a lot with IPv6 tunnels....

> On the other hand the above also means that *if* the client does not
> have IPv6 address, then it *will not* request AAAA to begin with.

Which is quite okay in most cases, though sometimes you just want to see
the IPv6 address even though you might not have connectivity (or have
perfectly working connectivity over another interface).

Some people are therefor "advising" adding a /128 to the IPv4 only
interface, that way Windows thinks "hey I have an IPv6 address" and
suddenly it does AAAA queries.

> All the failures I've debugged recently involved the host having a
> [non-link-local] IPv6 address, and either a routing or PMTUD or some
> more exotic blackholes (FWIW for completeness: an ancient version of
> IOS with CBAC not understanding TCP window scaling but trying to
> enforce the window) - this proposal helps with none of them.

Yep, and that is the fun, you can't solve any of this at the server side.


More information about the ipv6-ops mailing list