Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*

["Livingood, Jason" <[e-mail]>]

Dave – Thanks for this email as well. It is my last item in queue before posting an updated –04 draft (whew!). See some specific responses inline below.

Thanks
JL

On 5/9/11 1:18 PM, "Dave CROCKER" <[e-mail]<mailto:[e-mail]>> wrote:

(This is an "official" and significantly extended version of an informal and
narrow review I posted earlier.  /d)

Howdy.

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Review (v2):

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker <[e-mail]<mailto:[e-mail]>>
Date:   <>

Summary
=======

This draft covers a a dual-stack problem in which a target host's DNS entry
contains records for IPv4 and IPv6, but returning IPv6 information to a DNS
client can cause problems. The paper discusses for resolving this through use of
a a DNS-based mechanism that manually lists response preferences to select which
DNS records to return.  The paper describes the mechanism and explores various
effects and possibilities of its use, including the difference between using it
selectively among a smaller number of sites, versus universally.

The draft is a serious effort to explore the use of such a mechanism and it
touches many different issues.  It is generally well-organized and clearly
written, although it very much needs the aid of a professional technical editor.
The writing often assumes too much knowledge by the reader.

The paper's exploration of universal adoption seems to vary between considering
that goal practical versus considering it only as a matter of completeness for
discussing the full range of possibilities.  That is, it is not clear whether
the paper views this alternative as practically possible and even preferred,
versus only a matter for academic thoroughness.

[JL] I consider it the latter – highly unlikely but included for completeness (on the assumption that a failure to include it would lead to comments that it was incomplete without it). However the –04 update will make more clear the remoteness of the possibility of universal deployment.

The paper needs to take a basic
position about feasibility, explain it in terms of comparable adoption efforts
at Internet-scale, and then make its treatment of universal adoption a bit more
consistent.

[JL] Good feedback - I've tried to do that in the –04 version.

When introducing terms, mechanisms, configurations and scenarios, the paper
needs to be more careful to describe them adequately for a reader new to the
topic.  This is not a matter of having a tutorial about the DNS, but rather a
tutorial for this type of mechanism and when and how it can be used.

As a specific example, the document cites "domain-by-domain" use, but I am not
clear how that would work, in terms of configuration and cross-net information
exchange.  One question is how the server knows the 'domain' of the client?

The document should careful to distinguish what is existing practice, versus
what is being explored as added possibilities.  The difference in concreteness
and certitude between the two is substantial.

The document's use of the term whitelisting appears to continue an existing,
recent use, for this type of mechanism.  Unfortunately it directly conflicts
with long-standing use of the term by the anti-abuse community for whitelisting
in the DNS. Its use here also seems to be a mismatch with the word's dictionary
semantics, which is most naturally used to distinguish yes/no choices, rather
than either/or choices.  So there is no intuitive sense of "goodness" (whitelist
= yes) or "badness" (blacklist) for this use. The word "preferences" seems more
in line with the meaning of the mechanism.

