Considerations for Transitioning Content to IPv6
RFC 6589
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Jari Arkko; former steering group member) (was Discuss) Yes
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 steering group member) Yes
(Wesley Eddy; former steering group member) (was Discuss) Yes
(Adrian Farrel; former steering group member) No Objection
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 steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
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 steering group member) (was Discuss, No Objection, Discuss) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 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 steering group member) No Objection