Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

From: Ray Hunter <[email-masked]>
Date: Fri, 06 May 2011 10:39:08 +0200

Thanks for the reply.

Yes I had thought of structured replies and tracking people via logs 
(which is questionable in some jurisdictions without their consent) and 
statistical multiplexing. Maybe my understanding of "trivial" is 
different from other people's.

And I agree that you can certainly get a "general" view of IPv6 readiness.

But it's all about making  clever assumptions leading to conclusions 
without ever asking directly the communication partner what they've 
actually done in their migration.

So I'm still to be convinced that Party X can get enough granularity 
through Party X's one sided and uncoordinated action of trying to guess 
what Party Y is doing without ever actually asking Party Y, so that 
Party X can generate enough confidence in their actions that Party X is 
not actually causing Party Y harm.

I'm not yet convinced that there's enough large scale operational 
experience out there of how people are going to migrate that we can draw 
these conclusions about DNS being orthogonal to transport connectivity 
or not, which is why building solutions on architectural links that 
don't actually exist may be so dangerous.

Even if my authoritative DNS only replies 50% of the time at a latency 
of 3s, because the result is then cached locally, that may have very 
little adverse effect on my users' perceived transport quality to my 
site, depending on the application.

Philip Homburg has already posted that he uses a resolver in another net 
block, so he does not receive IPv6 records. I do too. Maybe this will 
become the "new normal" that the providers of IPv6 transport and DNS 
resolution are not strongly operationally coupled (because there is no 
architectural requirement to do so) Who really knows yet?

Which is why my original posting suggested that the WG might wish to 
express a concern about anyone making assumptions about any undocumented 
architectural links between DNS and transport, and also suggest that 
operators of aaaa whitelists (party X) should disclose their aaaa 
methodology and data, and that they should not share whitelist data with 
other aaaa operators in an uncontrolled manner, so that at least Party Y 
could see what was happening and why, and also have a chance of 
correcting it.

I know a lot of people get paid by traffic volume. Traffic volumes are 
not always a good indicator of traffic importance. In most companies, 
the monthly payroll batch run is still the most important job, even 
though it is also probably "trivial" and consumes very few bytes on the 
network. I'm sure the CFO would rather that the payroll ran properly, 
than that his staff could watch videos. Often times in computing 
"importance" is actually proportional to the inverse to the volume.

So I am also concerned that we also do not make the assumption that 
"IPv6 readiness" equates to people's ability to access the biggest video 
site on the Internet. Which may actually happen if other site operators 
copy that site's aaaa whitelist policy blindly. Yes, that is an 
important source of income for a lot of operators, but there are also a 
lot of other applications and "important" content out there.

Another viable alternative to deal with broken IPv6 connectivity would 
be simply to ask users or fellow ISP's to express a preference per net 
block whether they wanted their content delivered via IPv6 or IPv4 (with 
the default being filled in automatically), and then implement this in 
the existing geographical DNS response systems. IMHO the Internet 
community is generally a pretty friendly place.

Again no provocation or flames, just pointing out the dangers of making 
assumptions in complex systems, and sometimes trying to be too clever.

regards,
RayH

>
>
> Ray,
> On Thu, 2011-05-05 at 17:54 +0200, Ray Hunter wrote:
>    
>> >  I'm sure you can track back to the set of (recursive) DNS servers that
>> >  have contacted your authoritative DNS over a period of time, plus how
>> >  they connected you, but can you track all the way back to the
>> >  individual hosts / DNS client resolver libraries that are querying
>> >  those recursive DNS servers?
>> >  
>> >  That's partially my concern: how do you know where I've pointed my
>> >  local resolver lib on my end hosts, compared to my next door neighbor,
>> >  who may have broken IPv6 connectivity and/or a broken IPv6 DNS
>> >  resolution?
>>      
>
> Seeing how Erik did not yet reply to this (and assuming he does not
> intend to), I'd just like to offer a plausible explanation from a
> general computer engineering perspective:
>
> Assuming:
>   1) you have a way to track user sessions or users,
>   2) you have a way to log DNS queries and additionally setup mappings
> for special queries, like those some IPv6 test sites famously does
> (unique records per test/user/session),
>   3) you have a way to connect the session/user driving code in 1 to
> generate certain specific records in 2, OR, you have some even more
> intelligent log parsing algorithms and some prepared/algorithmic unique
> record response scheme,
>
> you should be able to with quite high confidentiality build a map of
> this relationship.  You don't have to hit every user on every hit,
> either, you can add some statistical mumbu jumbo:)  in it to arrive at
> results within a certain confidence interval.
>
> The above is just what seems obvious to me.  Takes a non-trivial amount
> of supporting system code, especially for a larger system, but even at
> least one of these test-IPv6 sites managed to do it, presumably with a
> lot less backing resources and less code.
>
> It will probably not fingerprint what resolver library you use (though
> that seems like a research field in itself), and may only give a more
> generalized / aggregate view of the (subnet:resolver):ipv6-score
> mappings.  But this information is surely telling more about the general
> quality of a ISPs IPv6-readiness, than no such information at all.
>
> Best,
> Martin
>
>
>

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 May 2011 22:39:19 +0200

In your letter dated Fri, 06 May 2011 10:39:08 +0200 you wrote:
>architectural links between DNS and transport, 

Very curious in this case is that Google also provides a public DNS resolver.
So, where their IPv6 whitelisting depends on a connection between the 
resolver and the user's IPv6 capabilities, at the same time, they promote a
de-coupling between users netblocks and the DNS resolvers they use.

Coming back to my use of a DNS resolver in a different netblock. The main
reason is the limited number of IPv4 addresses provided with consumer DSL
connection (i.e., just one). For IPv6 that is not an issue. But apparently,
the line of reasoning that led Google to implementing DNS whitelisting also
led to a lack of IPv6 glue for their domains.

So, for the hypothetical user with good IPv6 connectivity and poor IPv4
connectivity, even if he can get his resolver whitelisted, he still has to
go over IPv4 to get those AAAA records.

Just a thought. I wonder if people will start running public DNS resolvers
that are hand populated with the IPv6 addresses of popular sites that employ
DNS whitelisting. Sounds like a useful service.