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

From: SM <[email-masked]>
Date: Sat, 30 Apr 2011 12:47:52 -0700

Hi Dave,
At 16:32 29-04-2011, Dave CROCKER wrote:
>Review:
>
>Title:  IPv6 AAAA DNS Whitelisting Implications
>I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

I have this document on the list of assignments to be made.  I 
generally avoid doing a review of a document on which I have 
previously commented.  Would you like to take on the assignment?

Please do feel free to decline or else I won't ask. :-)

Best regards,
-sm

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 May 2011 16:32:27 +0200

I disagree that "whitelisting" is a reserved trademark of the anti-abuse community.  It's a general term for a list of things that are granted something.  Likewise with "blacklist" and "deny".  Which means it's perfectly appropriate for this document.

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

On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote:

> By:     D. Crocker <[email-masked]>
> Date:   29 April 2011
> 
> 
> Summary:
> 
> This draft is a discussion of a technique for resolving a dual-stack problem between IPv4 and IPv6, through the use of special DNS records.
> 
> The document appears to continue a recent use of the term 'whitelisting' that strongly conflicts with long-standing use of the term by the anti-abuse community.
> 
> The document needs to do a more careful job of introducing the problem it is solving and the explaining the way the 'whitelisting' mechanism works.
> 
> I also very strongly encourage finding a different term.
> 
> d/
> 
> 
>> 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...)
> 
> 
>>   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.
> 
> 
>> Status of this Memo
>> 
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>> 
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current Internet-
>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>> 
>>   Internet-Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>> 
>>   This Internet-Draft will expire on August 26, 2011.
>> 
>> Copyright Notice
>> 
>>   Copyright (c) 2011 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>> 
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents
>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>   publication of this document.  Please review these documents
>>   carefully, as they describe your rights and restrictions with respect
>>   to this document.  Code Components extracted from this document must
>>   include Simplified BSD License text as described in Section 4.e of
>>   the Trust Legal Provisions and are provided without warranty as
>> 
>> 
>> 
>> Livingood                Expires August 26, 2011                [Page 1]
>> 
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>> 
>> 
>>   described in the Simplified BSD License.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Livingood                Expires August 26, 2011                [Page 2]
>> 
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>> 
>> 
>> Table of Contents
>> 
>>   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>>   2.  How DNS Whitelisting Works . . . . . . . . . . . . . . . . . .  6
>>     2.1.  Description of the Operation of DNS Whitelisting . . . . .  7
>>   3.  What Problems Are Implementers Trying To Solve?  . . . . . . .  8
>>   4.  Concerns Regarding DNS Whitelisting  . . . . . . . . . . . . .  9
>>   5.  Similarities to Other DNS Operations . . . . . . . . . . . . . 12
>>     5.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . . 12
>>     5.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 12
>>   6.  Likely Deployment Scenarios  . . . . . . . . . . . . . . . . . 13
>>     6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis  . . . . . . 13
>>     6.2.  Deploying DNS Whitelisting Universally . . . . . . . . . . 14
>>   7.  Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15
>>     7.1.  Architectural Implications . . . . . . . . . . . . . . . . 15
>>     7.2.  Public IPv6 Address Reachability Implications  . . . . . . 16
>>     7.3.  Operational Implications . . . . . . . . . . . . . . . . . 17
>>       7.3.1.  De-Whitelisting May Occur  . . . . . . . . . . . . . . 17
>>       7.3.2.  Authoritative DNS Server Operational Implications  . . 17
>>       7.3.3.  DNS Recursive Resolver Server Operational
>>               Implications . . . . . . . . . . . . . . . . . . . . . 18
>>       7.3.4.  Monitoring Implications  . . . . . . . . . . . . . . . 19
>>       7.3.5.  Implications of Operational Momentum . . . . . . . . . 19
>>       7.3.6.  Troubleshooting Implications . . . . . . . . . . . . . 20
>>       7.3.7.  Additional Implications If Deployed On An Ad Hoc
>>               Basis  . . . . . . . . . . . . . . . . . . . . . . . . 20
>>     7.4.  Homogeneity May Be Encouraged  . . . . . . . . . . . . . . 20
>>     7.5.  Technology Policy Implications . . . . . . . . . . . . . . 21
>>     7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22
>>   8.  Solutions  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
>>     8.1.  Implement DNS Whitelisting Universally . . . . . . . . . . 23
>>     8.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 23
>>     8.3.  Do Not Implement DNS Whitelisting  . . . . . . . . . . . . 23
>>       8.3.1.  Solving Current End User IPv6 Impairments  . . . . . . 24
>>       8.3.2.  Gain Experience Using IPv6 Transition Names  . . . . . 24
>>   9.  Is DNS Whitelisting a Recommended Practice?  . . . . . . . . . 24
>>   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
>>     10.1. DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 25
>>     10.2. Authoritative DNS Response Consistency Considerations  . . 26
>>   11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26
>>   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
>>   13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
>>   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
>>   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
>>     15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
>>     15.2. Informative References . . . . . . . . . . . . . . . . . . 29
>>   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 31
>>   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 32
>> 
>> 
>> 
>> Livingood                Expires August 26, 2011                [Page 3]
>> 
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>> 
>> 
>>   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Livingood                Expires August 26, 2011                [Page 4]
>> 
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>> 
>> 
>> 1.  Introduction
>> 
>>   This document describes the emerging practice of whitelisting of DNS
>>   AAAA resource records (RRs), which contain IPv6 addresses, hereafter
>>   referred to as DNS whitelisting.  The document explores the
>>   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-
> 
> Really?  Not for email first?
> 
> 
>>   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
> 
> Oh.  You mean /IPv6/ whitelisting.
> 
> 
>>   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 traffice.  If that's what is meant it should be stated.  If it isn't, the statistic should be recalculated.
> 
> 
>>   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].
> 
> How or why does whitelisting affect slow performance for these folk?
> 
> 
>>   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
> 
> Oh.  The whitelisting is for resolving a conflict between AAAA and A record choices?
> 
> Normally, the term 'whitelisting' is used to refer to bypass anti-abuse mechanisms.  This appears to be for something else and it seems odd to call it whitelisting.
> 
> Note the more typical use of the term:
> 
>   <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>
> 
> It appears that some v6 folks have chosen to co-opt a distinctive and very well established anti-abuse term for an entirely different purpose.
> 
> 
> 
>>   is important to note that these major domains are motivated by a
>>   desire to maintain a high-quality user experience for all of their
>>   users.  By engaging in DNS whitelisting, they are attempting to
>>   shield users with impaired access from the symptoms of those
>>   impairments.
>> 
>>   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,
> 
> Well, it certainly suggests that there is a problem handling v4/v6 in dual stack environments cleanly.  And it certainly seems that dealing with the underlying problem would be better.
> 
> Beyond that, this appears to be a hack that is useful but not scalable.
> 
> 
>> 
>>   o  that new operational and management burdens are created,
> 
> well, yeah...
> 
> 
>>   o  and that the costs and negative implications of DNS whitelisting
>>      outweigh the perceived benefits, compared to fixing underlying
>>      impairments.
>> 
>>   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.
> 
> 
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 May 2011 08:01:01 -0700

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

