Skip to main content

Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11

Yes

(Ron Bonica)
(Wesley Eddy)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Pete Resnick)
(Peter Saint-Andre)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)

Note: This ballot was opened for revision 10 and is now closed.

Jari Arkko Former IESG member
(was Discuss) Yes
Yes (2011-04-28) Unknown
o  DNS whitelisting is a very different behavior from the current
      practice concerning the publishing of IPv4 address resource
      records,

But location-based DNS responses and other practices are widely deployed in the IPv4 Internet, and while whitelisting differs substantially from them, I think we should not pretend that DNS operates in its original pure fashion either.

   In practice, DNS whitelisting generally means that a very small
   fraction of the DNS recursive resolvers on the Internet (those in the
   whitelist ACL) will receive AAAA responses.

Hmm. I'm not sure this corresponds to reality in all cases. For instance, a certain large content provider reported that their whitelist contained most of the assigned IPv6 address space.

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

I think the universal deployment model is so obviously unworkable that I don't even know why this it is brought up here. And I'm not sure why we need to call the other alternative "ad hoc" -- it comes down to network managers making their own decisions as to whether they believe they need whitelisting (or IPv6 to begin with, or DNSSEC, or ...) There is no universal deployment for any feature in an internet-wide fashion! 

Also, in reality there are different shades of universality. Groups of content providers may work together on a joint model, through an RIR, standards could be written or common open source tools or databases be employed. The split between "universal" and "ad hoc" misses all these nuances.

   As noted in Section 1, domains which implement DNS whitelisting are
   attempting to protect a few users of their domain, who have impaired
   IPv6 access, from having a negative experience (poor performance).
   While it is outside the scope of this document to explore the various
   reasons why a particular user's system (host) may have impaired IPv6
   access, for the users who experience this impairment it is a very
   real performance impact.

In a lot of cases, its not about a performance impact. Application behavior and timeouts may not be at all reasonable for recovering a wrong choice.

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

Are you implying that there is more? If so, maybe it should be described. If not, just say "Those potential implications are ..."

   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS whitelisting, it is
   not clear if the level of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be that websites are only
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are simply unable to or are
   otherwise not in a position to be able to measure IPv4 impairment
   (since this could result in no Internet access whatsoever). 

