Hi – Thanks for the feedback and see a few selected responses inline below. A
–04 update is coming soon.
On 5/3/11 4:43 AM, "SM"
At 11:48 02-05-2011, Livingood, Jason wrote:
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.
Repurposing a sentence from the
"By engaging in a DNS tradeoff, they are attempting to
shield users with impaired access from the symptoms of those
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.
[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.
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
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 . 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. :-)
[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.
On an unrelated note, there was a mistake in the message I posted
previously . The last sentence should be read as:
As I do not meet the religious requirements, I cannot take a
position on this draft.
Ietf mailing list