Richard,

The trademark model is interesting and probably useful here.

Trademarks have context.

Search on "whitelist dns"

Since there is long-standing practice of anti-abuse use of the term for A 
records there as no doubt it would be -- and indeed is -- need to use it for 
AAAA records.

d/

-- 

   Dave Crocker

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 May 2011 17:46:54 +0200

Search on "whitelist ipv6".  Results are topical.  What's the conflict here?

On May 2, 2011, at 5:01 PM, Dave CROCKER wrote:

> Since there is long-standing practice of anti-abuse use of the term for A records there as no doubt it would be -- and indeed is -- need to use it for AAAA records.
> 
> d/
> 
> -- 
> 
>  Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 02 May 2011 09:16:47 -0700

Richard,

Oh, right.  Sorry, I thought the reference to AAAA had to do with the DNS.

Clearly, since it will only be used in the context of v6, it won't cause any 
confusion.

My own having mistaken the title of the document as being the longstanding use 
of the term for DNS Whitelisting of anti-abuse-related addresses was merely an 
exception.

d/

-- 

   Dave Crocker

---

From: John Leslie <[email-masked]>
Date: Mon, 2 May 2011 13:08:38 -0400

Richard L. Barnes <[email-masked]> wrote:
> 
> Search on "whitelist ipv6".  Results are topical.

   Indeed, folks are talking about "ipv6 whitelist" right now; and I
guess they're referring to the same thing this I-D discusses...

> What's the conflict here?

   What does "ipv6 whitelist" mean to the average reader?

   Most of the links I found were considerably less helpful than the
I-D itself. Hopefully they are discussing what this I-D specifies, but
I'm not entirely certain...
" 
" 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.

   As I read it, this says that certain DNS servers will be configured
to _not_ return AAAA records to AAAA queries by default.

   This strikes me as a really-strange transition mechanism.

   Color me thoroghly confused.

--
John Leslie <[email-masked]>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 2 May 2011 18:48:32 +0000

In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS AAAA Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to act on. ;-)
If there are recommendations on alternatives, I'm all ears.

Thanks
Jason

On 5/2/11 10:32 AM, "Richard L. Barnes" <[email-masked]> wrote:

>I disagree that "whitelisting" is a reserved trademark of the anti-abuse
>community.  It's a general term for a list of things that are granted
>something.  Likewise with "blacklist" and "deny".  Which means it's
>perfectly appropriate for this document.
>
>> This draft is a discussion of a technique for resolving a dual-stack
>>problem between IPv4 and IPv6, through the use of special DNS records.
>> 
>> The document appears to continue a recent use of the term
>>'whitelisting' that strongly conflicts with long-standing use of the
>>term by the anti-abuse community.
>> 
>> The document needs to do a more careful job of introducing the problem
>>it is solving and the explaining the way the 'whitelisting' mechanism
>>works.
>> 
>> 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...)
>> 
>> 
>> 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.
>> 
>> 
>>> Status of this Memo
>>> 
>> 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 traffice.  If that's what is meant it should be stated.  If it
>>isn't, the statistic should be recalculated.
>> 
>> 
>> Normally, the term 'whitelisting' is used to refer to bypass anti-abuse
>>mechanisms.  This appears to be for something else and it seems odd to
>>call it whitelisting.
>> 
>><http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/c
>>om.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html>
>> 
>> It appears that some v6 folks have chosen to co-opt a distinctive and
>>very well established anti-abuse term for an entirely different purpose.
>> 
>> 
>> 
>> Well, it certainly suggests that there is a problem handling v4/v6 in
>>dual stack environments cleanly.  And it certainly seems that dealing
>>with the underlying problem would be better.
>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 2 May 2011 18:55:04 +0000

Depends on a number of factors for a content provider. The more traffic a domain receives the more likely they are to consider this practice as a transition mechanism from what I have observed. This practice can give a large domain some level of control in turning on IPv6 access to their content, whereas they would lack this since they would turn it on for everyone when publishing the AAAA RR in the DNS. Once a comfort level and operational stability is achieved I would expect most domains to move away from the practice, but that is TBD. Certainly what happens on World IPv6 Day will bear on this question in important ways (when AAAA RRs are published without the use of DNS whitelisting).

Hopefully that's more over the practice than the document; if you wish to see improvements in the I-D just say so.

Thanks
Jason

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 2 May 2011 15:12:01 -0400

> to _not_ return AAAA records to AAAA queries by default.

Yes, that's what the trick does.

>    This strikes me as a really-strange transition mechanism.

Indeed.

