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

From: Ray Hunter <[email-masked]>
Date: Thu, 05 May 2011 14:39:50 +0200

I'm guessing comments are welcome again now for input to the revised ID 
now that the status is "Revised ID Needed" (according to RFC6174) Or 
should I be waiting for the revised ID first before commenting further? 
I dunno. I still admit to getting confused by the status on the 
http://tools.ietf.org/wg/v6ops tooling page even after having read the 
finite state machine a couple of times. Maybe that should disqualify me 
from taking part in the WG ;)

Anyway, firstly, I can imagine that the actions of a single aaaa 
whitelisting provider can have far reaching consequences for many 
parties on the Internet.

Say "Content Provider G" adds your ISP's DNS resolvers and suddenly a 
huge proportion of the ISP's traffic switches to IPv6. Vice versa is 
also true if traffic is routed away from IPv6. It may even take a 
different path through the transit providers' networks (if they are not 
all offering dual native transport) and thus also have financial 
consequences.

Meanwhile if you're in the ISP network, you really can't debug anything 
meaningfully because you might be receiving a different response to 
someone else who has a problem, and you have no idea why. Even if you do 
debug the problem correctly, and correct your local issues, you have 
very little control over full problem resolution (by getting the aaaa 
whitelist contents changed).

That means my first conclusion is that I feel v6ops WG should attempt to 
reach some consensus on a revised I-D, and at least comment on the 
operational aspects, rather than just let the current draft lapse.

Secondly, Is the scope and function of the document clear?

That seemed to confuse some members of the IESG if I read their feedback.

Is it too early to talk about Solutions?

Maybe the revised I-D should simply stick to the target defined in the 
text already present on page 5:

"This document explores the reasons and motivations for DNS 
whitelisting. It also explores the outlined concerns regarding this   
practice. Readers will hopefully better understand what DNS whitelisting 
is, why some parties are implementing it, and what   criticisms of the 
practice exist." with the addition that "It is intended to address best 
current practice and solutions in a follow up."

And then leave all discussion of "Solutions" to a BCP follow up RFC?

I suspect it would probably be easier to reach consensus for an 
informational "description and concerns of current practice" without 
immediately taking the next step and marking that description as "best 
current practice" or proposing "solutions" to the concerns. Yes I know 
the first document won't change anything, but at least it is a clear 
problem statement for people to tackle and to generate possibly many 
alternative options for follow-up.

Thirdly, as has already been pointed out in the description of the 
"current practice", the relationship between IPv6 name resolution and 
IPv6 connectivity appears tenuous to me, although others have commented 
that they have observed a causal link.

Is there any hard data on this?

Thinking off the top of my head:

There are off site / off net back up recursive resolvers just to mention 
one basic level of obfuscation.

There are open recursive resolvers. Here's a survey of open recursive 
resolvers that potentially serve people "outside" of their own network 
http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html 
10000 of them in the latest survey. These would almost certainly break a 
link between resolver performance and network connectivity.

Looking closer to home, my own authoritative DNS is not located on my 
ISP's DNS. I want to be able to change transport provider (big cost and 
low hassle for me) in a smooth manner, without having to change DNS 
provider (small cost, but big hassle for me). I also currently use a 
different recursive resolver for outbound requests (IPv6 capable via a 
tunnel) than my IPv4 transport provider (not IPv6 capable).

This aaaa whitelisting practice as described appears to create a direct 
link between DNS recursive resolution services and IPv6 transport 
provider services that has not existed up until now IMHO.

That should probably be noted as an architectural concern of the WG. It 
is hinted at within the existing text: "An additional concern is that 
the IP address of a recursive resolver is not a precise indicator of the 
IPv6 preparedness, or lack of IPv6-related impairments, of end user 
hosts which query (use) a particular recursive resolver."

But that text does not address the concern at any architectural level 
whether there should be _any_ link at all between an IPv6 transport 
provider and DNS recursive resolver server address, never mind if it is 
a reliable link.

