Subject: Re: Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC

From: SM <[email-masked]>
Date: Mon, 18 Apr 2011 16:58:44 -0700

At 13:51 15-04-2011, The IESG wrote:

>The IESG has received a request from the IPv6 Operations WG (v6ops) to
>consider the following document:
>- 'IPv6 AAAA DNS Whitelisting Implications'
>   <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an
>Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the

 From Section 1:

   "The fraction of users with such impaired access has been estimated
    to be roughly 0.078% of total Internet users".

That's probably "web" users.

 From the Abstract:

   "The objective of this document is to describe what the whitelisting
    of DNS AAAA resource records is, hereafter referred to as DNS
    whitelisting, as well as the implications of this emerging practice
    and what alternatives may exist."

The only alternatives listed are a few paragraphs in Section 
8.3.  After reading the draft, it's hard to say whether the problem 
should be addressed at the network level, the DNS level or whether it 
is a chicken and egg problem.  The draft seems to aim to keep 
everyone happy by covering what different parties may view as issues.

Section 3 is about "What Problems Are Implementers Trying To 
Solve".  My naive view is that:

  1. Web browser tries to connect to web site over IPv6
  2. User has to wait for a timeout to get content over IPv4
  3. Content provider sees this as a business case against adopting IPv6

An alternative is to disable IPv6 in the web browser or have a popup 
message that says "IPv6 allows you to access more web sites.  Does 
your ISP support IPv6? Y/N".

Or the workaround can be done through DNS as documented in this 
draft.  It will be interesting to see what 8.8.8.8 will do.

In Section 6:

   "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."

I suggest using DNSBLs instead of "blacklists".

As I do meet the religious requirements, I cannot take a position on 
this draft.

Regards,
-sm

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Apr 2011 12:51:05 +0300 (EEST)

>  <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an

This is an ops-dir review of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.

The document is readable and could be published as-is.  I share some of the
concerns already expressed in the document, but I think the doc strikes a
reasonable balance between the concerns and practical points.

One bigger comment:
-------------------

Section 6 on deployment scenarios seems too black and white: either it is
done ad-hoc or (completely) universally.  The latter is unfeasible.

The document should cover a middle ground which is already discussed in
[NW-Article-DNS-WL], i.e., one or more whitelisting information providers
would be used by multiple content networks.  This has many benefits compared
to completely ad-hoc model, and is feasible compared to universal model.

The "universal deployment model" proposition has created ripples throughout
the document (one such place is S 7.3.7), and I think the document might
have been clearer if that was taken out completely -- or at least, issues
related to each deployment model would be more clearly separated.

......

8.3.1. Solving Current End User IPv6 Impairments
...
    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.

... I would observe that ad-hoc whitelisting is already requiring a lot of
work from each of whitelisting providers.  Would this require more than
that?  If the alternative is to do nothing (no whitelisting, no user
impairment notification) that is clear the winner from the selfish POV. But
if the choice is between whitelisting and alerting, I don't see much
difference between the two.  Both could benefit from joint activities, but
both can also be operated in an ad-hoc fashion.

editorial:
----------

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,
    monitoring, and ACL updates.

... this could be read to imply that S 7.3.1-6 would be applicable to
universal deployment.  This is not what is meant.  Maybe clarify somewhat
like as follows:

    Previous subsections described implications that apply to both ad-hoc and
    universal deployment models.  Some additional implications are specific
    to ad-hoc deployment models, namely ...

S 7.5

    governmental, and/or cultural conflicts, given the new control point
    which has be established with DNS whitelisting.  For example, in one

s/be/been/

    [IPv6 Brokenness]
               Anderson, T., "Measuring and Combating IPv6 Brokenness",
               Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
               <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.

s/2011/2010/