The draft is, IMO, a little too diplomatic to say it, but what this
really comes down to is a boneheaded put-spackle-over-it answer to the
problem of previous failed transition mechanisms.

There are eyeballs out there in front of screens.  Those are the
things the content providers want to reach.

Some percentage of those eyeballs are looking at screens with bad or
misconfigured IPv6 connectivity.  But because they don't know that,
they'll ask for AAAA records in their DNS lookups, because they think
they have IPv6 connecitivity.

What the "whitelisting" (scare quotes to address Dave's objection)
trick does is refuse to answer those AAAA queries unless the operator
of the answering server has positive evidence to believe that the AAAA
query is coming from a well-run IPv6 network.  If not, the AAAA is
suppressed.  This causes the AAAA lookups to fail, which causes the
bits to flow via IPv4.  The bits get to the eyeballs, and the content
provider is happy.

That this is a completely unscalable answer to the problem that a tiny
percentage of computers on the Internet are misconfigured is something
the people pushing this "whitelisting" acknowledge.  They're going to
jump off that bridge when they get to it.  Right now, there's hardly
any IPv6 penetration, they say, so they can handle it.

I think that this sort of "whitelisting" is, to be blunt,
short-sighted and foolish, but I think it is better to have a document
that at least explains what it is.  If we had a WCP series, I'd
nominate this for inclusion.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 2 May 2011 12:23:54 -0700

> nominate this for inclusion.

Perhaps the document could include the arguments for and against this practice?  That way, someone who is new to IPv6 
deployment theory can quickly get up to speed.

I'm very much in favor of documents which say "don't do this -- but if you have to, here's how."  But they have to include enough context for someone to understand why it'd be better if they didn't.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 2 May 2011 15:38:17 -0400

> deployment theory can quickly get up to speed.

On my reading, it does.  Whether people unfamiliar with the practice
find it clear enough is another matter.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 2 May 2011 19:39:23 +0000

>Perhaps the document could include the arguments for and against this
>practice?  That way, someone who is new to IPv6
>I'm very much in favor of documents which say "don't do this -- but if
>you have to, here's how."  But they have to include enough context for
>someone to understand why it'd be better if they didn't.

In the last update I added Section 9 "Is DNS Whitelisting a Recommended
Practice?"to attempt to address the question of "should a domain do this
or not?" (see 
http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implicatio
ns-03#section-9).

If folks here and on v6ops think it is valuable, I could add a sub-section
to this which addresses recommended things an implementer should do
(transparent/published policies, SLA on decision making, etc.).

Jason

---

From: John Leslie <[email-masked]>
Date: Mon, 2 May 2011 19:44:21 -0400

Livingood, Jason <[email-masked]> wrote:
> To: John Leslie <[email-masked]>...
> 
> Depends on a number of factors for a content provider.

   Actually, no -- none of these factors make me feel it's any less than
_REALLY_ strange.

> The more traffic a domain receives the more likely they are to consider
> this practice as a transition mechanism from what I have observed.

   "Transition mechanism" is really-close to an oxymoron.

> This practice can give a large domain some level of control in turning
> on IPv6 access to their content, whereas they would lack this since
> they would turn it on for everyone when publishing the AAAA RR in the
> DNS.

   It doesn't give nearly as much control as they seem to think it does.
This blocks AAAA records, not based on the host interested in using them,
but based on some feature (IP address?) of the intermediate DNS resolver.
It's traditional to configure hosts to use two (or more) DNS resolvers
to mimimize the delays and disruptions.

   It will be very common for an end-host to alternate AAAA-requests
between one resolver which happens to be AAAA-blocked and another which
happens to be "whitelisted". I cringe in fear of taking the support
calls from such customers.

> Once a comfort level and operational stability is achieved I would
> expect most domains to move away from the practice, but that is TBD.

   I would expect a painful number of domains to forget it's there. :^(

> Certainly what happens on World IPv6 Day will bear on this question
> in important ways (when AAAA RRs are published without the use of
> DNS whitelisting).

   I predict a majority will turn off AAAA records for their regular
www.example.com on WorldIPv6Day+1.

   But that's OK: there are other ways to make progress.

   And the pressure should probably be applied to browser-software writers,
so that when an end-user finds himself IPv6-impaired, he can simply shift
to a different browser,

> Hopefully that's more over the practice than the document;

   Indeed, I _am_ more confused by the practice than the document.

   But the document is confusing enough! What does it encourage me to
_do_?

> if you wish to see improvements in the I-D just say so.

   Personally, I wish you'd do a nearly-global

s/DNS whitelisting/AAAA-blocking/

   It's a much more descriptive term.

   Also, I'd appreciate less of "this solve a transition problem" and
more of "this doesn't even do what the folks seem to think it does".

   It's arguably reasonable to AAAA-block to DNS resolvers whose
managers ask for it; but it's not at all reasonable to AAAA-block by
default. IMHO, it would be better to tell folks that ask you to
AAAA-block to switch to resolver software that can AAAA-block to
certain end-users. After all, the problem _isn't_ localized on the
DNS resolver.

   And the document does nothing to help me figure out what to do to
enable a venturesome customer to _use_ IPv6 to a site that turns on
this AAAA-blocking!

   :^( :^(

---

From: SM <[email-masked]>
Date: Tue, 03 May 2011 01:43:10 -0700

Hi Jason,
>If there are recommendations on alternatives, I'm all ears.

Repurposing a sentence from the 
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03:

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

Web content providers use a DNS tradeoff to avoid losing quality and 
money as most ISPs are reluctant to pour money into IPv6.  At least 
Comcast has a plan to provide each of their users with 
18,446,744,073,709,551,616 IPv6 addresses.

Given that draft-ietf-v6ops-v6-aaaa-whitelisting-implications has 
been reviewed by DNSOP and v6ops, and that the intended status is 
Informational, it is difficult to give it a "DNP".  RFC 3901 mentions 
"Policy Based Avoidance of Name Space Fragmentation".  The DNS 
technique used in the draft (split-view) contributes to name space 
fragmentation.

If you wanted to argue for "DNP", you could have the following text 
from the v6ops Charter at the bottom of the list:

  "IPv6 operational and deployment issues with specific protocols or
   technologies (such as Applications, Transport Protocols, Routing
   Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
   the groups or areas responsible for those protocols or technologies.
   However, the v6ops WG may provide input to those areas/groups, as
   needed, and cooperate with those areas/groups in reviewing solutions
   to IPv6 operational and deployment problems."

If you want to argue against "DNP", you can always say that you are 
merely documenting the stupid things people have to do get IPv6 deployed.

I am stupid but I am not that stupid to go and argue about a draft 
that has been blessed by DNSOP and v6ops.  :-)  Andrew Sullivan 
mentioned WCP [1].  That RFC sub-series does not exist yet.  The best 
fit is FYI.

As a comment that will not be considered as part of the Last Call, I 
would have given the draft a DNP if I had to review it.  I don't have 
to say that as the draft already got a five DISCUSS rating.  That 
won't prevent a well-known search engine from deploying the mechanism 
described in this draft.  Someone might come to me and say that 
"well-known search does this, why can't you do it; it's even a 
RFC".  I'll read the Mathematical Principles of Natural Philosophy to 
see whether I can find an answer to that. :-)

On an unrelated note, there was a mistake in the message I posted 
previously [2].  The last sentence should be read as:

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

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg66311.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg66203.html

---

From: Erik Kline <[email-masked]>
Date: Tue, 3 May 2011 00:28:12 +0900

I'm having a hard time thinking of adequate alternatives terms (but
this purely a personal failing, I'm sure).  Recommendations for other
words?

---

From: Tina Tsou <[email-masked]>
Date: Mon, 02 May 2011 12:03:52 -0700

Hi Jason,
Perhaps an experience for preparing for World IPv6 Day could be added as
appendix.

We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Livingood, Jason
Sent: Monday, May 02, 2011 11:55 AM
To: John Leslie; Richard L. Barnes; Dave CROCKER
Cc: [email-masked]; IETF Discussion
Subject: Re: [v6ops] Review of:
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

 
Depends on a number of factors for a content provider. The more traffic a
domain receives the more likely they are to consider this practice as a
transition mechanism from what I have observed. This practice can give a
large domain some level of control in turning on IPv6 access to their
content, whereas they would lack this since they would turn it on for
everyone when publishing the AAAA RR in the DNS. Once a comfort level and
operational stability is achieved I would expect most domains to move away
from the practice, but that is TBD. Certainly what happens on World IPv6 Day
will bear on this question in important ways (when AAAA RRs are published
without the use of DNS whitelisting).

Hopefully that's more over the practice than the document; if you wish to
see improvements in the I-D just say so.
 
Thanks
Jason

---

From: "John Mann (ITS)" <[email-masked]>
Date: Tue, 3 May 2011 17:41:46 +1000

> If there are recommendations on alternatives, I'm all ears.

I would prefer a name that indicated that it was the resolvers that are
whitelisted.
>From the draft:

> >>>   resource records to DNS resolvers which are not on the whitelist.
>  ...
>

The AAAA records aren't thr things being whitelisted.

How about "IPv6 DNS Resolver Whitelisting"
or "IPv6 AAAA DNS Resolver Whitelisting"

    John

---

From: james woodyatt <[email-masked]>
Date: Tue, 03 May 2011 10:20:51 -0700

On May 2, 2011, at 08:28 , Erik Kline wrote:
> 
> I'm having a hard time thinking of adequate alternatives terms (but this purely a personal failing, I'm sure).  Recommendations for other words?

The word "enclave" springs to mind.  We are talking about the use of "DNS enclaves" for serving AAAA resources rather than serving them to the public DNS horizon.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Doug Barton <[email-masked]>
Date: Wed, 04 May 2011 16:56:50 -0700

On 05/03/2011 01:43, SM wrote:
> I am stupid but I am not that stupid to go and argue about a draft that
> has been blessed by DNSOP and v6ops.

"Blessed" is rather strong. There are a non-zero number of people in 
both groups (of which I am one) who don't like the draft, and don't 
agree that documenting bad ideas is its own virtue.

The other reason that I personally opposed the draft is that it's not 
going to make 1 tiny bit of difference. The people who are going to do 
this are going to do it, regardless of what the IETF says about its 
relative merit. Thus publishing it is just a waste of everyone's time. 
However, the rough consensus was to move it forward, so here we are.

Meanwhile, the discussion about whether or not to call this 
"whitelisting" is pointless. The term is already well-established.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: SM <[email-masked]>
Date: Mon, 09 May 2011 12:13:46 -0700

Hi Doug,
>agree that documenting bad ideas is its own virtue.

If I have to go by the document shepherd write-up, only one person 
expressed discontent about this proposal, hence the above comment.

[snip]

>"whitelisting" is pointless. The term is already well-established.

No comment for obvious reasons.

Regards,
-sm

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 May 2011 17:25:45 -0700

Hi, all,

Although this is a minor point, it's also easy to address:

On 5/4/2011 4:56 PM, Doug Barton wrote:
...
> "whitelisting" is pointless. The term is already well-established.

That's true, but equally true that the terms for disk drives used to use 
terms "master" and "slave" - equally antiquated and potentially racially 
charged terms. FWIW, the Los Angeles County banned the terms in 2003 
when used for various purposes - including technology, preferring 
"primary" and "secondary", in specific. The terms don't even appear in 
the ATA spec after version 1.

For the terms in this doc, alternatives that do not require explanation 
(and aren't potentially racially charged) include "permit list" and 
"deny list".

Joe

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 16 May 2011 14:27:53 -0700

On May 11, 2011, at 5:25 PM, Joe Touch wrote:

> That's true, but equally true that the terms for disk drives used to use terms "master" and "slave" - equally antiquated and potentially racially charged terms. FWIW, the Los Angeles County banned the terms in 2003 when used for various purposes - including technology, preferring "primary" and "secondary", in specific. The terms don't even appear in the ATA spec after version 1.
> 
> For the terms in this doc, alternatives that do not require explanation (and aren't potentially racially charged) include "permit list" and "deny list".

the blacklist originates with charles the 2nd. it has no racial connotations in that context.

see also the death of cromwell and the resortation.

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 17:37:13 -0400

On 5/16/2011 5:27 PM, Joel Jaeggli wrote:
>> (and aren't potentially racially charged) include "permit list" and "deny
>> list".
>

1. Changing times often call for changed vocabulary.

2. The "established" label is semantically wrong, since the construct of 
white/black for lists refers to priviledge or goodness.  Which is "good", v6 or 
v4?  The answer is completely arbitrary and, therefore, renders the term neither 
intuitive not really appropriate.

3. When the IETF processes work with a history, it often changes labels.

4. And let's not forget the name conflict with anti-spam DNS-based whitelists. 
(It's probably close enough to qualify as trademark infringement if this were a 
trademark case)

How much longer does this list need to be to justify choosing better labels for 
this v6 dual-stack transition hack?

d/

-- 

   Dave Crocker

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 16 May 2011 15:08:24 -0700

> 1. Changing times often call for changed vocabulary.

which is fine, the rational stated is false to fact.

> 2. The "established" label is semantically wrong, since the construct of white/black for lists refers to priviledge or goodness.  Which is "good", v6 or v4?  The answer is completely arbitrary and, therefore, renders the term neither intuitive not really appropriate.

> 4. And let's not forget the name conflict with anti-spam DNS-based whitelists. (It's probably close enough to qualify as trademark infringement if this were a trademark case)

Really? I can find numerous examples of whitelisting that don't involve spam. 

> How much longer does this list need to be to justify choosing better labels for this v6 dual-stack transition hack?

returning different sets of resource records on the basis of the orgin of a query ala split horizon is not exactly new ground.

By my observation, what is being done, satisfactorily 
meets the dictionary definition of a whitelist. the term was uncontroversial in the dicussion leading up to the wglc. If it's really inapropiate that's cool but I'm frankly not convinced.

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 May 2011 18:12:34 -0400

On 2011-05-11, at 20:25, Joe Touch wrote:

> FWIW, the Los Angeles County banned the terms in 2003 when used for various purposes - including technology, preferring "primary" and "secondary", in specific. The terms don't even appear in the ATA spec after version 1.

I believe that story may be apocryphal. e.g. <http://www.cnn.com/2003/TECH/ptech/11/26/master.term.reut/> (one of the few references I could find in a hurry that actually quote anybody from the county):

>> "I do understand that this term has been an industry standard for years and years and this is nothing more than a plea to vendors to see what they can do," [Sandoval] said. "It appears that some folks have taken this a little too literally."
>> 
>> Sandoval said that he had already rejected a suggestion that the county stop buying all equipment carrying the "master" and "slave" labels and had no intention of enforcing a ban on such terms with suppliers.

According to that article, Joe Sandoval was the division manager of purchasing and contract services at the time. Not that this is particularly on-topic for anything (and I'm no expert, and am very happy to concede that my amateur sleuthing has led me down the garden path).

For what it's worth, there is no shortage of examples of the use of "master" and "slave" in the DNS in Los Angeles county. In that particular context "primary" and "secondary" are particularly poor choices of terminology (in my opinion), since from the point of view of a DNS requestor master/primary and slave/secondary servers are simply instances of authoritative servers and no preference or priority ought to be inferred (masters are not prioritised above slaves or even identifiable as such; master/slave denotes the control plane distribution of zone data only).

Joe

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 18:21:44 -0400

> which is fine, the rational stated is false to fact.

But you do not seem to be refuting the point /I/ am making, which that the fact 
that the term has some established practice now does not automatically mean than 
it /must/ be retained.

>> 4. And let's not forget the name conflict with anti-spam DNS-based
>> whitelists. (It's probably close enough to qualify as trademark
>> infringement if this were a trademark case)
>

This has been explored before.  Do a google on DNS whitelist.  Look for dominant 
use, not stray exceptions.

> returning different sets of resource records on the basis of the orgin of a
> query ala split horizon is not exactly new ground.

1. It is not previously standardized and I believe it is not documented in an RFC.

2. It is typically a split-DNS private/public mechanism.

The draft is quite clear about exploring this topic in order to pursue common 
behaviors.  That's standardization (eventually).

> By my observation, what is being done, satisfactorily meets the dictionary
> definition of a whitelist. the term was uncontroversial in the dicussion

Not this dictionary:

    <http://dictionary.reference.com/browse/whitelist>

nor this one:

    <http://www.webopedia.com/TERM/W/whitelist.html>

and neither of the main-stream examples cited here:

    <http://www.thefreedictionary.com/white+list>

> leading up to the wglc.

The working group is what statistical research methodology calls a biased sample...

d/

-- 

   Dave Crocker

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 May 2011 18:28:35 -0400

Hi Dave,

I take no position on whether it's in good taste to use the word "whitelist" in this particular instance or in general, but

> 1. It is not previously standardized and I believe it is not documented in an RFC.

the term appears to have some precedent in the RFC series (see <http://www.google.com/search?q=whitelist+rfc+site:rfc-editor.org>, which includes such contexts as DNS, mail, SDP, Atom, v4 and v6 network operations and SIP), and

> 2. It is typically a split-DNS private/public mechanism.

No.

Joe

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 18:33:45 -0400

On 5/16/2011 6:28 PM, Joe Abley wrote:
> the term appears to have some precedent in the RFC series (see<http://www.google.com/search?q=whitelist+rfc+site:rfc-editor.org>, which includes such contexts as DNS, mail, SDP, Atom, v4 and v6 network operations and SIP), and

silly me, to have forgotten John's effort to document long-establishedn 
anti-spam list publication through the DNS, that the IESG would not allow to 
have made a standard.

An ironic example, given the current thread.

>> 2. It is typically a split-DNS private/public mechanism.

No doubt you can point to IETF documentation or other related, formal 
documentation of this?

(By the way, I'm not saying it's not done, merely that it seems not to have been 
documented in the fashion the current draft is attempting.  Documentation 
history matters, for this sort of thread.)

d/

-- 

   Dave Crocker

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 May 2011 18:37:11 -0400

On 2011-05-16, at 18:33, Dave CROCKER wrote:

> No doubt you can point to IETF documentation or other related, formal documentation of this?

No, and I'm not sure why that's relevant. There's no shortage of examples of addresses encoded in the DNS which can be (and are) used as whitelists. By "typically" did you mean "theoretically"? :-)

Joe

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 16 May 2011 15:44:23 -0700

On May 16, 2011, at 3:21 PM, Dave CROCKER wrote:
> The draft is quite clear about exploring this topic in order to pursue common behaviors.  That's standardization (eventually).

rfc 1919 didn't result in the standardization of split horizon dns either so I'm not sure what I'm supposed to conclude from that.

The criticicsm with the name of the draft  doesn't seem to have anything to do with criticism of documenting the practice.

> The working group is what statistical research methodology calls a biased sample...

Will we be revising dkim rfc 4871 to explictly define whitelist as dns name based whitelist thereby replacing the existing two usages of the term (which involve explicitly allowing delivery on the basis of orign), or was the term appraise in 2009 but not now?

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 18:49:41 -0400

On 5/16/2011 6:44 PM, Joel Jaeggli wrote:
> Will we be revising dkim rfc 4871 to explictly define whitelist as dns name
> based whitelist thereby replacing the existing two usages of the term (which
> involve explicitly allowing delivery on the basis of orign), or was the term
> appraise in 2009 but not now?

how is non-normative discussion text in rfc 4871 relevant?

Perhaps that also means that all RFC references to cron are required to define 
the term?

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Mon, 16 May 2011 17:34:22 -0700

At 15:44 16-05-2011, Joel Jaeggli wrote:
>Will we be revising dkim rfc 4871 to explictly define whitelist as 
>dns name based whitelist thereby replacing the existing two usages 
>of the term (which involve explicitly allowing delivery on the basis 
>of orign), or was the term appraise in 2009 but not now?

There is on-going work on RFC 4871.

Quoting the Abstract section of RFC 5782:

   "This memo documents the structure and usage of DNS-based blacklists
    and whitelists, and the protocol used to query them."

 From Abstract section of 

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

Maybe this could be called "DNS Seal Team 6".

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 21:46:33 -0400

> Maybe this could be called "DNS Seal Team 6".

Well, apparently that would be /actual/ trademark infringement, with Disney.

d/
-- 

   Dave Crocker

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 May 2011 05:45:54 +0200

On May 17, 2011, at 12:49 AM, Dave CROCKER wrote:

> Perhaps that also means that all RFC references to cron are required to define the term?

Speaking as and for myself...

I speak English. As a result, I understand that the word "run" has multiple meanings. If the speaker is looking at a stocking, I understand him or her to be talking about a "run" in a stocking; if we are at a baseball game, I automatically understand that "runs" compare with "hits" and "errors". In fact most words have multiple meanings and have to be understood in context.

In this case, the draft is talking about a particular variety of DNS service. One might call is "DNS Whitelisting" when the context isn't clear, but I think in this case the context is clearly not DKIM. The common thread it the phrase is that a whitelist identifies those deemed acceptable, as compared to a blacklist identifying those deemed unacceptable within the context.

Personally, I think this discussion is getting a little strange. It reminds me of a rabbi's discussion of what constitutes work and therefore may not be done on the sabbath.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 May 2011 10:04:26 +0100

Fred Baker <[email-masked]> wrote:
>
> In this case, the draft is talking about a particular variety of DNS
> service. One might call is "DNS Whitelisting" when the context isn't
> clear, but I think in this case the context is clearly not DKIM.

The problem is that the specific phrase "DNS whitelist" is already used in
the anti-spam world, so it would be helpful if IPv6 resolver whitelists
used a different descriptive phrase.

The anti-spam blacklist/whitelist terminology is often quite poor. I think
it is clearer to talk about what is listed (as in URIBL) rather than how
the list is published (DNSBL) since the latter doesn't immediately explain
how the list is supposed to be used. See for example the cautionary note
at http://www.spamhaus.org/dbl/

In the case at hand, the list does not contain AAAA RRs as the abstract
suggests, it contains IPv6-capable resolvers. The whitelist isn't
published in the DNS, so it doesn't match the existing use of the phrase
"DNS whitelist".

So I suggest retitling the document "IPv6 DNS resolver whitelisting" and
revising the terminology throughout to match. e.g.

   This document describes the emerging practice of whitelisting of IPv6
   capable DNS resolvers, to determine which resolvers may be sent AAAA
   resrource records. This technique is referred to as IPv6 whitelisting.
   The document explores the implications of this emerging practice are
   and what alternatives may exist.

   The practice of IPv6 whitelisting appears to have first been used by
   major web content sites [...]

   As a result of this impairment affecting end users of a given domain,
   a few major domains have either implemented IPv6 whitelisting or are
   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
   When implemented, IPv6 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
   is important to note that these major domains are motivated by a
   desire to maintain a high-quality user experience for all of their
   users.  By engaging in IPv6 whitelisting, they are attempting to
   shield users with impaired access from the symptoms of those
   impairments.

etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

---

From: Scott Schmit <[email-masked]>
Date: Tue, 17 May 2011 08:02:24 -0400

On Tue, May 17, 2011 at 05:45:54AM +0200, Fred Baker wrote:
> Personally, I think this discussion is getting a little strange. It
> reminds me of a rabbi's discussion of what constitutes work and
> therefore may not be done on the sabbath. 

I agree. Next thing you know, they'll be telling us that "spam" doesn't
refer to Hormel's canned meat product!

That said, Tony's suggestion of "IPv6 whitelist" (and associated
definition) seems fair to me (especially since it's actually the
resolvers rather than the records that are being whitelisted). That
said, the shorthand will be just as confusing to some, since if
"whitelist" really is wedded to spam in your mind, "IPv6 whitelist" will
mean "spam whitelist that uses IPv6" (whatever that means).

Personally, I don't have this problem. I've always understood whitelists
and blacklists to be generic problem-solving tools that happen to be
applied to the spam filtering problem. I'm confident that people who
didn't before will quickly adjust to the terms being used more broadly,
just as they did with "spam" (and "computer").

-- 
Scott Schmit

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 May 2011 15:32:12 +0100

> just as they did with "spam" (and "computer").

Yes.

Tony.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 17 May 2011 08:27:08 -0700

On May 16, 2011 11:41 PM, <[email-masked]> wrote:
>
> > > How much longer does this list need to be to justify choosing better
labels for this v6 dual-stack transition hack?
> >
> > returning different sets of resource records on the basis of the orgin
of a query ala split horizon is not exactly new ground.
> > meets the dictionary definition of a whitelist. the term was
uncontroversial in the dicussion leading up to the wglc. If it's really
inapropiate that's cool but I'm frankly not convinced.
>
> Agreed. I see no good reason to change the use of "whitelist". Let's
> move on.
>

+1 for moving on

Cb
> Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Tue, 17 May 2011 08:41:08 +0200 (CEST)

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 May 2011 09:26:19 -0700

On 5/17/2011 8:27 AM, Cameron Byrne wrote:
>
> On May 16, 2011 11:41 PM, <[email-masked] <mailto:[email-masked]>>
> wrote:
>  >
>  > > > How much longer does this list need to be to justify choosing
> better labels for this v6 dual-stack transition hack?
>  > >
>  > > returning different sets of resource records on the basis of the
> orgin of a query ala split horizon is not exactly new ground.
>  > >

I'm OK if there's consensus not to change it, but the wider scope of 
IETF LC and cross-area review is exactly to catch things that the WG didn't.

Joe

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 May 2011 12:46:58 -0400

> IETF LC and cross-area review is exactly to catch things that the WG 

+1

-- 
Hector Santos, CTO
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 May 2011 12:51:58 -0400

>> Will we be revising dkim rfc 4871 to explictly define whitelist as dns 
>> name based whitelist thereby replacing the existing two usages of the term 
>> (which involve explicitly allowing delivery on the basis of orign), or was 
>> the term appraise in 2009 but not now?
> 

The beauty of RFCs is its merger of functional and technical writing 
for a multi-discipline audience environment.

Ideally, the writer should find a term that is *universally" 
understood.  On the other hand, at times "Being Specific Is Terrific." 
In this case with DKIM, the "cron" usage in MLM I-D (IMO) was 
inconsistently applied; may be helpful for one audience group, but not 
others.

For "DNS Whitelisting," IMV, it is more universal, although it might 
be come with different perspectives and motivations.  For example, the 
irony (as I read the documents) is that it is based on faults 
occurring of the network - using expected failure as a form to 
filtering out the incompatibilities - the "bad". In that vain, we have 
a form of "whitelisting."

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 08:27:35 +1000

In message <[email-masked]>, Tony F
> published in the DNS, so it doesn't match the existing use of the phrase

No.  It contains just resolvers.  All the resolvers in the world
should be capable of resolving AAAA records if they followed RFC
1034.  It was clear enough that unknown == opaque blob in terms of
actually resolving data.  What wasn't clear was how to load and
display the data in the opaque blobs but once the data was in the
system moving it around shouldn't have been a problem.

A IPv6 capable resolver uses IPv6 as a transport.  A IPv6 capable
resolver may do its own AAAA lookups.  A IPv6 capable nameserver
may *not* even be able to decode AAAA presentation format.  It may
just be being handed blobs of data.  AAAA doesn't require any special
handling in a nameserver.

> revising the terminology throughout to match. e.g.

"DNS resolver whitelisting for AAAA resolution" describes what is being
talked about.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 15:51:28 +0000

[JL] Oops! Thanks for noticing this – I have corrected it in the Abstract and Introduction (in my upcoming –04 update).

Thanks for catching this,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 18:24:53 +0000

Thank you for your thorough review, Dave. Changes will be made in an upcoming –04 revision. Some more specific comments can be found inline below.

Thanks!
JL

PS – I have at least one other email from you in my queue for this I-D – I've not forgotten about it. :-)

On 4/29/11 7:32 PM, "Dave CROCKER" <[email-masked]<mailto:[email-masked]>> wrote:

Review:

By:     D. Crocker <[email-masked]<mailto:[email-masked]>>
Date:   29 April 2011

Summary:

This draft is a discussion of a technique for resolving a dual-stack problem
between IPv4 and IPv6, through the use of special DNS records.

The document appears to continue a recent use of the term 'whitelisting' that
strongly conflicts with long-standing use of the term by the anti-abuse community.

The document needs to do a more careful job of introducing the problem it is
solving and the explaining the way the 'whitelisting' mechanism works.

[JL] There's been a great deal of discussion on the mailing list about this. While it appears the consensus is to leave it as-is, your point is well noted and I have listed this in the Open Items list of the –04 draft and will be consulting with the WG chairs for direction on the matter.

d/

Abstract

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?

[JL] You are quite correct. Another reviewer also noted my error in this sentence and it is corrected in the –04 version.

Comcast's own considerable expertise notwithstanding, has this doc been vetted
with a range of organizations that actually DO whitelisting?

[JL] Folks from organizations that perform or are considering IPv6 DNS whitelisting have provided feedback on the draft, which has been incorporated into previous versions. Additional feedback has been shared which will be in the –04 revision.

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] It has not specifically been sent to groups like MAAWG, as I think this form of DNS server-related whitelisting is different from mail server whitelisting. I can certainly do so, but I'm not sure those groups will be interested as it is not particularly anti-abuse related.

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.

[JL] You are doing a good job illustrating the confusion over the use of the term 'whitelisting'. ;-) The target is actually not A/A tech and ops personnel, since the draft is specifically related to the IPv6 transition and not A/A or even messaging.

<snip>

1.  Introduction

[JL] You now get a +2 for further illustrating the potential for confusion over the terms. ;-) But I'm referring specifically to this (which is how the updated –04 text reads):
"whitelisting of DNS recursive resolvers in order to limit AAAA resource records responses"

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
traffice.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated.

[JL] Not sure what you mean… I'm simply citing a statistic shared by a major website, which appears to be based on a very large set of users from around the world (from many networks). I agree it is a small percentage (and it appears to be shrinking — to be confirmed on World IPv6 Day). One of the reactions to the practice is often that it is a lot to go through for such a small percentage of users. Of course, it is now also apparent that the –03 did not adequately summarize all of the motivations for the practice and so the –04 update will list some additional ones relating to the desire to incrementally add IPv6 traffic, gradually mature IPv6 routes and operational procedures, etc. So it is my hope that a fuller picture of the motivations will emerge in the –04 update.

[JL] If an end user has an IPv6-related impairment, they may only have an IPv4 address but the mere fact of seeing a AAAA RR response will cause them to have no access or very slow access (waiting through various client timeouts, which most users will not do) to the FQDN that had a AAAA RR. So in such cases, whitelisting is used so that these impaired users never see the AAAA RR in the response.

Normally, the term 'whitelisting' is used to refer to bypass anti-abuse
mechanisms.  This appears to be for something else and it seems odd to call it
whitelisting.

[JL] You are now up to a +3 on illustrating this point. ;-) I'm going to stop counting now, because you are getting too good it it. In all seriousness, I have recorded this as one of the main open issues to be sorted out on the draft with the WG chairs. (And as you know I'm quite familiar with it's usage in the email area.)  :-)

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

It appears that some v6 folks have chosen to co-opt a distinctive and very well
established anti-abuse term for an entirely different purpose.

[JL] BTW, don't shoot the messenger! ;-) I'm just documenting what's the current term being used.

Well, it certainly suggests that there is a problem handling v4/v6 in dual stack
environments cleanly.  And it certainly seems that dealing with the underlying
problem would be better.

[JL] I believe even the implementers agree with you there. I think it was Vint to may have called this useful "temporary scaffolding" but conceded that it really doesn't scale over the long-term.

well, yeah...

--

   Dave Crocker

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 18:39:15 +0000

Hi John - Thanks for the detailed review. I'm planning a -04 update soon, FWIW.

Specific responses inline below.

Thx,
Jason

On 5/2/11 7:44 PM, "John Leslie" <[email-masked]<mailto:[email-masked]>> wrote:

Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:
To: John Leslie <[email-masked]<mailto:[email-masked]>>...
As I read it, this says that certain DNS servers will be configured
to _not_ return AAAA records to AAAA queries by default.
This strikes me as a really-strange transition mechanism.
Depends on a number of factors for a content provider.

[JL] Quite so, and many in the WG feel it is difficult to use the resolver as a proxy for end use host IPv6-related impairment. Nevertheless, implementers feel it is good enough and the best available mechanism, and works reliably enough for their (temporary) use.

[JL] You and me both!!  ;-)