[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. Your other notes have also suggested a simplification of the document in some respects so that is also noted as an open item as well (but I really do need to get an update out in the meantime).

Detailed Comments
=================

Abstract

    The objective of this document is to describe what the whitelisting
    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean
something else?

Comcast's own considerable expertise notwithstanding, has this doc been vetted
with a range of organizations that actually DO whitelisting?  Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops folks
whose names I know.  (But then, I only know a few...)

[JL] Per my other note today, this will be fixed in the –04.

    whitelisting, as well as the implications of this emerging practice
    and what alternatives may exist.  The audience for this document is
    the Internet community generally, including the IETF and IPv6
    implementers.

I suspect that product marketers won't have much interest in this.  I suspect
that the target for this is anti-abuse technical and operations staff. In any
event, the targetting statement should be more precise.

[JL] Addressed in my earlier response to your shorter review.

1.  Introduction

    This document describes the emerging practice of whitelisting of DNS

One natural, semantic problem with the term 'whitelist' is that it does not
really match the function being performed.  The white/black distinction implies
goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is for
preference or priority.  What would a "blacklist" be, here?  Also note it is not
obvious what it means to be whitelisted, here?  Does it mean to choose the AAAA
records or the A records?

This is more like a 'Preference' or 'Configuration' list.

At the least, the name for this should be IPv6 Resolver Whitelisting.  It makes
clear /what/ is being "whitelisted".

[JL] Ack. Carried in Open Items for –04.

    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
    referred to as DNS whitelisting.  The document explores the

This provides a name, but not a function.  That is, it does not say what this
mechanisms actually /does/ or is /for/.

[JL] Addressed in my earlier response to your shorter review.

    implications of this emerging practice are and what alternatives may
    exist.

    The practice of DNS whitelisting appears to have first been used by
    major web content sites (sometimes described herein as "highly-

It's use for email anti-abuse dates back farther.

    <http://www.dnswl.org/>

    <http://en.wikipedia.org/wiki/DNSBL>

<http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html>

Specifically within the context of the DNS, the term whitelisting is therefore
made ambiguous.

A google query for "whitelist dns" also demonstrates the history and current
ambiguity.

[JL] Addressed in my earlier response to your shorter review.

    trafficked domains" or "major domains").  These web site operators,
    or domain operators, observed that when they added AAAA resource
    records to their authoritative DNS servers in order to support IPv6
    access to their content that a small fraction of end users had slow
    or otherwise impaired access to a given web site with both AAAA and A
    resource records.  The fraction of users with such impaired access
    has been estimated to be roughly 0.078% of total Internet users
    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
    Brokenness].  Thus, in an example Internet Service Provider (ISP)
    network of 10 million users, approximately 7,800 of those users may
    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is, in total users and total
traffic.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated and explained a bit more precisely.

[JL] Addressed in my earlier response to your shorter review.

    As a result of this impairment affecting end users of a given domain,
    a few major domains have either implemented DNS whitelisting or are
    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
    When implemented, DNS whitelisting in practice means that a domain's
    authoritative DNS will return a AAAA resource record to DNS recursive
    resolvers [RFC1035] on the whitelist, while returning no AAAA
    resource records to DNS resolvers which are not on the whitelist.  It

This explanation of the function should be offered sooner and should be
summarized in the Abstract.

[JL] Good suggestion – made some tweaks to the Abstract to try to address this.

    is important to note that these major domains are motivated by a
    desire to maintain a high-quality user experience for all of their

Rather than being important to note, this sentence sounds oddly like marketing
hype, in a technical specification.  It is gratuitous because specified features
are never added to /lower/ the quality of the user experience, for example.

In addition, the mechanism also affects client activity that has no user
directly involved.


    users.  By engaging in DNS whitelisting, they are attempting to
    shield users with impaired access from the symptoms of those
    impairments.

The /technical/ statement that should be here is that they are attempting to
provide a work-around for problematic behaviors in dual-stack IPv4/IPv6
environments.

The paper should make more clear exactly where the problem lies and when. If it
can occur for a number of reasons, explaining each of those scenarios would be
useful.

[JL] I've attempted to do so in the –04 update.

    Critics of the practice of DNS whitelisting have articulated several
    concerns.  Among these are that:

    o  DNS whitelisting is a very different behavior from the current
       practice concerning the publishing of IPv4 address resource
       records,

    o  that it may create a two-tiered Internet,

    o  that policies concerning whitelisting and de-whitelisting are
       opaque,

Livingood                Expires August 26, 2011                [Page 5]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    o  that DNS whitelisting reduces interest in the deployment of IPv6,

    o  that new operational and management burdens are created,

well, yeah... in fact it should be noted that the burdens are particularly
onerous at scale.

[JL] Ack – updated the text to reflect this



    o  and that the costs and negative implications of DNS whitelisting
       outweigh the perceived benefits, compared to fixing underlying
       impairments.

and it doesn't scale.

and it violates an extremely basic premise of cross-Internet interoperability by
requiring prior arrangement.

[JL] Ack – added this

    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.


2.  How DNS Whitelisting Works

How IPv6 AAAA DNS Whitelisting Works.

(Anti-spam DNS Whitelisting works rather differently...)


    DNS whitelisting is implemented in authoritative DNS servers.  These
    servers implement IP address-based restrictions on AAAA query
    responses.  So far, DNS whitelisting has been primarily implemented
    by web server operators deploying IPv6-enabled services.  For a given

Really?  This is web-specific?  The same restrictions are not applied for other
applications?

So if the same client-side hosts attempt to contact the server for email or
xmpp, they won't get the same handling?

[JL] Quite so – I updated the text to clarify this.

    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.

    the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive

Either address type can be listed?  So this really is a pure 'preferences'
mechanism?

Which settings count as whitelisting?  Do any count as blacklisting?

[JL] A resolver can have both IPv6 and IPv4 addresses. Whether a resolver is listed on the whitelist and is therefore able to receive AAAA RR responses is orthogonal to whether the resolver itself has an IPv4 or IPv6 address — since the whitelisting decision making tends to be based on some conclusion about the hosts that query the resolver rather than the resolver.

    resolvers on the Internet, which have been authorized to receive AAAA
    resource record responses.  These DNS recursive resolvers are
    operated by third parties, such as ISPs, universities, governments,
    businesses, and individual end users.  If a DNS recursive resolver IS
    NOT matched in the ACL, then AAAA resource records will NOT be sent
    in response to a query for a hostname in the example.com domain.

This configuration appears to ensure the maximum barrier to adoption for IPv6,
since it means that IPv6 will not work automatically.  It will only work for
hosts that are manually configured to receive responses with v6 records.

That's a rather major implication.  It's a default that is probably meant to
apply during the very early stages of adoption, when there are few users of the
newer mechanism.

It's probably worth discussing it in more detail, including discussing when to
change the default...

[JL] Correct on all 3 points. I've tried to address this better in the –04 version.

    However, if a DNS recursive resolver IS matched in the ACL, then AAAA
    resource records will be sent in response to a query for a given
    hostname in the example.com domain.  While these are not network-
    layer access controls they are nonetheless access controls that are a
    factor for end users and other parties like network operators,
    especially as networks and hosts transition from one network address
    family to another (IPv4 to IPv6).

Also, all of this clarifies the function of this listing mechanism and suggests
a very different name, to be more precise and accurate in naming it:

     IPv6 DNS Response Preference List.

[JL] I've added all the various naming suggestions to the Open Issues section.

    In practice, DNS whitelisting generally means that a very small
    fraction of the DNS recursive resolvers on the Internet (those in the
    whitelist ACL) will receive AAAA responses.  The large majority of
    DNS resolvers on the Internet will therefore receive only A resource
    records containing IPv4 addresses.  Thus, quite simply, the
    authoritative server hands out different answers depending upon who
    is asking; with IPv4 and IPv6 resource records for some on the
    authorized whitelist, and only IPv4 resource records for everyone
    else.  See Section 2.1 and Figure 1 for a description of how this



Livingood                Expires August 26, 2011                [Page 6]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    works.

    Finally, DNS whitelisting can be deployed in two primary ways:
    universally on a global basis, or on an ad hoc basis.  Deployment on
    a universal deployment basis means that DNS whitelisting is
    implemented on all authoritative DNS servers, across the entire
    Internet.  In contrast, deployment on an ad hoc basis means that only
    some authoritative DNS servers, and perhaps even only a few,
    implement DNS whitelisting.  These two potential deployment models
    are described in Section 6.

2.1.  Description of the Operation of DNS Whitelisting

    The system logic of DNS whitelisting is as follows:

    1.  The authoritative DNS server for example.com receives DNS queries
        for the A (IPv4) and AAAA (IPv6) address resource records for the
        FQDN www.example.com, for which AAAA (IPv6) resource records
        exist.

This means that the mechanism is /only/ triggered when /both/ address records
are queried?  A query for only one type of address record won't trigger the list
lookup?  I think that doesn't match other statements in the document.

[JL] Updated to clarify / correct my text. (changed A and AAAA to and/or)



    2.  The authoritative DNS server examines the IP address of the DNS
        recursive resolver sending the AAAA (IPv6) query.

"examines"?  Examines it for what?  What does this step mean?

[JL] Examines as in looks at the IP address. I'll just simplify it and combine it with #3.

    3.  The authoritative DNS server checks this IP address against the
        access control list (ACL) that is the DNS whitelist.

    4.  If the DNS recursive resolver's IP address IS matched in the ACL,
        then the response to that specific DNS recursive resolver can
        contain AAAA (IPv6) address resource records.

Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This is
whether to /include/ a particular type of RR in responses???

In that case an appropriate name for this mechanism is more like:

    DNS Response Content Preference List

[JL] Adding this suggested name to the Open Issues list as well.

And this seems even less like an ACL than it did before.  (I assume the
justification is that access is being prevented by virtue of not supplying the
address, but still...)


    5.  If the DNS recursive resolver's IP address IS NOT matched in the
        ACL, then the response to that specific DNS recursive resolver
        cannot contain AAAA (IPv6) address resource records.  In this
        case, the server should return a response with the response code
        (RCODE) being set to 0 (No Error) with an empty answer section
        for the AAAA record query.

Livingood                Expires August 26, 2011                [Page 7]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    ---------------------------------------------------------------------
    A query is sent from a DNS recursive resolver that IS NOT on the DNS
    whitelist:

                Request                      Request
            www.example.com                  www.example.com
                  AAAA    +-------------+     AAAA    +-----------------+
      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
      ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
    +--------+     A      | example.com |      A      |                 |
       Host    <--------- |  WHITELIST  |  <--------- |                 |
     Computer   A Record  +-------------+  A Record   +-----------------+
                Response   DNS Recursive   Response       example.com
               (only IPv4)   Resolver     (only IPv4)    Authoritative
                               #1                           Server
    ---------------------------------------------------------------------
    A query is sent from a DNS recursive resolver that IS on the DNS
    whitelist:

                Request                      Request
            www.example.com                  www.example.com
                 AAAA     +-------------+     AAAA    +-----------------+
      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
      ||  ||       A      |   **IS**    |      A      | IN A exists     |
    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
    +--------+   AAAA     | example.com |     AAAA    |                 |
       Host    <--------- |  WHITELIST  |  <--------- |                 |
     Computer      A      |             |      A      |                 |
               <--------- |             |  <--------- |                 |
               A and AAAA +-------------+ A and AAAA  +-----------------+
                Record     DNS Recursive   Record        example.com
               Responses     Resolver     Responses      Authoritative
               (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
    ---------------------------------------------------------------------

               Figure 1: DNS Whitelisting - Functional Diagram

This diagram is confusing to me.  I suspect that a protocol exchange sequence
format, in the style of:

      Host             Resolver 1            Authoritative

           ---------->
                                  --------->
                                 <---------
          <----------

will be considerably more helpful.

[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).

3.  What Problems Are Implementers Trying To Solve?

This is a very useful section and it is probably worth moving it higher, to
precede the 'how it works' section.


    As noted in Section 1, domains which implement DNS whitelisting are
    attempting to protect a few users of their domain, who have impaired
    IPv6 access, from having a negative experience (poor performance).

By the way, what does 'impaired v6 access' mean?

I think there needs to be a simple, direct description of what occurs without
this mechanism.

For example, perhaps you mean that a host can send DNS queries using IPv6 but
cannot receive DNS responses over IPv6? Perhaps you mean that the host can send
IPv6 but cannot receive it.  (That's a different scale and scope of problem from
the first example I gave.)

This brief, summary problem statement should be included in the Abstract, to
make /much/ more clear what this mechanism is for.

[JL] Done. Added text to the Abstract and Intro and added more to note that this is about both impairment and (actual or perceived) immaturity of IPv6 network routing and practices.



    While it is outside the scope of this document to explore the various
    reasons why a particular user's system (host) may have impaired IPv6
    access, for the users who experience this impairment it is a very
    real performance impact.  It would affect access to all or most dual



Livingood                Expires August 26, 2011                [Page 8]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    stack services to which the user attempts to connect.  This negative
    end user experience can range from someone slower than usual (as
    compared to native IPv4-based access), to extremely slow, to no
    access to the domain whatsoever.

Rather than repeat that this is about end-users, it sounds more that this is
about whether a service works or does not work, whether a user is directly
present or not.


    While one can debate whether DNS whitelisting is the optimal solution
    to the end user experience problem, it is quite clear that DNS
    whitelisting implementers are interested in maximizing the
    performance of their services for end users as a primary motivation
    for implementation.

You keep citing 'performance' but haven't described what sort of performance
degradation takes place. Is this really about relatively better or worse
performance -- and if so, how -- or is this about working or not working?

[JL] Good point – I added this text:
"In essence, whether the end user even has an IPv6 address or not (they probably only have an IPv4 address), merely by receiving a AAAA record response the user either cannot access a FQDN or it is so slow that the user gives up and assumes the destination is unreachable."

Also rather than saying what implementers are interested in, it's probably more
helpful to note that the practice is now significantly established and therefore
worth documenting, independent of its possible controversy.


    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.

    those recursive resolvers have expressed a concern that their IPv6

I suspect that it's not resolvers that are doing the expressing, since their
vocabulary is usually too limited...

[JL] Quite. Updated:
"In this case, DNS recursive resolvers operators have expressed…"

    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 impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/

Wow. I do understand why service providers often have to work around silliness
at the client side, but this problem at the client side seems particularly
egregious.


    a temporary consideration relating to the deployment of IPv6 network
    infrastructure on the part of networks with end user hosts, rather
    than a long-term concern.  These end user networks may also have

Again this goal of short-term usage is worth noting earlier, including in the
Abstract.


    other tools at their disposal in order to address this concern,
    including applying rules to network equipment such as routers and
    firewalls (this will necessarily vary by the type of network, as well
    as the technologies used and the design of a given network), as well
    as configuration of their recursive resolvers (though modifying or
    suppressing AAAA resource records in a DNSSEC-signed domain on a
    Security-Aware Resolver will be problematic Section 10.1).

    Some implementers with highly-trafficked domains have explained that
    DNS whitelisting is a necessary, though temporary, risk reduction
    tactic intended to ease their transition to IPv6 and minimize any
    perceived risk in such a transition.  As a result, they perceive this
    as a tactic to enable them to incrementally enable IPv6 connectivity
    to their domains during the early phases of their transition to IPv6.

    Finally, some domains, have run IPv6 experiments whereby they added
    AAAA resource records and observed and measured errors [Heise Online
    Experiment], which should be important reading for any domain
    contemplating either the use of DNS whitelisting or simply adding
    IPv6 addressing to their site.


4.  Concerns Regarding DNS Whitelisting

    There are a number of potential implications relating to DNS
    whitelisting, which have been raised as concerns by some parts of the
    Internet community.  Many of those potential implications are further

I think the implications are not conditional; they exist rather than being
potential.  The 'potential' is that what is implicated will come to pass.

[JL] Fair point – removed 'potential' there and in another similar section.


Livingood                Expires August 26, 2011                [Page 9]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    enumerated here and in Section 7.

Pro forma question:  Why are implications discussed in multiple places?

[JL] Some of them in are briefly noted in Section 4, but the exhaustive list in in Section 7.



    Some parties in the Internet community, including ISPs, are concerned

This style of text personalizes the issues unnecessarily (IMO).  It does not
really matter who holds the concerns, or else they'd be described more precisely.

[JL] I'll have to look at that after the –04 update. In a previous draft I was asked to call out different parts of the community separately. (Always challenging to work through conflicting feedback.)


I suggest merely noting that there are concerns and then listing and discussing
the concerns, rather than adding text to attribute the concerns to others, even
if the conclusion of your text is that a particular concern is not valid.

[JL] Duly noted. Let me get the –04 update out, after which I will look at generally simplifying the I-D and look at this issue specifically.



    that the practice of DNS whitelisting for IPv6 address resource
    records represents a departure from the generally accepted practices
    regarding IPv4 address resource records in the DNS on the Internet
    [Whitelisting Concerns].  These parties explain their belief that for

"These parties explain their belief" is an example of personalization that is
not needed.  This isn't about the believers.  It is about possible problems.

[JL] Ack.

    A resource records, containing IPv4 addresses, once an authoritative
    server operator adds the A record to the DNS, then any DNS recursive
    resolver on the Internet can receive that A record in response to a

This does not appear to be a grammatically valid sentence.  My guess is that
deleting "A resource... addresses" fixes this.

[JL] Change made.

And by the way, the document's reference to "recursive" resolvers is mostly
likely incorrect.  The problem is not restricted only to that very specific type
of resolver, is it?

If in fact it /is/ specific to them -- and your following text describes an
indirect effects scenario where it might be -- I suggest calling out the
configuration at the beginning, along the lines of:

      One way the problem with returning AAAA records can be experienced is when
recursive resolvers are used.  Although that resolver might support IPv6, its
client hosts might not.  So, returning an AAAA record will mean that these
limited hosts will be given an unusable address.

And this type of description belongs in the text describing the motivating
problem(s), rather than buried in the 'concerns' discussion.

(The text, here, pertains to A records, but the problem I've described uses the
same configuration but for AAAA records with mixed v6 support.)


    query.  By extension, this means that any of the hosts connected to
    any of these DNS recursive resolvers can receive the IPv4 address
    resource records for a given FQDN.  This enables new server hosts
    which are connected to the Internet, and for which a fully qualified
    domain name (FQDN) such as www.example.com has been added to the DNS
    with an IPv4 address record, to be almost immediately reachable by
    any host on the Internet.  In this case, these new servers hosts
    become more and more widely accessible as new networks and new end
    user hosts connect to the Internet over time, capitalizing on and
    increasing so-called "network effects" (also called network
    externalities).  It also means that the new server hosts do not need
    to know about these new networks and new end user hosts in order to
    make their content and applications available to them, in essence
    that each end in this end-to-end model is responsible for connecting
    to the Internet and once they have done so they can connect to each
    other without additional impediments or middle networks or
    intervening networks or servers knowing about these end points and
    whether one is allowed to contact the other.

Hmmm.  This rather lengthy bit of prose appears merely to be explaining the
basic and long-standing DNS value proposition???

[JL] Ack – see previous comments about simplification. At the same time I'm trying to keep the document understandable to wide audience (and one of your other notes suggested I need to be somewhat less technical or more descriptive). You may be more familiar with the mechanics of DNS whereas someone else is less so. I'll think about this one…

    In contrast, the concern is that DNS whitelisting may fundamentally
    change this model.  In the altered DNS whitelisting end-to-end model,
    one end (where the end user is located) cannot readily connect to the
    other end (where the content is located), without parts of the middle
    (recursive resolvers) used by one end (the client, or end user hosts)
    being known to an intermediary (authoritative nameservers) and
    approved for access to the resource at the end.  As new networks
    connect to the Internet over time, those networks need to contact any
    and all domains which have implemented DNS whitelisting in order to
    apply to be added to their DNS whitelist, in the hopes of making the
    content and applications residing on named server hosts in those
    domains accessible by the end user hosts on that new network.
    Furthermore, this same need to contact all domains implementing DNS
    whitelisting also applies to all pre-existing (but not whitelisted)
    networks connected to the Internet.

    In the current IPv4 Internet when a new server host is added to the
    Internet it is generally widely available to all end user hosts and
    networks, when DNS whitelisting of IPv6 resource records is used,

If it is available to the hosts, it is available to the network.

networks, when -> networks. When

[JL] Fixed






Livingood                Expires August 26, 2011               [Page 10]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    these new server hosts are not accessible to any end user hosts or
    networks until such time as the operator of the authoritative DNS

They are still accessible.  The IP-level mechanisms still work.

They are not reachable when using the domain name.

[JL] Fixed



    servers for those new server hosts expressly authorizes access to
    those new server hosts by adding DNS recursive resolvers around the
    Internet to the ACL.  This has the potential to be a significant

This is a good example of the reason the term ACL is inappropriate:  It implies
a security protection that does not actually exist.  The hosts are still accessible.

[JL] I still think the whitelist is comparable to an ACL insofar as it controls access to AAAA RR responses on the authoritative server, regardless of access by IP address to some destination host.

    change in reachability of content and applications by end users and
    networks as these end user hosts and networks transition to IPv6,
    resulting in more (but different) breakage.  A concern expressed is
    that if much of the content that end users are most interested in is
    not accessible as a result, then end users and/or networks may resist
    adoption of IPv6 or actively seek alternatives to it, such as using
    multi-layer network address translation (NAT) techniques like NAT444
    [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
    that this practice also could disrupt the continued increase in
    Internet adoption by end users if they cannot simply access new
    content and applications but must instead contact the operator of
    their DNS recursive resolver, such as their ISP or another third
    party, to have their DNS recursive resolver authorized for access to
    the content or applications that interests them.  Meanwhile, these
    parties say, over 99.9% of the other end users that are also using
    that same network or DNS recursive resolver are unable to access the
    IPv6-based content, despite their experience being a positive one.

    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?

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.

5.2.  Similarities to DNS Load Balancing

    DNS whitelisting also has some similarities to DNS load balancing.
    There are of course many ways that DNS load balancing can be
    performed.  In one example, multiple IP address resource records (A
    and/or AAAA) can be added to the DNS for a given FQDN.  This approach
    is referred to as DNS round robin [RFC1794].  DNS round robin may
    also be employed where SRV resource records are used [RFC2782].

Right, but that's algorithmic rather than involving the manual method, described
here. So it does not seem comparable.

[JL] Whether I agree with you or not, the WG asked to include it in an earlier draft. I tried to simply say that there are "some" similarities as a qualifier.

6.  Likely Deployment Scenarios

    In considering how DNS whitelisting may emerge more widely, there are
    two likely deployment scenarios, which are explored below.

    In either of these deployment scenarios, it is possible that
    reputable third parties could create and maintain DNS whitelists, in
    much the same way that blacklists are used for reducing email spam.
    In the email context, a mail operator subscribes to one or more of
    these lists and as such the operational processes for additions and
    deletions to the list are managed by a third party.  A similar model
    could emerge for DNS whitelisting, whether deployment occurs
    universally or on an ad hoc basis.

The challenges of email whitelists and blacklists should be cited, since it
provides a rich base of experience for such an effort, at scale.


6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis

    The seemingly most likely deployment scenario is where some

Most likely?  This is not already established practice?

[JL] It is established at some large domains like google.com (which comprise a large % of global Internet traffic). But other domains are now on the cusp of their IPv6 transition and are pondering whether or not to use whitelisting. This document will hopefully be one of many data points in their decision-making.

    authoritative DNS server operators implement DNS whitelisting but
    many or most others do not do so.  What can make this scenario
    challenging from the standpoint of a DNS recursive resolver operator
    is determining which domains implement DNS whitelisting, particularly
    since a domain may not do so as they initially transition to IPv6,
    and may instead do so later.  Thus, a DNS recursive resolver operator



Livingood                Expires August 26, 2011               [Page 13]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    may initially believe that they can receive AAAA responses as a
    domain adopts IPv6, but then notice via end user reports that they no
    longer receive AAAA responses due to that domain adopting DNS
    whitelisting.  Of course, a domain's IPv6 transition may be
    effectively invisible to recursive server operators due to the effect
    of DNS whitelisting.

This suggests that every listing at the server needs a contact record for
periodic checks whether to renew the listing.



    In contrast to a universal deployment of DNS whitelisting
    Section 6.2, deployment on an ad hoc basis is likely to be
    significantly more challenging from an operational, monitoring, and

Oh?  Use in small scale is more challenging than use of manual exceptions list
at large scale?  That's a very unexpected view.

[JL] I think it is in some regards but thinking it through more fully, I think you are correct and I have removed this.

    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.

    whitelisting.  As a result, discovering which domains implement DNS
    whitelisting, in order to differentiate them from those that do not,
    is likely to be challenging.

    One benefit of DNS whitelisting being deployed on an ad hoc basis is
    that only the domains that are interested in doing so would have to
    upgrade their authoritative DNS servers in order to implement the
    ACLs necessary to perform DNS whitelisting.

    In this potential deployment scenario, it is also possible that a
    given domain will implement DNS whitelisting temporarily.  A domain,
    particularly a highly-trafficked domain, may choose to do so in order
    to ease their transition to IPv6 through a selective deployment and
    minimize any perceived risk in such a transition.

6.2.  Deploying DNS Whitelisting Universally

    The least likely deployment scenario is one where DNS whitelisting is
    implemented on all authoritative DNS servers, across the entire
    Internet.  While this scenario seems less likely than ad hoc
    deployment due to some parties not sharing the concerns that have so
    far motivated the use of DNS whitelisting, it is nonetheless
    conceivable that it could be one of the ways in which DNS
    whitelisting is deployed.

Significantly, the partial-deployment model casts this mechanism as a transition
expedient -- as the document reasonably describes it -- whereas universal
deployment casts it as a fundamental change to the architecture.

Given that it would take decades to achieve relatively full deployment of this
'across the entire Internet', what is the benefit of discussing this highly
unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think
otherwise, the paper needs to explore the deployment and adoption issues in much
more detail, because I don't see how it could work.

[JL] Per my previous email responses this has been extensively reworked. I feel I should probably leave the universal deployment scenario in there for completeness, but it's been cut down and minimized. I'm open to reconsidering the question later.

   In order for this deployment scenario to occur, it is likely that DNS
    whitelisting functionality would need to be built into all
    authoritative DNS server software, and that all operators of
    authoritative DNS servers would have to upgrade their software and
    enable this functionality.  It is likely that new Internet Draft
    documents would need to be developed which describe how to properly
    configure, deploy, and maintain DNS whitelisting.  As a result, it is

Livingood                Expires August 26, 2011               [Page 14]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011

    unlikely that DNS whitelisting would, at least in the next several
    years, become universally deployed.  Furthermore, these DNS
    whitelists are likely to vary on a domain-by-domain basis, depending
    upon a variety of factors.  Such factors may include the motivation
    of each domain owner, the location of the DNS recursive resolvers in
    relation to the source content, as well as various other parameters
    that may be transitory in nature, or unique to a specific end user
    host type.  It is probably unlikely that a single clearinghouse for
    managing whitelisting is possible; it will more likely be unique to
    the source content owners and/or domains which implement DNS
    whitelists.

    While this scenario may be unlikely, it may carry some benefits.
    First, parties performing troubleshooting would not have to determine
    whether or not DNS whitelisting was being used, as it always would be
    in use.  In addition, if universally deployed, it is possible that
    the criteria for being added to or removed from a DNS whitelist could
    be standardized across the entire Internet.  Nevertheless, even if
    uniform DNS whitelisting policies were not standardized, is also
    possible that a central registry of these policies could be developed
    and deployed in order to make it easier to discover them, a key part
    of achieving transparency regarding DNS whitelisting.

Is any of this paragraph realistic?  Obviously my asking means I don't it is.
These seem to be of theoretical rather than pragmatic interest.  ("If everyone
refuses to shoot, there will be no wars.")

It's true that this is an "implications" paper rather than a BCP, but still...

[JL] Good point. Paragraph removed.


7.  Implications of DNS Whitelisting

    There are many potential implications of DNS whitelisting.  The key
    potential implications are detailed below.

7.1.  Architectural Implications

    DNS whitelisting could be perceived as modifying the end-to-end model
    and/or the general notion of the architecture that prevails on the

I'll suggest that perception is not a major issue about a technical topic like
this.  (It's not entirely irrelevant, of course, but I suspect it is quite minor.)

The major issue is whether it /actually/ modifies the end-to-end nature of the
DNS.  And I think it does, as well as modifying the "spontaneous
interoperability" expectation for most Internet mechanism, since it requires
prior registration.

[JL] Removed the perception stuff…



7.2.  Public IPv6 Address Reachability Implications

    The predominant experience of end user hosts and servers on the IPv4-
    addressed Internet today is that when a new server with a public IPv4
    address is added to the DNS, that it is then globally accessible by

This sentence is not quite correct, in strict technical terms.  Since this is a
technical discussion, we need to be precise:  the host is reachable when the
routing tables make it reachable.  That's strictly a mapper of IP Address
handling, not name-to-address mapping.

What you mean is that its domain name is immediately useful for reaching it.

[JL] Correction made.



    IPv4-addressed hosts.  This is a generalization and in Section 5
    there are examples of common cases where this may not necessarily be
    the case.  For the purposes of this argument, that concept of
    accessibility can be considered "pervasive reachability".  It has so
    far been assumed that the same expectations of pervasive reachability
    would exist in the IPv6-addressed Internet.  However, if DNS
    whitelisting is deployed, this will not be the case since only end
    user hosts using DNS recursive resolvers which are included in the

again, you mean /name-based/ reachability.

[JL] Fixed. In a way I was grasping at the "spontaneous interoperability" notion you mentioned.


Livingood                Expires August 26, 2011               [Page 16]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    ACL of a given domain using DNS whitelisting would be able to reach
    new servers in that given domain via IPv6 addresses.  The expectation
    of any end user host being able to connect to any server (essentially
    both hosts, just at either end of the network), defined here as
    "pervasive reachability", will change to "restricted reachability"
    with IPv6.

    Establishing DNS whitelisting as an accepted practice in the early
    phases of mass IPv6 deployment could well establish it as an integral
    part of how IPv6 DNS resource records are deployed globally.  As a
    result, it is then possible that DNS whitelisting could live on for
    decades on the Internet as a key foundational element of domain name
    management that we will all live with for a long time.

(that last sentence could benefit from some editing.)

[JL] Ack – fixed.

    It is a critical to understand that the concept of reachability
    described above depends upon a knowledge or awareness of an address
    in the DNS.  Thus, in order to establish reachability to an end
    point, a host is dependent upon looking up an IP address in the DNS

If this section were started with a sentence like this, then there would not be
a problem with the other references' being confused with address-based routing
reachability.

[JL] Great point! I've actually moved the last paragraph to the start of that section and it makes much more sense.

    when a FQDN is used.  When DNS whitelisting is used, it is quite
    likely the case that an IPv6-enabled end user host could ping or
    connect to an example server host, even though the FQDN associated
    with that server host is restricted via a DNS whitelist.  Since most

First, I suspect that "example" doesn't add meaning to the sentence.  Second,
pinging and connecting might happen with or without the whitelist entry.  So I
do not understand what import there is in this sentence.

[JL] I removed pinging but left connecting. What I'm saying you may still be able to connect to the host via an IP if you cannot use the FQDN (it won't always be the case, such as on a virtual web server sharing one IP across several sites). I'll reword it a bit though since I see your point.

    Internet applications and hosts such as web servers depend upon the
    DNS, and as end users connect to FQDNs such as www.example.com and do
    not remember or wish to type in an IP address, the notion of
    reachability described here should be understood to include knowledge
    how to associate a name with a network address.

Again, this 'premise' statement should introduce the sub-section, not end it.

[JL] Done (as noted above)


7.3.  Operational Implications

    This section explores some of the operational implications which may
    occur as a result of, are related to, or become necessary when
    engaging in the practice of DNS whitelisting.

7.3.1.  De-Whitelisting May Occur

The more general version of this issue is 'synchronization'.  Entries in the
whitelist need to be synchronized with host status and capabilities.


    It is possible for a DNS recursive resolver added to a whitelist to
    then be removed from the whitelist, also known as de-whitelisting.
    Since de-whitelisting can occur, through a decision by the
    authoritative server operator, the domain owner, or even due to a
    technical error, an operator of a DNS recursive resolver will have
    new operational and monitoring requirements and/or needs as noted in
    Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.

7.3.2.  Authoritative DNS Server Operational Implications

    Operators of authoritative servers may need to maintain an ACL a

a -> on a (?)

[JL] fixed



    server-wide basis affecting all domains, on a domain-by-domain basis,


Livingood                Expires August 26, 2011               [Page 17]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    as well as on a combination of the two.  As a result, operational

I'm not really understanding the first sentence.  One problem might be that its
discussing an implication of some configuration or usage options that have not
been previously specified, so that the reference here might be overly cryptic.

For example, I don't know what "affecting all domains" actually means.  It
almost sounds as if it could mean "everyone gets AAAA records" or "no one gets
AAAA records" yet I'm reaonably certain that is /not/ what is meant.

[JL] Yes, that sentence was unclear. It is now:
"Operators of authoritative servers (which are frequently authoritative for multiple domain names) will need to maintain an ACL on a server-wide basis affecting all domains, or on a domain-by-domain basis."

    practices and software capabilities may need to be developed in order
    to support such functionality.  In addition, processes may need to be
    put in place to protect against inadvertently adding or removing IP
    addresses, as well as systems and/or processes to respond to such
    incidents if and when they occur.  For example, a system may be
    needed to record DNS whitelisting requests, report on their status
    along a workflow, add IP addresses when whitelisting has been
    approved, remove IP addresses when they have been de-whitelisted, log
    the personnel involved and timing of changes, schedule changes to
    occur in the future, and to roll back any inadvertent changes.

Might be worth starting with a simple, broad summary statement, possibly along
the lines of:

    An AAAA DNS Whitelist serves as a critical infrastructure service; to be
useful it needs careful and extensive administration, monitoring and operation.
  Each new and essential mechanism creates substantial follow-on support costs.

[JL] Thanks – added that text.



    Operators may also need implement new forms of monitoring in order to
    apply change control, as noted briefly in Section 7.3.4.

7.3.3.  DNS Recursive Resolver Server Operational Implications

    Operators of DNS recursive resolvers, which may include ISPs,
    enterprises, universities, governments, individual end users, and
    many other parties, are likely to need to implement new forms of
    monitoring, as noted briefly in Section 7.3.4.  But more critically,
    such operators may need to add people, processes, and systems in
    order to manage large numbers of DNS whitelisting applications as
    part of their own IPv6 transition, for all domains that the end users
    of such servers are interested in now or in which they may be

I think the summary observation is simple and should be stated directly:  This
is a manual mechanism that becomes expensive in time and personnel effort as it
scales up.

[JL] Added that



    interested in the future.  As anticipation of interesting domains is
    likely infeasible, it is more likely that operators may either choose
    to only apply to be whitelisted for a domain based upon one or more
    end user requests, or that they will attempt to do so for all domains
    that they can ascertain to be engaging in DNS whitelisting.

"attempt to do so for all domain that they can ascertain to be engaging in DNS
whitelisting"  appears to be saying to do whitelisting for domains that do
whitelisting.  I don't understand.

[JL] I was going to great effort to badly make a point that you can't anticipate all domains users will want to access and so will need a way for users to request whitelisting instead. I've reworded as:
"But more critically, such operators will need to add people, processes, and systems in order to manage large numbers of DNS Whitelisting applications. Since there is no common method for determining whether or not a domain is engaged in DNS Whitelisting, operators will have to apply to be whitelisted for a domain based upon one or more end user requests, which means systems, processes, and personnel for handling and responding to those requests will also be necessary."


    When operators apply for DNS whitelisting for all domains, that may

"apply for DNS whitelisting for all domains" -- again I'm not understanding what
this means.

[JL] See above

7.3.5.  Implications of Operational Momentum

    It seems plausible that once DNS whitelisting is implemented it will
    be very difficult to deprecate such technical and operational
    practices.  This assumption is based in an understanding of human

in -> on

[JL] Fixed

    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…

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. ;-) 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. This seems very much like the physics principle to which I refer but I'm open to other citations. I envision this possibility:
Q (from new trainee): Why are we doing this DNS Whitelisting thing?
A: Because that's what we have to do for IPv6 access to every new domain.
Q: Why?
A: Because we've been doing it for years and it says to do it here in this operations manual we have to follow.
Q: Then I guess we should keep doing it?
A: Yes, we should. It'd be hard to change the standard process, and we'd have to escalate it to someone, etc.

    of Motion].  Thus, once DNS whitelisting is implemented it is quite
    likely that it would take considerable effort to deprecate the
    practice and remove it everywhere on the Internet - it will otherwise
    simply remain in place in perpetuity.  To better illustrate this
    point, one could consider one example (of many) that there are many
    email servers continuing to attempt to query or otherwise check anti-



Livingood                Expires August 26, 2011               [Page 19]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    spam DNS blocklists which have long ago ceased to exist.

7.3.6.  Troubleshooting Implications

    The implications of DNS whitelisted present many challenges, which
    have been detailed in Section 7.  These challenges may negatively

But this is /still/ section 7.  Can you be more specific?  Or perhaps say
"throughout this section".

[JL] fixed



    affect the end users' ability to troubleshoot, as well as that of DNS
    recursive resolver operators, ISPs, content providers, domain owners
    (where they may be different from the operator of the authoritative
    DNS server for their domain), and other third parties.  This may make
    the process of determining why a server is not reachable
    significantly more complex.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

    Additional implications, should this be deployed on an ad hoc basis,
    could include scalability problems relating to operational processes,

I'm pretty sure that scaling problems for this exist in all scenarios, not just
ad hoc usage.

[JL] True. Simplified to:
"As more domains choose to implement DNS Whitelisting, and more networks become IPv6-capable and request to be whitelisted, scaling up operational processes, monitoring, and ACL updates will become more difficult. The increased rate of change and increased size of whitelists will increase the likelihood of configuration and other operational errors."

    monitoring, and ACL updates.  In particular, it seems likely that as
    the number of domains that are using DNS whitelisting increases, as
    well as the number of IPv6-capable networks requesting to be
    whitelisted, that there is an increased likelihood of configuration
    and other operational errors, especially with respect to the ACLs
    themselves.

    It is unclear when and if it would be appropriate to change from
    whitelisting to blacklisting, and whether or how this could feasibly
    be coordinated across the Internet, which may be proposed or

Actually the question of coordination is quite clear and rather fundamental:

      No.

Anyone believing otherwise needs to cite a successful example, at Internet scale
and diversity, more recently than the 1983 switch to IP (which didn't go all
that well anyhow...)

Simple, unambiguous showstoppers should be stated in a simple and direct manner.
  When there is room for debate, softer language makes sense.  Again, if the
question of coordination really is subject to debate, then the basis needs to be
stated.  (Good luck!)

[JL] That's not encouraging… Changed to:
"It is unclear when and if it would be appropriate to change from whitelisting to blacklisting. It is clear that trying to coordinate this across the Internet is likely be be impossible, so such a change to blacklisting would happen on a domain-by-domain basis (if at all)."

    implemented on an ad hoc basis when a majority of networks (or
    allocated IPv6 address blocks) have been whitelisted.  Finally, some
    parties implementing DNS whitelisting consider this to be a temporary
    measure.  As such, it is not clear how these parties will judge the
    network conditions to have changed sufficiently to justify disabling
    DNS whitelisting and/or what the process and timing will be in order
    to discontinue this practice.

    One further potential implication is that an end user with only an
    IPv4 address, using a DNS resolver which has not been whitelisted by
    any domains, would not be able to get any AAAA resource records.  In
    such a case, this could give that end user the incorrect impression
    that there is no IPv6-based content on the Internet since they are
    unable to discover any IPv6 addresses via the DNS.

7.4.  Homogeneity May Be Encouraged

    A broad trend which has existed on the Internet appears to be a move
    towards increasing levels of heterogeneity.  One manifestation of

increasing levels of heterogeneity -> more heterogeneity

[JL] fixed


(I think heterogeneity does not have 'levels'.)

Substantively:  say the nature of the heterogeneity within the initial claim.
For example, there is /less/ heterogeneity of ISPs, given industry
consolidation.  There is less heterogeneity of infrastructure equipment such as
routers.  Etc.

[JL] I have gotten lots and lots of questions related to this section, which led me to conclude that I've done a poor job stating the issue. I was dancing around it but here it is more directly in an updated section (the new 2nd  and final paragraph of this section):
"Some forms of so-called "network neutrality" principles around the world include the notion that any IP-capable device should be able to connect to a network, which seems to encourage heterogeneity. These principles are often explicitly encouraged by application providers given the reasons noted above, though some of these same providers may also be implementing DNS Whitelisting. This is ironic, as one implication of the adoption of DNS Whitelisting is that it encourages a move back towards homogeneity. This is because some implementers have expressed a preference for greater levels of control by networks over end user hosts in order to attempt to enforce technical requirements intended to reduce IPv6-related impairments. This return to an environment of more homogenous and/or controlled end user hosts could have unintended side effects on and counter-productive implications for future innovation at the edges of the network."

    this is in an increasing number, variety, and customization of end
    user hosts, including home network, operating systems, client



Livingood                Expires August 26, 2011               [Page 20]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    software, home network devices, and personal computing devices.  This
    trend appears to have had a positive effect on the development and
    growth of the Internet.  A key facet of this that has evolved is the
    ability of the end user to connect any technically compliant device
    or use any technically compatible software to connect to the
    Internet.  Not only does this trend towards greater heterogeneity
    reduce the control which is exerted in the middle of the network,
    described in positive terms in [Tussle in Cyberspace], [Rethinking
    the Internet], and [RFC3724], but it can also help to enable greater
    and more rapid innovation at the edges.

    An unfortunate implication of the adoption of DNS whitelisting may be
    the encouragement of a reversal of this trend, which would be a move

the encouragement of -> to encourage

[JL] totally changed this, as noted above.



8.1.  Implement DNS Whitelisting Universally

    One obvious solution is to implement DNS whitelisted universally, and
    to do so using some sort of centralized registry of DNS whitelisting
    policies, contracts, processes, or other information.  This potential
    solution seems unlikely at the current time.

I'm pretty sure that the only thing that is obvious about a premise of universal
adoption is that it's not practical.  Seriously.

At the least, this section needs to be less cavalier about putting this
alternative forward as a "solution", especially given the rather serious
drawbacks/problems with it.

[JL] Fixed




8.2.  Implement DNS Whitelisting On An Ad Hoc Basis

    If DNS whitelisting is to be adopted, it is likely to be adopted on

"is to be"?  I thought it already had a significant installed base.

[JL] Fixed.

    this ad hoc, or domain-by-domain basis.  Therefore, only those
    domains interested in DNS whitelisting would need to adopt the
    practice, though as noted herein discovering that they a given domain
    has done so may be problematic.  Also in this scenario, ad hoc use by
    a particular domain may be a temporary measure that has been adopted
    to ease the transition of the domain to IPv6 over some short-term
    timeframe.

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.





Livingood                Expires August 26, 2011               [Page 23]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


8.3.1.  Solving Current End User IPv6 Impairments

    A further extension of not implementing DNS whitelisting, is to also
    endeavor to actually fix the underlying technical problems that have
    prompted the consideration of DNS whitelisting in the first place, as
    an alternative to trying to apply temporary workarounds to avoid the
    symptoms of underlying end user IPv6 impairments.  A first step is
    obviously to identify which users have such impairments, which would
    appear to be possible, and then to communicate this information to
    end users.  Such end user communication is likely to be most helpful
    if the end user is not only alerted to a potential problem but is
    given careful and detailed advice on how to resolve this on their
    own, or where they can seek help in doing so.  Section 11 may also be
    relevant in this case.

    One challenge with this option is the potential difficulty of
    motivating members of the Internet community to work collectively
    towards this goal, sharing the labor, time, and costs related to such
    an effort.  Of course, since just such a community effort is now
    underway for IPv6, it is possible that this would call for only a
    moderate amount of additional work.

This 'challenge' is at the core of /all/ adoption efforts for Internet protocols
and services that entail distributed adoption.


    Despite any potential challenges, many in the Internet community are
    already working towards this goal and/or have expressed a general
    preference for this approach.

If this is not already an organized effort with a website, sponsoring
consortium, or the like, it should be.  If it is, then cite it in this doc!

[JL] Fixed. It is World IPv6 Day and the many efforts related to that.



8.3.2.  Gain Experience Using IPv6 Transition Names

    Another alternative is for domains to gain experience using an FQDN
    which has become common for domains beginning the transition to IPv6;
    ipv6.example.com and www.ipv6.example.com.  This can be a way for a
    domain to gain IPv6 experience and increase IPv6 use on a relatively
    controlled basis, and to inform any plans for DNS whitelisting with
    experience.

I do not understand what this means.

What is it for?  What are the results?  How are theyused?

[JL] Ack. This has been clarified in the –04.



9.  Is DNS Whitelisting a Recommended Practice?

    Opinions in the Internet community concerning whether or not DNS
    whitelisting is a recommended practice are understandably quite
    varied.  However, there is clear consensus that DNS whitelisting is
    at best a useful temporary measure which a domain may choose to

If that is a clear consensus, then it makes even less sense to promote the idea
of universal adoption, given the timescale needed to achieve it.


10.  Security Considerations

    There are no particular security considerations if DNS whitelisting
    is not adopted, as this is how the public Internet works today with A
    resource records.

Or rather, failure to adopt a mechanism like this or repair the underlying
problem, for those sites experiencing that problem, will result in a denial of
service, albeit not an intentional one.  Still, that's a pretty basic security
issue.


d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net