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

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:

> 
> Review:
> 
> Title:  IPv6 AAAA DNS Whitelisting Implications
> I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
> 
> 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: 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: "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: "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: "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: 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: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Tue, 3 May 2011 10:17:49 -0400

> or "IPv6 AAAA DNS Resolver Whitelisting"

Well, I guess if we're going to discuss changing the name from what it
had been (which I was fine with), then it should be to something that
accurately reflects what is being discussed. The whitelisting is of DNS
Resolvers that are using DNSv4 protocol, and not "IPv6 DNS" Resolvers or
"IPv6 AAAA DNS" Resolvers. The purpose of the whitelisting is to
determine which DNSv4 Resolvers are sent AAAA records in a response.

So, maybe "DNSv4 Resolver Whitelisting" (short name) or "DNSv4 Resolver
Whitelisting for Inclusion of AAAA Record in Response" (longer name)

Barbara

---

From: Erik Kline <[email-masked]>
Date: Tue, 3 May 2011 23:34:21 +0900

DNSv6 is theoretically in scope as well.  (i.e. we would include IPv6
prefixes in our resolver ACLs if [and when] we serve authoritative DNS
over v6)

On 3 May 2011 23:17, STARK, BARBARA H (ATTSI) <[email-masked]> wrote:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "STARK, BARBARA H (ATTSI)" <[email-masked]>
Date: Tue, 3 May 2011 11:15:51 -0400

> prefixes in our resolver ACLs if [and when] we serve authoritative DNS

That's interesting. I don't think the current draft really covers that case. Would this still be for the purpose of determining whether or not to send AAAA records?

I don't think that the justifications listed in the draft are sufficient to explain why IPv6 prefixes might be included in the whitelist. The justifications currently seem to center around "broken IPv6 implementations" that cause bad user experience when client devices try to use AAAA records because they think they have IPv6 connectivity but they really don't; and ISPs that want to limit IPv6 traffic when they turn up IPv6, so they like the fact that AAAA records aren't returned in many cases. I haven't heard anyone describe IPv6 brokenness in the context of clients that successfully use DNSv6 (where currently there seems to be a good correlation between the ability to do DNSv6 and to make good use of AAAA records). I also don't think that IPv6 addresses for DNS resolvers are going to be something deployed early on by ISPs who feel the need to limit IPv6 traffic. There are still so many clients that are unable to be automatically given IPv6 addresses for doing DNS, that it just isn't a priority. Could you explain the justifications for IPv6 prefixes in these DNS resolver whitelists? And would this be part of a long-lived whitelisting strategy? The current document seems to suggest the need for these whitelists might die out once good-working IPv6 connectivity becomes the norm. But if IPv6 prefixes are included, then that may not be right.

So I guess this all brings up the following questions in my mind:
1. Is there a need to expand the draft to include whitelisting of DNS resolvers for purposes other than whether or not to include AAAA records in the response?
2. Is there a need to expand the draft to include explicit discussion (justification, etc.) for whitelisting of IPv6 prefixes of DNS resolvers?

Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 May 2011 17:20:12 +0200

On Tue, May 3, 2011 at 5:15 PM, STARK, BARBARA H (ATTSI) <[email-masked]>wrote:

> I haven't heard anyone describe IPv6 brokenness in the context of clients
> that successfully use DNSv6 (where currently there seems to be a good
> correlation between the ability to do DNSv6 and to make good use of AAAA
> records).
>

A client could use DNSv4 to talk to a recursive resolver which would then
send the query to the auth server over IPv6. That would be broken.

---

From: Erik Kline <[email-masked]>
Date: Wed, 4 May 2011 00:26:08 +0900

There's a lot the draft doesn't discuss.

Google is the only entity actively doing this right now, though Akamai
has announced that they are doing it (auto-discovering what's safe to
add to a whitelist), and both Facebook and Yahoo have expressed
interest in doing this (Facebook has already begun whitelisting
actually).

AFAIK none of use have contributed substantially to this document, nor
do I have the time to fix all the things that would need fixing (I'd
just write a new doc and don't even have the time to do that).

IMHO, this document is not a real discussion of whitelisting mechanics
and motivations.  It is, rather, a harangue against its use, despite
the fact that it is, and may remain for some period (which we all do
want to be as short as possible), an operational reality/necessity.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 May 2011 18:35:51 +0200

> want to be as short as possible), an operational reality/necessity.

Right. For us (Google - but I think a lot of large website operators are in
the same boat), whitelisting is the only possible option for IPv6
deployment, period. Subjecting hundreds of thousands of users to breakage is
simply not an option, so while we don't particularly like the disadvantages
of whitelisting, it's much, much better than doing nothing.

We don't think that the draft is a balanced assessment of the situation, but
at the same time, we don't have time to contribute to it, because we'd much
rather be working on deployment, services, and operational concerns (e.g.,
6to4 deprecation) rather than discussing something that for us is
unavoidable. So we find ourselves in the situation that we don't really
support the text but don't have time to influence it, and since we don't
feel it's fair to simply attack the text without contributing, we're simply
letting the document run its course.

As Erik has noted, Google and Facebook are employing whitelisting, and Yahoo
and Akamai have publicly announced their intention to do it. In a sense,
it's just like DNS-based load-balancing. The vast majority of websites don't
use it, but a lot of the very large ones do.

Cheers,
Lorenzo

---

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: Pekka Savola <[email-masked]>
Date: Tue, 3 May 2011 20:24:03 +0300 (EEST)

> prefixes in our resolver ACLs if [and when] we serve authoritative DNS

I'm not sure I follow this reasoning.  I may be missing something.

You'd need to add AAAA glue for your authoritative DNS servers. But 
then DNSv6 lookups would end up being used by those recursive 
resolvers that are broken.

So, if one employs aaaa-whitelisting, then it logically seems to 
follow that the authoritative servers must not have AAAA glue records.

I suppose you could omit AAAA glue records from the first tier of auth 
servers, and have a chain of servers where the next tier could also 
offer AAAA and v6 records for those whitelisted, but AFAICS these 
should never end up in glue.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 3 May 2011 17:49:26 +0000

There have been a few email threads on the name of the practice described in the document, which bears directly on the document name.

The title is currently:
IPv6 AAAA DNS Whitelisting Implications

Discussion here (mainly from John Mann's most recent note) have led to a suggestion to consider these alternatives:
1 - IPv6 DNS Resolver Whitelisting Implications
2 - IPv6 AAAA DNS Resolver Whitelisting Implications

I'll take this question up with the chairs for direction.

Thanks
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 3 May 2011 17:53:14 +0000

On 5/3/11 10:34 AM, "Erik Kline" <[email-masked]<mailto:[email-masked]>> wrote:

Erik is correct – the concept is that a resolver's IP addresses, whether they are IPv4 or IPv6 addresses, could be on a whitelist in the authoritative DNS. I will add some text to the –04 version to make this more clear.

Thanks
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 3 May 2011 18:05:38 +0000

On 5/3/11 11:26 AM, "Erik Kline" <[email-masked]<mailto:[email-masked]>> wrote:

[JL] Feel free to note those and send them to me if you wish, for inclusion of an upcoming version.

[JL] Yes, I'd note the same companies. I think some others are in a wait and see mode right now, assessing whether or not they should whitelist. It is possible that experience on World IPv6 Day will help inform the decisions of some of those others as well (real data is always good).

[JL] You send written feedback to me (and maybe the list as well) and I incorporated that feedback into the –01 document (as mentioned in the revision notes). One of my co-workers also provided feedback that informally incorporated some of your views that I addressed in the –02 version. If you have additional feedback, please feel free to send it. And, as you noted, anyone can write an Internet Draft. ;-)

[JL] My personal perception is not that it is a harangue; I actually took pains to be balanced and explain motivations and not rant and I sincerely regret that you may feel otherwise. If you have specific feedback on areas where more of the motivations can be explained more fully I am all ears. :-)

Thanks,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 3 May 2011 18:45:02 +0000

On 5/3/11 12:35 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:

Right. For us (Google - but I think a lot of large website operators are in the same boat), whitelisting is the only possible option for IPv6 deployment, period. Subjecting hundreds of thousands of users to breakage is simply not an option, so while we don't particularly like the disadvantages of whitelisting, it's much, much better than doing nothing.

[JL] I do not disagree and have attempted to incorporate this thinking into the most recent version of the I-D. Among other things it says what is noted below. Please advise if you desire additional text or some specific changes to better explain this. (As I am working on the –04 now I will contemplate that as well.)

…In particular, some major domains view DNS whitelisting as one of the few practical and low risk approaches enabling them to prepare for the transition to IPv6.
…major domains may find DNS whitelisting a beneficial temporary tactic in their transition to IPv6. Such temporary use during the transition to IPv6 is broadly accepted within the community…

We don't think that the draft is a balanced assessment of the situation, but at the same time, we don't have time to contribute to it <snip>

[JL] I understand. As I'm in a similar situation, it's always challenging to balance time and various other work commitments. I will look again at the text in the –04 update and see if I can add more depth to the motivation sections and better explain the situation that major domains like your own face, and why this is therefore viewed as a critical transition tool. I'm sure this will be imperfect, but I'll see what I can do (and I may run some draft text past you privately).

Regards
Jason

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 May 2011 17:06:35 +0200

Hi,

> resolvers that are broken.

The IPv6 connectivity or not of the recursive resolver is no indication
on the brokenness of the IPv6 connectivity of the *end user* querying
this resolver.

> follow that the authoritative servers must not have AAAA glue records.

DNS is very good at handling the situation where certain servers out
of a delegated sets cannot be reached, or cannot be reached via a certain
protocol.

So - I don't see why there would be any problem having AAAA glue in the
first place, and then of course having IPv6 addresses in the whitelist
ACLs.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 May 2011 20:38:05 +0300 (EEST)

> on the brokenness of the IPv6 connectivity of the *end user* querying

While this is true in theory, I don't think it applies in practise in 
this case.

Whitelisting is done by whitelisting resolvers, i.e., ISPs.

There is a connection between broken users and broken (IPv6) resolvers 
in the case that ISP's IPv6 is unreliable.  Indeed, Google has 
requirements for the v6 connectivity of the ISP as well.

In the typical case, however, you're right that the brokenness of IPv6 
resolvers and IPv6 end-users are orthogonal.  But that does not change 
the main point, i.e., that in the case the IPv6-capable resolver is 
broken, lots of end-users will be affected.

I would be interested in seeing measurements on the brokenness of 
resolvers when a) IPv4 is used for AAAA queries, and b) IPv6 is used 
for AAAA queries.  Both are known to have issues in certain cases.

> of a delegated sets cannot be reached, or cannot be reached via a certain

I have to disagree here.  DNS is very slow at handling these issues -- 
if the answer is not in the cache or it has timed out.  The timeouts 
take multiple seconds or even a dozen seconds.  In the worst case, the 
resolver keeps hammering the authoritative server that's down again 
and again, and every lookup will time out. If the end-user has to wait 
even a couple of seconds or a dozen seconds, I think from Google POV 
that's effectively equivalent to broken end-user experience.

IMO, DNS lookup induced timeouts are one of the most visible issues 
affecting end-user usage satisfaction.

As a result, I don't see major content providers adding AAAA glue to 
their authoritative servers any time soon even if they had the 
technical capability to do so. But I'd love to see them say the 
opposite. (For similar reasons, I don't see them enabling DNSSEC any 
time soon.)

---

From: Erik Kline <[email-masked]>
Date: Wed, 4 May 2011 20:05:49 +0200

> As a result, I don't see major content providers adding AAAA glue to their
> authoritative servers any time soon even if they had the technical
> capability to do so. But I'd love to see them say the opposite. (For similar
> reasons, I don't see them enabling DNSSEC any time soon.)

<digression>
We have the capability to add AAAA records to nameservers, but won't
be putting AAAAs into glue until the impact of doing is properly
quantified and has undergone engineering review.

Basically, the work up until this point has been about quantifying
(and controlling) the damage for "HTTP/S applications as used by
browsers".  Measuring and responding to the issues that arise for
adding AAAAs to MXes, adding AAAAs to NSes, etc has yet to be done (by
us).
</digression>

---

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: Mark Andrews <[email-masked]>
Date: Thu, 05 May 2011 10:14:58 +1000

> adding AAAAs to MXes, adding AAAAs to NSes, etc has yet to be done (by

Adding IPv6 transport for DNS is a no-brainer.  The recursive servers
already have to deal with a unreliable transport where a reasonable
percentage of servers are unreachable at any point in time and
recover within the 2-3 seconds before the stub clients timeout and
return a failure to the application.  Recursive servers already
track responses times from authoritative servers.

All the sorts of methods happy eyeballs encourages have been done
for decades in recursive DNS servers.  With normal resolution DNS
servers don't talk TCP without first being able to talk to the
server over UDP.

I know the nameservers we ship are often to run as recursive servers
with local IPv6 connectivity, global IPv6 default route, no ICMPv6
error traffic and global IPv4 connectivity without problems on
default configs.  They work better if there is ICMPv6 error traffic.
They work better if they are tuned to know which IPv6 addresses are
reachable.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Thu, 5 May 2011 16:47:55 +0200

Hi,

On Wed, May 04, 2011 at 08:38:05PM +0300, Pekka Savola wrote:
> take multiple seconds or even a dozen seconds.  

... for end user resolver libraries.  Proper recursive resolver software
handles this quite well, and with usually much shorter timeouts before
trying alternative pointers.

And it's not like IPv6 is the only way a DNS delegation chain can be
broken - we quite frequently see domains that are delegated to a number
of IPv4 servers of which one is not reachable.  Our recursors seem to
handle that quite nicely...  (unbound and pdns_recursor).

> affecting end-user usage satisfaction.

I don't need to have an "O" here, I have actual *experience* here :-) - 
our DNS recursors and DNS authoritative servers have been dual-stacked
for at least the last 5 years, and that hat has not caused a single
problem.

> opposite. (For similar reasons, I don't see them enabling DNSSEC any 

We're mostly a hosting provider these days, and our nameservers are
dual-stacked, with glue and everything.  We might not be in the global
Top 10, though, so it depends on your definition of "major".

Gert Doering
        -- NetMaster

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 May 2011 08:12:37 +1000

> that's effectively equivalent to broken end-user experience.

Which really is not true.  Please go do the exercise of running a
dual stack recursive nameserver and filtering out the IPv6 DNS
traffic from that server without sending back ICMPv6 messages.  If
you want a server to zone to test against use isc.org's.  It, org
and the root have IPv6 address and IPv6 glue/hints.  All the zones
are also signed so you have big answers some of which will be
fragmented if your recursive server sets DO=1 in the queries.

Yes the initial query takes about 3 seconds as the resolver discovers
that it can't reach the root, org or isc.org over IPv6.  Subsequent
queries take much less time.  Usually a single round trip.

Look at the packet traces.  Named uses a 800ms timer on timeouts and
we will be dropping it to ~200ms in future versions mainly to deal
with firewalls blocking EDNS response > 512 bytes.  Other vendors
use similar timeouts.

Named can also be configured to run IPv4 only on a dual stack box
(named -4).
Named can also be configured to run IPv6 only on a dual stack box
(named -6).
Named can be configured to only query IPv4 servers but respond on
both stacks (servers ::/0 { bogus yes; };).
Named can be configured to only query IPv6 servers but respond on
both stacks (servers 0.0.0.0/0 { bogus yes; };).
Named can be configured to treat all but certain address ranges as
unreachable (if you are using ULA but have no external IPv6 connectivity
servers ::/0 { bogus yes; }; servers fdxx:xxx:xxxx::/48 { bogus no; }; ).

Some or all of these features are available from other vendors.

As a vendor we looked at this a decade ago back when people were
playing with site-local addresses.

> affecting end-user usage satisfaction.

Much more frustating is IPv4 nameservers that drop AAAA queries or
return invalid negative answers for AAAA queries.  These affect
everybody and there are no workarounds that can be deployed locally.

---

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

Here is the text I plan to add to Section 2 to address the discussion below. Please advise if folks think this is inelegantly-worded and should be modified in any way.

"DNS whitelisting also works independently of whether an authoritative server, recursive resolver, or end user host uses IPv4 transport, IPv6, or both. So, for example, whitelisting may prevent sending AAAA responses even in those cases where the recursive resolver has queried the authoritative server over IPv6 transport, or where the end user host's original query to the recursive resolver was over IPv6 transport. One important reason for this is that even though the recursive resolver may have no IPv6-related impairments, this is not a reliable predictor of whether the same is true of the end user host. This also means that a DNS whitelist can contain both IPv4 and IPv6 addresses."

Thanks
Jason

On 5/3/11 1:53 PM, "Livingood, Jason" <[email-masked]<mailto:[email-masked]>> wrote:

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

---

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

/"DNS whitelisting also works independently of whether an authoritative server,
recursive resolver, or end user host uses IPv4 transport, IPv6, or both. So, for
example, whitelisting may prevent sending AAAA responses even in those cases
where the recursive resolver has queried the authoritative server over IPv6
transport, or where the end user host's original query to the recursive resolver
was over IPv6 transport. One important reason for this is that even though the
recursive resolver may have no IPv6-related impairments, this is not a reliable
predictor of whether the same is true of the end user host. This also means that
a DNS whitelist can contain both IPv4 and IPv6 addresses."/

I do not understand this text.

    "independently of whether an... end user host user..."

I don't think I say "end user host user" though. ??

appears to be saying that this mechanism 'works' even when its constraint on DNS
response content is useless, by virtue of preventing the response to be
delivered.  That, at least, appears to be the implication of some of the
combinatorials the text seems to cover.

I'm trying to say that the transport used (v4 or v6) of the stub, recursive resolver, and authoritative server are orthogonal to the application of a whitelist or whether a host or network is or is not on the whitelist.

JL

d/
--

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 06 May 2011 09:03:49 -0700

On 5/6/2011 8:38 AM, Livingood, Jason wrote:
> Here is the text I plan to add to Section 2 to address the discussion below.
> Please advise if folks think this is inelegantly-worded and should be modified
> in any way.
>

d/
-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Mon, 9 May 2011 18:01:06 +0200

Dear Jason,

a more or less arbitrarily using of the AAAA whitelisting configuration
without coordination of all involved networks could lead IMHO to unexpected traffic behaviour respectively traffic load in some segments of the internet.
That should be valid as long as the internet is not complete Dual-Stack enabled
or when no congruent IPv4/v6 network topology is available.
I would expect at least that the latter case will never occur.

Therefore I propose the following text in section 7.3.x of the draft.

"
7.3.x Unexpected changes and shifts in traffic load on links and network segments

In the case when large content provider would using DNS whitelisting for DNS resolver of
access provider [is this now the right term?] to be whitelisted or not will change significant
the traffic volume for IPv4 or IPv6 between both parties.
Also when the overall traffic is stable, in the case that there is not a congruent IPv4-IPv6 topology available whitelisting will lead to changes in traffic load of individual links and network segments between the access and the content provider.
In the case of creating a whitelist entry traffic will be shifted to IPv4 and the IPv4 capable links and network segments.
In the case of deleting a whitelist entry traffic will be shifted to IPv6 and the IPv6 capable links and network segments.
When the DNS whitelisting occur without coordination between the content and the access provider this could cause challenges in the traffic engineering.
"

Best

KARSTEN

---

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: Dave CROCKER <[email-masked]>
Date: Thu, 12 May 2011 09:50:45 -0700

> Whitelisting for Inclusion of AAAA Record in Response" (longer name)

For completeness:

I wound up doing a full review for the Apps Area -- you all should have seen it 
posted by now -- and included a bit more about naming issues/choices.  I think 
there is some 'internal' issues with the name, in addition to the 'external' 
confusion of conflicting with the established use by anti-abuse folk.

I'm a fan of choosing names that have some hope of being reasonable intuitive 
and precise.  It's rarely possible to be so intuitive that a new reader will 
guess the name, but it can be intuitive enough to be easy to remember and know 
what it means.

On 5/3/2011 8:26 AM, Erik Kline wrote:
 > and motivations.  It is, rather, a harangue against its use, ...

I found the opinions of the draft sometimes difficult to discern.  I think that, 
in fact, it did not take clear enough positions for or against a number of 
issues in this topic.  Certainly I did not find anything either clear enough or 
strong enough to qualify as a harangue.

My second review noted this, especially with respect to "universal" adoption of 
the mechanism.

d/

-- 

   Dave Crocker

---

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.

---

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: 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: [email-masked]
Date: Tue, 17 May 2011 08:41:08 +0200 (CEST)

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

Steinar Haug, Nethelp consulting, [email-masked]

---

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

+1 for moving on

Cb

---

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

---

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: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

---

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

Thanks for your additional feedback, Karsten. See comments inline below.

Regards
JL

On 5/9/11 12:01 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear Jason,

"

[JL] I received similar feedback from some other people recently. What I have done is added this text to 7.3.1, De-Whitelisting May Occur. I'm hoping this sufficiently accounts for your concern, which I share. If not, let me know what you suggest and I will add that to an upcoming version.
"One particular risk is that, especially when a high-traffic domain de-whitelists a large network, this may cause a sudden and dramatic change to networks since a large volume of traffic will then switch from IPv6 to IPv4. This can have dramatic effects on those being de-whitelisted as well as on other interconnected networks. In some cases, IPv4 network links may rapidly become congested and users of affected networks will experience network access impairments well beyond the domain which performed the de-whitelisting. Thus, once "operational stability" has been achieved between a whitelisting and whitelisted party, then de-whitelisting should generally not occur except in cases of operational emergencies, and there should be opportunities for joint troubleshooting or at least for advance warning to affected parties."

Thanks!
Jason

Best

KARSTEN

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 May 2011 19:16:03 -0700

On Sun, May 29, 2011 at 12:46 PM, Livingood, Jason <
[email-masked]> wrote:

>  *"One particular risk is that, especially when a high-traffic domain
> de-whitelists a large network, this may cause a sudden and dramatic change
> to networks since a large volume of traffic will then switch from IPv6 to
> IPv4.*
>

Why does the draft neglect to mention the equal but opposite "sudden and
dramatic change to networks" that can occur if a high-traffic domain
suddenly announces AAAA records for the whole world without whitelisting?

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 30 May 2011 03:25:52 +0000

On 5/29/11 10:16 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, May 29, 2011 at 12:46 PM, Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:
"One particular risk is that, especially when a high-traffic domain de-whitelists a large network, this may cause a sudden and dramatic change to networks since a large volume of traffic will then switch from IPv6 to IPv4.

Why does the draft neglect to mention the equal but opposite "sudden and dramatic change to networks" that can occur if a high-traffic domain suddenly announces AAAA records for the whole world without whitelisting?

[JL] Well, actually the draft *does* mention this. Please note the following instances with specific and/or relation mentions of this. I am open to any suggestions you may have on these or on additional mentions of course. :-)

Section 3: "… Therefore there are two concerns which relate to this practice; one of which relates to IPv6-related impairment and the other which relates to the maturity or stability of IPv6 transport for high-traffic domains…."

Section 3.2, Volume-Based Concerns:
"Some implementers are trying to gradually add IPv6 traffic to their domain since they may find that network operations, tools, processes and procedures are less mature for IPv6 as compared to IPv4. While for domains with small to moderate traffic volumes, whether by the count of end users or count of bytes transferred, high-traffic domains receive such a level of usage that it is prudent to undertake any network changes gradually or in a manner which minimizes any risk of disruption. For example, one can imagine for one of the top ten sites globally that the idea of suddenly turning on a significant amount of IPv6 traffic might be quite daunting. DNS Whitelisting may therefore offer such high-traffic domains one potential method for incrementally enabling IPv6. Thus, some implementers with high-traffic domains plan to use 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."

Section 3.3.  Free Versus Subscription Services
"It is also worth noting the differences between domains containing primarily subscription-based services compared to those containing primarily free services. In the case of free services, such as search engines, end users have no direct billing relationship with the domain and can switch sites simply by changing the address they enter into their browser (ignoring other value added services which may tie a user's preference to a given domain or otherwise create switching costs). As a result, such domains explain that they believe they are more sensitive to the quality of the services within their domain since if the user has issues when they turn on IPv6, then that user could switch to another domain that is not using IPv6."

Section 7.6: "...At the same time, as noted in Section 3, some high-traffic domains may find the prospect of transitioning to IPv6 daunting without having some short-term ability to incrementally control the amount and source of IPv6 traffic to their domains. Lacking such controls, some domains may choose to substantially delay their transition to IPv6..."

Section 8.3.2: "...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. While this is a good first step to functionally test and prepare a domain for IPv6, the utility of the tactic is limited since users must know the transition name, the traffic volume will be low, and the traffic is unlikely to be representative of the general population of end users, among other reasons..."

Section 9: "...In particular, some high-traffic domains view DNS Whitelisting as one of the few practical and low-risk approaches enabling them to transition to IPv6, without which their transition may not take place for some time..."

-- JL

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 May 2011 02:06:33 -0700

On Sun, May 29, 2011 at 8:25 PM, Livingood, Jason <
[email-masked]> wrote:

>  [JL] Well, actually the draft *does* mention this. Please note the
> following instances with specific and/or relation mentions of this. I am
> open to any suggestions you may have on these or on additional mentions of
> course. :-)
>

None of those snippets mention changes to other networks, let alone "sudden
and dramatic" changes.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 30 May 2011 12:59:02 +0000

On Sun, May 29, 2011 at 8:25 PM, Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:
Why does the draft neglect to mention the equal but opposite "sudden and dramatic change to networks" that can occur if a high-traffic domain suddenly announces AAAA records for the whole world without whitelisting?

None of those snippets mention changes to other networks, let alone "sudden and dramatic" changes.

[JL] Then perhaps I am misunderstanding what you are asking for. For example, 3.2 does say sudden:
"For example, one can imagine for one of the top ten sites globally that the idea of suddenly turning on a significant amount of IPv6 traffic might be quite daunting. DNS Whitelisting may therefore offer such high-traffic domains one potential method for incrementally enabling IPv6. Thus, some implementers with high-traffic domains plan to use 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."

Can you explain exactly what you mean / are asking for? I can keep guessing but it'd be far easier if you could explain it. ;-)

Jason