Dave - Thanks for the additional feedback. Any changes noted below will be made soon in a -06 update. See inline comments.
Regards
Jason
(I see that you've posted -05. This response is for completeness.)
On 5/29/2011 7:54 PM, Livingood, Jason wrote:
[JL] Duly noted in my previous emails. I'm keeping the naming as an open issue
in the –04 and will be seeking WG and WG co-chair guidance one way or the other.
One of the reasons for cross-area review is to look for cross-area problems.
Separate from the legal formalities, the purpose of 'trademark' is to try to
avoid market confusion. Market confusion was exactly the reason that I raised
concern about the naming and I wasn't the only one who noticed the problem. (My
original, informal posting was directly result of that confusion...)
So I'm sorry to see that the naming conflict is felt to be irrelevant by those
running the working group. (I was also a little surprised to see that that core
of folk constitute working group rough consensus, for removing open items.)
As for the actual term "whitelisting" I suppose we should admire the boldness of
the view that access to v6 is a priviledge -- note that that's the denotational
perspective of the word whitelisting...
[JL] Duly noted.
operator of a website, such as www.example.com, the operator
essentially applies an access control list (ACL) on the authoritative
DNS servers for the domain example.com. The ACL is populated with
An ACL usually is a yes/no mechanism. Here, however, the mechanism is for
asserting a preference for IPv6 over IPv4.
That does not seem to match the definition of ACL that I'm used to, unless the
semantic is defined as denying IPv4 access to the listed clients.
The term ACL is particularly odd to use if the mechanism pertains to responses
rather than queries.
[JL] I am using 'ACL' in the most general possible sense and am open to
alternative descriptors if you wish to suggest one. But most people seem to know
an ACL is a list that, if you are listed on it, grants you access to some
resource. In this case if the resolver is on the list then it gets AAAA RRs.
On reflection, the term is growing on me for this use.
"AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good
labels. They provide useful, direct and precise meaning, while avoiding the
various referential and denotational problems of a loaded term like whitelist.
[JL] Great! And I like thinking about it more in terms of granting "access" to AAAA RRs than viewing it as "blocking" AAAA RRs, as I find access control a more neutral term and one that is still easy to understand conceptually.
[JL] I took a stab at a new diagram in –04 — so take a look and let me know if
it is what you are suggesting (I've left the original one in for now).
Took a quick look at the added diagram in the new draft. The thing about a
protocol timeline diagram is that it uses verticality to provide ordering. So a
response is lower down than a request. I don't get that from your Figure 2.
(By the way, your first sub-scenario, with Resolver 1, shows only a v4 response,
without indicating whether the resolver sent a v6 or v4 query. For the review,
I think this distinction between transport and data -- "how is the
query/response transported" vs. "what RRs are returned" -- was a continuing
point of confusion for me. )
[JL] Ack. I'll add an extra note at the top of the diagram to clarify that the access control logic is independent of whether IPv6 transport is used between the host and resolver, or resolver and authority.
At least one highly-trafficked domain has noted that they have
received requests to not send DNS responses with AAAA resource
records to particular resolvers. In this case, the operators of
"At least one" seems a rather tiny statistic. Perhaps the actual statistic is
significantly larger?
[JL] It does not seem to be. Other than this being passed along by Google, I've
not heard of any similar stories. Nevertheless, it seemed interesting enough to
include.
As an anecdote, it is perhaps interesting. As a basis for promoting the entire
effort, not so much. I couldn't tell which role it was serving, but it felt
like the latter.
network infrastructure is not yet ready to handle the large traffic
volume which may be associated with the hosts in their network
connecting to the websites of these domains. This concern is clearly
So even though the site allows v6 DNS queries to go out from a host, it can't
really support having the host use v6?
[JL] A network isn't really in control of the end host's limitations w/r/t IPv6
That sort of commentary, along with the citation, might be good to include, for
clarification.
[JL] Done.
While in Section 1 the level of IPv6-related impairment has been
estimated to be as high as 0.078% of Internet users, which is a
8 hundredths of one percent?
I think that that's 8 of every 10,000 Internet users?
That's considered a high percentage?
[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that
rate, it'd be cheaper and easier for me (an ISP) to just buy new computers for
the affected "impaired" users than to have to navigate years of whitelisting
with a variety of domains. In any case, one recent measurement estimates it at
0.05% now and another at 0.015%. Despite this, this practice is still generating
some interest. I'm hoping World IPv6 Day goes well and is informative for the
community as to this percentage on a widespread basis, across a wide variety of
web sites.
Even if it is 8%, is that considered high?
[JL] 8% of the Internet finding google.com or facebook.com inaccessible would be
bad for everyone. That could generate several hundred thousand support calls per
day to a big ISP.
On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out of
every 10,000 users, nevermind a large multiple of that. (Although it does carry
a backhanded note of encouragement about v6 adoption, I'm a bit suspicious of
the statistic.)
[JL] Important to keep in mind that the IPv6-impairment occurs in situations where someone usually does not have functioning IPv6 transport — just seeing the AAAA RR causes issues.
troubleshooting standpoint. In this scenario, a DNS recursive
resolver operator will have no way to systematically determine
whether DNS whitelisting is or is not implemented for a domain, since
the absence of AAAA resource records may simply be indicative that
the domain has not yet added IPv6 addressing for the domain, rather
than that they have done so but have restricted query access via DNS
The premise is that, in large scale use, servers /will/ have a way to
systematically determine whether it is implemented? What are the existing
examples of having such a capability for other Internet protocols and services?
[JL] Perhaps I'm overplaying this point, but you know someone has email service
if they have an MX record for example, or a website if the host answers on
TCP/80. But as I re-read this it is probably overkill and so I've deleted it. I
have however moved some of the text to a prior section, since determining
whether or not domains are whitelisting is still a challenge at scale.
Note that a site can have email service without an MX and that TCP:80 is not
merely an "indicator" of web service, but actually /is/ the web service.
My point is that this idea of signaling/registering support of a service, as
separate from actually providing the service, is not part of typical Internet
service requirements and the simplification this provides is significant. We
need to be careful that we do not inadvertently teach folks that "signaling
support" is an expected feature.
(And with this response, given that you already deleted the text, it's my turn
to overplay a point...)
nature, not to mention physics. For example, as Sir Issac Newton
noted, "Every object in a state of uniform motion tends to remain in
that state of motion unless an external force is applied to it" [Laws
Code does not have momenum. Neither do configurations or lists. This really
isn't about physics.
[JL] But people and processes do have (operational) momentum…
Indeed, and the process of dealing with the naming issue for this does seem to
show that...
It is entirely about group psychology, as you note, and the administrative
challenges in the logistics of large-scale operational changes (which probably
/does/ have something to with physics, but it seems a stretch to credit Newton.
How about Heisenberg?...)
[JL] Hmmm… I don't think it is Heisenberg-related. But it's such an interesting
citation I feel it's almost a personal challenge to figure out a way to keep it
in there. ;-)
How certain of it's being a challenge are you? Does your certainty change as
you think about it?
[JL] I'm not wed to the reference. It was suggested earlier in the development of the document. If you have any better reference to the notion of momentum taking some effort to slow, I'm open to that.
The way I think about it is that in 5 or 10 years none of the
people working on the details of the IPv6 transition now will still be involved
in the day-to-day operational work. But DNS Whitelisting could still be in place
– and once something gets a momentum to it (people, processes, and
organizations) it is really, really hard to change that.
Well, I seriously applaud that concern, especially since its validity is proven
every day (including in the IETF...)
On the average, I tend to believe that the best way to instruct folks later is
by imparting information about tradeoffs and, especially, cost vs. benefit.
In the current case, the near-term cost/benefit makes some sense.
In the long term, the scaling cost of maintenance and the architectural cost of
losing spontaneous interoperability strike me as pretty f'ing expensive.
8.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS whitelisting, the Internet
community generally can choose to take no action whatsoever,
perpetuating the current predominant authoritative DNS operational
model on the Internet, and leave it up to end users with IPv6-related
impairments to discover and fix those impairments.
That is, place the burden of fixing a problem on those creating it?
[JL] In a way. It gets back to the question you asked about what level of
impairment justifies this practice. One obvious option is to let end users sort
it out (presumably by consulting with their ISPs / network operators). This may
be simpler and it's the way solutions to non-IPv6 problems tend to work today.
On the average, demanding that an end-user make an explicit decision about an
operational tuning issue does not work very well.
[JL] Thanks again for your feedback!
Jason
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
| 