RFC5358 suggest it was Best Current Practice in 2008 to avoid open 
recursive resolvers to avoid reflector attacks, but it does not directly 
link DNS resolution and transport service provision. It just says "The 
generic recommendation to nameserver operators is to use the means 
provided by the implementation of choice to provide recursive name 
lookup service to only the intended clients." One suggested method was 
IP filtering, another was DNS-tsig, which is certainly a real 
possibility. But the intended clients for DNS were certainly not limited 
to only those using a particular transport provider.

Has this concern therefore been properly documented?

Fourthly, moving on to possible suggestions for solutions and BCP, it is 
very clear that there is a real issue with the lack of transparency on 
the whole aaaa whitelisting process. As others have already commented, 
it seems very opaque.

In order to facilitate troubleshooting, and to give people a chance to 
control their own destiny (regardless of the aaaa whitelisting 
technology employed) can the v6ops WG take a view that DNS server 
operators who employ aaaa whitelisting SHOULD:
1. publish their policy for maintaining the aaaa whitelist
2. provide details for how and where the aaaa whitelist is used
3. provide details of how to request the contents of the aaaa whitelist 
(taking into account privacy concerns)
4. provide details of how to request being included in the aaaa whitelist
5. provide details of how to request being excluded from the aaaa whitelist
6. provide details of how to request a review, appeal, or enter an 
arbitration process.
7. provide active feedback to the maintainers of DNS and IPv6 transport 
providers to improve overall IPv6 DNS resolution and IPv6 connectivity, 
in order to remove any underlying need for an aaaa whitelist, and to 
facilitate its complete removal at the earliest possible opportunity.

I miss these operational issues being addressed at all in the previous 
draft in the Solutions section. They're well covered in discussion 
relating to other (similar) lists e.g. DNSBL

So does the v6ops WG deprecate/discourage/condone/tolerate/encourage DNS 
whitelisting or blacklisting on the basis of "recursive resolver IP 
address" reachability/ reliability being linked to IPv6 transport 
reliability?

Doubt there'll be consensus here, but I think the question should be 
asked again.

To it seems that broken IPv6 connectivity is the real problem, not 
broken name resolution as far as I can see. Especially when it is 
possible to resolve both IPv4 and IPv6 records over either IPv4 or IPv6 
transport, I really fail to see the correlation. Perhaps someone can 
correct my myopia with hard data.

If someone has broken DNS recursive resolution for IPv6, it is going to 
affect the majority of the IPv6 services they are using, and should 
stand out like a sore thumb. They are therefore likely to be highly 
motivated to point their local resolver libs at a better DNS server, and 
which action is generally a fairly trivial act (altering one DHCP record 
at best and rebooting machines).

If there are generally large numbers of broken IPv6 DNS resolvers out 
there, then there's a much bigger problem, which is certainly not going 
to be solved by a point solution deployed by a few content providers. In 
fact aaaa whitelisting is more likely to mask the problem than solve it 
IMHO.

Again I sense a lack of hard operational data as to the root causes of 
the problem. Maybe that's also a basic concern to be noted: "lack of 
operational data regarding the root causes of the problem."

Also IMHO the v6ops WG also shouldn't encourage people to mess around 
with DNS unless it is absolutely necessary. Breaking DNS would break an 
awful lot, to put it mildly.

The current document notes the current practice of only deploying aaaa 
whitelisting on an authoritative server.

Should the v6ops WG clearly state in any recommendations or bcp that
1. aaaa whitelisting MUST NOT be deployed anywhere other than on an 
authoritative DNS server for which the aaaa whitelist provider is 
directly responsible.
2. aaaa whitleisting information SHOULD NOT be traded for use in aaaa 
whitelisting on other authoritative DNS servers, unless the aaaa 
whitelist policy of the two organisations is tightly coupled.
3. the adminisatrator of the authoritative DNS SHOULD ensure that all 
authoritative DNS servers for a domain return a consistent set of 
results, regardless of which server has been queried.
4. aaaa whitelisting is a transition mechanism that MAY be useful in 
supporting a move towards a fully native IPv6 network, but which SHOULD 
only be used where, and for as long, as is essential to maintain normal 
operations.

A few questions and issues for your consideration thus.

regards,
RayH

---

From: Erik Kline <[email-masked]>
Date: Thu, 5 May 2011 16:45:50 +0200

[Random responses without commentary on the draft at hand.]

> That should probably be noted as an architectural concern of the WG. It is
> hinted at within the existing text: "An additional concern is that the IP
> address of a recursive resolver is not a precise indicator of the IPv6
> preparedness, or lack of IPv6-related impairments, of end user hosts which
> query (use) a particular recursive resolver."

"Precise", no.  But very definitely quantifiable, to varying degrees
of accuracy.

> whether there should be _any_ link at all between an IPv6 transport provider
> and DNS recursive resolver server address, never mind if it is a reliable
> link.

It is trivial to build a map of client addresses and the resolvers
they use.  The connection is observable, whatever that connection may
be.

> To it seems that broken IPv6 connectivity is the real problem, not broken
> name resolution as far as I can see. Especially when it is possible to
> resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I
> really fail to see the correlation. Perhaps someone can correct my myopia
> with hard data.

Broken AAAA resolution can cause broken dualstack connectivity.  DNS
resolvers in home gateways have been variously observed to do things
like dropping any query that isn't for an A record, transform the high
32bits of an AAAA response and into an A response (Jason Fesler can
even test for this!), and even dropping all responses that are still
less than 512 bytes but have more than 16 address records.  And worse.

It's a pathological world out there, as I'm sure you well know.

> affect the majority of the IPv6 services they are using, and should stand
> out like a sore thumb. They are therefore likely to be highly motivated to
> point their local resolver libs at a better DNS server, and which action is
> generally a fairly trivial act (altering one DHCP record at best and
> rebooting machines).

Ahem...what IPv6 services are they using right now?  Seriously.

> If there are generally large numbers of broken IPv6 DNS resolvers out there,
> then there's a much bigger problem, which is certainly not going to be
> solved by a point solution deployed by a few content providers. In fact aaaa
> whitelisting is more likely to mask the problem than solve it IMHO.

The whitelisting is indeed designed to avoid the problems and allow
IPv6 to be more broadly served to those who are properly able to make
use of it.

But absolutely, breaking things does highlight that some things need
to be fixed, and sometimes some people can even identify what those
things are, and sometimes not.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 05 May 2011 17:54:15 +0200

Thanks very much for replying.

Comments in line.

> "Precise", no.  But very definitely quantifiable, to varying degrees
hmm potentially some confusion over precision and accuracy.

AFAIK Precision is whether a measurement is repeatable within a certain 
confidence range, irrespective of how true it is.
Accuracy is how close the overall measured result is to the actually 
true value.

Care to share operational data?

> they use.  The connection is observable, whatever that connection may
Really? Interesting.

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?

Especially if the recursive DNS name server for example has cached the 
response, how do you know who else has asked the same question from 
their local resolver lib to that recursive DNS name server, and you 
never ever even saw the query?

p34 of DNS and Bind With version 4.8 8 & 9 of BIND name servers even 
implement negative caching .... if the name server has cached the 
answer, positive or negative, it simply returns the answer to the resolver.

And what about DNS forwarders?

Equally, with widespread use of tunnels like 6in4 (or even dual 
transport providers) expected to be deployed in the transition to IPv6, 
how do you reliably correlate my IPv4 address with my IPv6 address? They 
may be 100% completely separate paths and providers, except for that 
very last hop from my IPv6 dual stack node to my site border router(s). 
There's plenty of discussion still on multihoming and how to transition. 
Many recommend contracting a separate link for IPv6. There's especially 
still a lot of ongoing discussion on how to handle DNS resolution in a 
multihomed/ transitioning World.

So I'd be very wary about making assumptions of relationships between 
IPv6 connectivity and DNS address resolution. YMMV.

> It's a pathological world out there, as I'm sure you well know.
Sure. And I think we're both trying to make it better. Completely 
disabling or crippling IPv6 DNS resolution is not going to make it any 
better. So it's just a question of how we make it better.
> Ahem...what IPv6 services are they using right now?  Seriously.
My company's web server, SSH, admin system, and SMTP mail service 
already run native IPv6 dual stack, without aaaa whitelisting.

This very mail was probably sent over IPv6 to the IETF's server (the 
inbound mail certainly was if I check my logs.)

If people have a problem with my IPv6 services, because of their broken 
service, I normally see it as their problem.

The transition to IPv6 will probably be painful. AAAA whitelisting will 
probably also be painful.

But I guess I have the luxury of not getting paid per click.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 May 2011 18:16:17 +0200

On Thu, May 5, 2011 at 5:54 PM, Ray Hunter <[email-masked]> wrote:

>  My company's web server, SSH, admin system, and SMTP mail service already
> run native IPv6 dual stack, without aaaa whitelisting.
>

I think that what Erik meant is that if you look at your favourite list of
most popular websites, you will find very few that are IPv6-enabled.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 May 2011 22:23:14 +0200

>Ahem...what IPv6 services are they using right now?  Seriously.

I'd like to point out that many gTLD and ccTLD zones do have IPv6 addresses in
their glue. And there don't seem many complaints about it.

Now, I think the real issue, which seems to be missing in the draft (at
least after a quick read of the draft), is what happens to people who have
good IPv6 connectivity and poor IPv4 connectivity.

I don't get IPv6 addresses for Google at work (not whitelisted) or at home
(the network is whitelisted but I use a resolver in another netblock). But
does it really matter? I have excellent IPv4 connectivity. And there are
plenty of smaller sites with IPv6 addresses to test IPv6.

So the people who are really going to be affected by (the lack of) whitelisting
are those with good IPv6 connectivity poor IPv4 connectivity. I'm not sure
that there many of those at the moment.

But when they come, it will be interesting to see what will happen. Many big
companies have a very poor track record communicating with small parties.
So it is quite possible to at some point a small ISP will find it 
impossible to get it's customers whitelisted. And that will be the moment
whitelisting really hurts the Internet.

---

From: Martin Millnert <[email-masked]>
Date: Thu, 05 May 2011 19:45:05 -0400

Ray,

On Thu, 2011-05-05 at 17:54 +0200, Ray Hunter wrote:
> 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: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 10:58:09 +1000

In message <[email-masked]>, Erik Kline wri
> It's a pathological world out there, as I'm sure you well know.

Yep, but even combined the number of those boxes are not enough to
require filtering.  There are also plenty of drop in replacements
available that do work or there are firmware updates that fix these
problems.

> Ahem...what IPv6 services are they using right now?  Seriously.

Actually more and more these days.

> IPv6 to be more broadly served to those who are properly able to make

And there are plenty that can use IPv6 but can't get AAAA records
due to whitelisting.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Fri, 6 May 2011 09:10:40 +0200

> And there are plenty that can use IPv6 but can't get AAAA records

I look forward to seeing your data that backs up this assertion.

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 May 2011 14:44:02 +0000

Philip – Thanks for the suggestion and I'll see if I can add something about this in the –04. One scenario I could imagine to cause good IPv6 / bad IPv4 is the ISP exhausts IPv4 addresses and starts doing something like NAT444, which degrades IPv4 performance, while giving out a /64 of IPv6 addresses (with good IPv6 connectivity).

Thanks
Jason

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 May 2011 17:33:48 +0000

Here's the draft text I am adding to address this in a new section (7.7). Let me know if you wish to see changes to this text (I've taken my best shot at it):

"7.7 Implications with Poor IPv4 and Good IPv6 Transport

It is possible that there could be situations where the differing quality of the IPv4 and IPv6 connectivity of an end user could cause complications in accessing content which is in a whitelisted domain, when the end user's recursive DNS resolver is not on that whitelist. While today most end users' IPv4 connectivity is typically superior to IPv6 connectivity (if such connectivity exists at all), there could be implications when the reverse is true and and end user has markedly superior IPv6 connectivity as compared to IPv4. This is admittedly theoretical but could become a factor as the transition to IPv6 continues and IPv4 address availability within networks becomes strained.

For example, in one possible scenario, a user is issued IPv6 addresses by their ISP and has a home network and devices or operating systems which fully support IPv6. As a result this theoretical user has very good IPv6 connectivity. However, this end user's ISP may have exhausted their available pool of unique IPv4 address, and so that ISP uses NAT in order to reuse IPv4 addresses. So for IPv4 content, the end user must send their IPv4 traffic through some additional network element (e.g. NAT, proxy, tunnel server). Use of this additional network element may cause the end user to experience sub-optimal IPv4 connectivity when certain protocols or applications are used. This user then has good IPv6 connectivity but impaired IPv4 connectivity. Furthermore, this end user's recursive DNS resolver is not whitelisted by the authoritative server for a domain that the user is trying to access, meaning the end user only gets A record responses for their impaired IPv4 transport rather than also AAAA record responses for their stable and well-performing IPv6 transport. Thus, the user's poor IPv4 connectivity situation is potentially exacerbated by not having access to a given domain's IPv6 content since they must use the address family with relatively poor performance."

Thank you
Jason

On 5/6/11 10:44 AM, "Livingood, Jason" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks
Jason

---

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

In your letter dated Fri, 6 May 2011 17:33:48 +0000 you wrote:
>It is possible that there could be situations where the differing quality o=
>f the IPv4 and IPv6 connectivity of an end user could cause complications i=
>n accessing content which is in a whitelisted domain, when the end user's r=
>ecursive DNS resolver is not on that whitelist. 

My main comment, and that applies to the entire document, is that the
text is very verbose. Reducing the amount of text by a factor of two seems
to be quite possible, and is likely to result in a much more readable
document.

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 7 May 2011 12:01:55 +0200

> I look forward to seeing your data that backs up this assertion.

I can guess there are quite some with decent IPv6 connectivity but their
ISP is not whitelisted.  The reason is probably (my guess) that the ISP
haven't yet got around to, or used resources on being whitelisted...

My home network happen to be one of these cases, my ISP has a fairly
good IPv6 network but no whitelisting for their resolvers.
Im so lucky to have my own NS servers and they happen to be in a
netblock (ipv4/ipv6) that happen to be whitelisted... only problem I've had
was some MTU issue that only affected loading of youtube video, after
adjusting MTU on the LAN side everything worked great:)

(that I might have to do tweaks, MTU or others, on my side is one downside
of IPv6 at the current stage all over really)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 10 May 2011 15:39:40 -0500

> > And there are plenty that can use IPv6 but can't get AAAA records

Our site would fall into this category (for small cases of "plenty").

Since some of our recursive servers are used by a diverse group of users 
in managed and unmanaged academic and residentual settings it is my 
understanding that it would be inappropriate to whitelist our servers 
because of the alleged brokenness of some amount of the hosts using those 
resolvers.

However, many of the hosts have native v6 service today but obviously
don't get AAAA responses from some large content sites that use
whitelisting.

For the sites doing whitelisting it would be benificial to the operator
community to have feedback as to what the percived brokenness would be
for a site if it were whitelisted.  Maybe IPv6-day will be a starting
point for that.

Dale

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 11 May 2011 17:39:35 +1000

Hi,

On 11 May 2011 06:39, Dale W. Carder <[email-masked]> wrote:

> ...

You should be able to measure brokenness of your users by adding a web bug
to the front page of a few of your own commonly visited sites
e.g. add
http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript
to  www.example.com  mail.example.com  portal.example.com ...
This will flag to users that they have problems.
Analysing the logs carefully should tell you who and how many work or have
problems.

Then dual-stack one of your own web servers.
Fix any user/network problems, dual-stack something else ... repeat

Is the USA academic year finishing about now?
Do disruptive changes after exams, and if the residences are empty, you can
get normal staff happy
before having to worry about residences.
Then, when the students do come back, if it doesn't work for them, it's
_their_ fault not _yours_ ;-) ;-)

Going through all this should give you the confidence to ask for your
resolvers to be whitelisted.

> for a site if it were whitelisted.  Maybe IPv6-day will be a starting

It should be possible for site operators to add invisible web bugs such as
http://labs.apnic.net/ or http://www.potaroo.net/ispcol/2011-05/ip6test.html
or [  thing which logs locally that I can't find at the moment. ]
and then be able to answer queries about netblocks of "users" rather than
"resolvers"
that are IPv6 capable.

More work for content providers, but that may be part of the cost of doing
whitelisting.

    John

---

From: Erik Kline <[email-masked]>
Date: Wed, 11 May 2011 17:15:10 +0900

> More work for content providers, but that may be part of the cost of doing

Indeed.  But there is a cost to not doing whitelisting.  <insert
classical economics here>

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 May 2011 12:23:09 +0100

> Our site would fall into this category (for small cases of "plenty").

I would assume a lot of universities fall into this category; certainly ones in the UK I've spoken to about it do.   The academic networks, at least the backbones, have been at the forefront of IPv6 deployment.

We have dual-stack in our internal network, and publicly facing services, and have done for many years.  
We have native connectivity to our academic ISP (JANET)
JANET is natively dual-stacked (at 100Gbit/s now)
JANET has a fat dual-stack peering (10G?) with Google.
Yet we don't get AAAA for Google services, because we're not in the 'experiment'.
At least until June 8th :)

I would have hoped Google to be production AAAA by the end of 2011, so we're not *that* concerned about it.  Or maybe this whitelisting approach will be longer-term.  We'll see :)

Tim

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 12 May 2011 07:07:45 -0500

On May 11, 2011, at 2:39 AM, John Mann (ITS) wrote:
> You should be able to measure brokenness of your users by adding a web bug to the front page of a few of your own commonly visited sites
> e.g. add http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript
> Analysing the logs carefully should tell you who and how many work or have problems.

This would scale fine for our main campus (AS 59), but it's half of 
the million or so users of our statewide isp service (AS 2381) is the 
real issue...  basically the schools where the "IT guy" is really the
math teacher.

It is my hope that data collection from v6-day and/or the "happy-eyeballs"
approach could be the planned obsolescence of whitelisting.  I just now 
realize I don't see a reference to happy-eyeballs in the draft.  Would 
that be appropriate?

Dale

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 19:33:42 +0000

Thanks for your review and feedback, Ray. A revised –04 will soon be published. See some specific comments inline below in a few places.

Thank you!
JL

On 5/5/11 8:39 AM, "Ray Hunter" <[email-masked]<mailto:[email-masked]>> wrote:

[JL] Quite so…

[JL] The current I-D will definitely not lapse. Your point above is a good one and I have added this to the section concerning the implications of de-whitelisting:
"One particular risk is that, especially when a high-traffic domain de-whitelists a large network, this may cause a sudden change to networks since a large volume of traffic will then switch from IPv6 to IPv4. This can have dramatic effects on those being de-whitelisted as well as on other interconnected networks."

[JL] That section has been reworked in the upcoming revision and is now called "General Implementation Variations". If you think the re-worked section is still out of place after the –04, please feel free to say so.

[JL] I don't disagree that the resolver is an imperfect proxy for the end host's capabilities. Implementers have said it may be their best or easiest available tool however.

[JL] I understand your concern but I'm not sure how to update the sentence / section noted. If you have suggested text, please let me know.

[JL] Yes, and this was one of my initial concerns with the practice. It seems that the WG is not ready to work on recommended practices in this area. I'm working on some suggested steps an implementer can take in another group (the Broadband Internet Technical Advisory Group). That document covers each of the items you note below (and will become a public document in the next 2 – 3 months).

[JL] Broken IPv6-related connectivity is without a doubt one of the root issues. Another which I am trying to better address in the –04 is a volumetric concern held by high-traffic domains. This concerns leads them to search for a way to gradually add IPv6 traffic to their domain, so they can mature their IPv6 routes to various networks, and so their and other networks can mature their IPv6-related monitoring, policies, procedures, etc.

[JL] It's less about the resolvers being broken or having IPv6 issues — it's more the end hosts using a particular resolver.

[JL] This is a fair point — DNS is a foundational element.

[JL] Those are good questions for the WG. I think so far consensus seems to be to proceed with the current I-D and that, over time, a BCP or other additional documents may (or may not) be called for. That being said, on #4, the upcoming I-D will address this somewhat more directly.

Thanks again!
Jason

regards,
RayH