[JL] Fair enough – which is why the 'risk of operational momentum' has been noted in the I-D. I don't know if it'll happen with this practice, but it would not be the first time that a temporary mechanism becomes a foundational one.

[JL] To some extent this is expected — everyone will want to do some data analysis afterwards before they make a decision on what to do next. But certainly Heise Online (as cited in the I-D) and others feel the risk was low enough on their domains to go ahead and publish a AAAA RR. Every domain will be different and make the decision on their own.

[JL] Suggest I simplify the document, I'm sure. ;-) I've made some effort to do this for the –04 version based on all the feedback on –03. I'm also planning a top-to-bottom simplification after the –04.  So, point well-taken.    :-)

[JL] The naming of the practice is noted as an Open Item in the draft, so I'll be discussing that with the WG chairs.

   :^( :^(

[JL] All good feedback – thanks!

Jason

--
John Leslie <[email-masked]<mailto:[email-masked]>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 18:58:15 +0000

Hi – Thanks for the feedback and see a few selected responses inline below. A –04 update is coming soon.

Thanks
JL

On 5/3/11 4:43 AM, "SM" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jason,

[JL] What has become more apparent since the –03 draft is that it is not just about the impairment level. Even (or perhaps especially) if every ISP was 100% dual stack, some large domains would still want or need a mechanism to incrementally control the addition of IPv6 traffic to their domain. I have tried to add some new text to the –04 update to better explain this on behalf of implementers or potential implementers.

[JL] Yup.

[JL] I came at this from the perspective of someone who had a bad experience with whitelisting and was extremely concerned by all of the implications if it became a long-standing practice (see an early document here, http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf). As a WG document the consensus was to make sure that the motivations were documented, as well as the potential implications.  In my personal opinion, I can understand why some domains may choose to adopt the practice and I may do the same in their situation. At the same time, I hope as few domains as possible do this and that it is as short-lived as possible. Then again, if the Internet crashes and burns on World IPv6 Day, then who knows what will happen.

Regards,
-sm