I have measured IPv4 and IPv6 impairments alongside each other. The IPv6 impairments *are* bigger. The IPv4 impairments are not insignificant, however. My measurements were not about the case of a large, well-managed content provider being accessible by randomly picked individual users or networks, it was the reverse. But it goes to show that there is significant breakage in both the IPv4 and IPv6 Internet and that IPv6 breakage is often bigger. I for one do not fault the content providers for trying to ensure that their content is as widely accessible as possible.

   Also, it is possible that DNS whitelisting could affect some of the
   architectural assumptions which underlie parts of Section 2 of
   [RFC4213] which outlines the dual stack approach to the IPv6
   transition.  DNS whitelisting could modify the behavior of the DNS,
   as described in Section 2.2 of [RFC4213] and could require different
   sets of DNS servers to be used for hosts that are (using terms from
   that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
   As such, broad use of DNS whitelisting may necessitate the review
   and/or revision of standards documents which describe dual-stack and
   IPv6 operating modes, dual-stack architecture generally, and IPv6
   transition methods, including but not limited to [RFC4213].

I think this worry is a little bit overstated.

   An unfortunate implication of the adoption of DNS whitelisting may be
   the encouragement of a reversal of this trend, which would be a move
   back towards greater levels of homogeneity.  In this case, a domain
   owner which has implemented DNS whitelisting may prefer greater
   levels of control be exerted over end user hosts (which broadly
   includes all types of end user software and hardware) in order to
   attempt to enforce technical standards relating to establishing
   certain IPv6 capabilities or the enforcing the elimination of or
   restriction of certain end user hosts.  While the domain operator is
   attempting to protect, maintain, and/or optimize the end user
   experience for their domain, the collective result of many domains
   implementing DNS whitelisting, or even a few major domains (meaning
   domains which are a major destination of Internet traffic)
   implementing DNS whitelisting, may be to encourage a return to more
   homogenous and/or controlled end user hosts.  This could have
   unintended side effects on and counter-productive implications for
   future innovation at the edges of the network.

As above. 

   As noted in Section 4, the implications of DNS whitelisting may drive
   end users and/or networks to delay, postpone, or cancel adoption of
   IPv6, or to actively seek alternatives to it.  Such alternatives may
   include the use of multi-layer network address translation (NAT)
   techniques like NAT444 [I-D.shirasaki-nat444], which these parties
   may decide to pursue on a long-term basis to avoid the perceived
   costs and aggravations related to DNS whitelisting.  This could of
   course come at the very time that the Internet community is trying to
   get these very same parties interested in IPv6 and motivated to begin
   the transition to IPv6.  As a result, parties that are likely to be
   concerned over the negative implications of DNS whitelisting could
   logically be concerned of the negative effects that this practice
   could have on the adoption of IPv6 if it became widespread or was
   adopted by majors Internet domains or other major parties in the
   Internet ecosystem.

   At the same time, as noted in Section 3, some highly-trafficked
   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.

I think these different viewpoints would have deserved a more equal treatment. For instance, it is not at all clear to me why whitelisting drives NAT444 while inability to gradually turn on IPv6 in a controlled manner doesn't.

In general, Section 7 seems to be written as a critique of the whitelisting practices, not as a comparison of the different implications of choosing to either deploy or not deploy whitelisting.

   8.1. Implement DNS Whitelisting Universally
   8.2. Implement DNS Whitelisting On An Ad Hoc Basis
   8.3. Do Not Implement DNS Whitelisting

I think that this set of options is not a very good one. Option 1 is clearly impossible for any technology, option 2 is even named in a manner that makes it obvious that the document doesn't prefer it, and option 3 has well known issues. One of the things that would have helped this document is to not contrast the extremes but to highlight practices that are preferred/not preferred. For instance, I think developing common whitelisting databases and tools, temporary whitelisting, moving later to blacklisting and eventually to no-listing-at-all would all be useful actions.  Trying to deny the need for content providers to have some control of how their network is accessed will IMO likely result in less or no IPv6 deployment. Fortunately, the good news is that I think the Internet is moving forward and hopefully we can grow out of whitelisting into blacklist and no listing at all.

   8.3.2. Gain Experience Using IPv6 Transition Names

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

And that's one of the other alternatives that are not so extreme. However, I think for much of the premier content in Internet, we're already past this. Been there done that. We need more IPv6 deployment than this can give.

   However, there is clear consensus that DNS whitelisting is
   at best a useful temporary measure which a domain may choose to
   pursue as they prepare for the transition to IPv6.  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.  Thus, DNS whitelisting is not a recommended practice over
   the long-term.  In addition, DNS whitelisting should be avoided
   wherever possible in the short-term and its use is generally
   discouraged.

The last sentence does not seem to match the earlier sentences.
Ron Bonica Former IESG member
Yes
Yes () Unknown

                            
Wesley Eddy Former IESG member
(was Discuss) Yes
Yes (2011-05-31) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-04-24) Unknown
Thanks for a document that was both informative and easy to read.

One tiny nit:

Section 3

"someone slower than usual"

s/someone/somewhat/
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2011-06-21) Unknown
Updated to reflect feedback on rev -06 (2011/6/21).

1. The following edited text in section 4 is intended, in part, to
address one of my Discuss points:

   Implementers are attempting to protect users of their domain from
   having a negative experience (poor performance) when they receive DNS
   response containing AAAA resource records or when attempting to use
   IPv6 transport.  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.  Both can negatively affect the experience
   of end users.

I find this text confusing as (a) it sort of mixes the method with the
outcome and (b) I didn't understand the two concerns at first
reading.  I suggest:

   Implementers use IPv6 AAAA DNS Whitelisting to protect users of
   their domain from having a negative experience (poor performance)
   because of potential problems with IPv6 transport to the domain.
   There are two primary problems to be avoided: IPv6-related
   impairment in which the end-to-end IPv6 transport between the user
   and the domain leads to a negative experience and the maturity,
   scalability and stability of the IPv6 transport at the domain.


2. Throughout section 8, "domains" are anthropomorphized to "choose to
use [whitelisting]," "view DNS Whitelisting [...]," "transition to
IPv6," etc.  At the risk of pedantic clunkiness of style, as an
example I suggest:

OLD:

   However, there is clear consensus that DNS Whitelisting can
   be a useful tactic a domain may choose to use as they transition to
   IPv6.

NEW:

   However, there is clear consensus that DNS Whitelisting can
   be a useful tactic an administrator can use during the transition
   of a domain to the use of IPv6 transport.

or NEW:

   However, there is clear consensus that DNS Whitelisting can be a
   useful tactic for use during the transition of a domain to IPv6
   transport.
Robert Sparks Former IESG member
(was Discuss, No Objection, Discuss) No Objection
No Objection (2011-05-30) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2011-05-30) Unknown
- Spaces in references are odd and may break some tools. Be better
not do to that I think. Example: "[Evaluating IPv6 Adoption]"

- I'm not sure the reference to world IPv6 day should stay,
it'll be outdated just after an RFC issues so why bother?
(Describing what happens in June in retrospect will be very
interesting but this bit isn't.)
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown