Hi Bernard – I've finally found the time to close out the last bits of feedback in this version of the draft. Your comments will be incorporated shortly into a –04 version of the document. Please see specific replies inline below.
Thanks!
Jason
Overall, I think this is a useful document.
My suggestions below mostly relate to potential organizational improvements, as well as as a bit more detail in some areas.
Section 2
This section talks about how white-listing works, but does not talk about potential mechanisms by which the whitelist is determined. For example, in addition to techniques for manually maintaining the whitelist, there have been some suggestions that would
involve automatic determinations (e.g. only answering with AAAA RRs if the query comes in over IPv6). It might be useful to cover some of the proposals, since they might have different implications.
[JL] I added a bit of text in the ad hoc DNS whitelisting section noting that there are two approaches. I did not include the part about only responding with a AAAA RR if the query comes in via IPv6, as I've not heard much about this in practice and discussion
from implementers seems to indicate that even if they recursive server sent the query over IPv6 they still may have end hosts that are broken.
Section 2.1
Is the term "IP address" here intended to include both IPv4 and IPv6 addresses?
[JL] Yes, and I updated the text to clarify that.
Section 3
At least one highly-trafficked domain has noted that they have
received requests to not send DNS responses with AAAA resource
records to particular resolvers. In this case, the operators of
those recursive resolvers have expressed a concern that their IPv6
network infrastructure is not yet ready to handle the large traffic
volume which may be associated with the hosts in their network
connecting to the websites of these domains. This concern is clearly
a temporary consideration relating to the deployment of IPv6 network
infrastructure on the part of networks with end user hosts, rather
than a long-term concern. These end user networks may also have
other tools at their disposal in order to address this concern,
including applying rules to network equipment such as routers and
firewalls (this will necessarily vary by the type of network, as well
as the technologies used and the design of a given network), as well
as configuration of their recursive resolvers (though modifying or
suppressing AAAA resource records in a DNSSEC-signed domain on a
Security-Aware Resolver will be problematic Section 10.1).
[BA] This paragraph seems to be distinguishing "blacklisting" from "whitelisting" as well as describing some of the implications of attempting to suppress AAAA RRs in the recursive resolver. It might be worthwhile to introduce the distinction between "blacklisting"
and "whitelisting" earlier on.
Such a section might also include the following paragraph from Section 7.3.7:
[JL] Good idea – I added a brief section contrasting whitelisting and blacklisting, including some of the text you suggest.
It is unclear when and if it would be appropriate to change from
whitelisting to blacklisting, and whether or how this could feasibly
be coordinated across the Internet, which may be proposed or
implemented on an ad hoc basis when a majority of networks (or
allocated IPv6 address blocks) have been whitelisted. Finally, some
parties implementing DNS whitelisting consider this to be a temporary
measure. As such, it is not clear how these parties will judge the
network conditions to have changed sufficiently to justify disabling
DNS whitelisting and/or what the process and timing will be in order
to discontinue this practice.
Section 4
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). As a
result, it is worth considering that IPv4-related impairment could
exceed that of IPv6-related impairment and that such IPv4-related
impairment may have simply been accepted as "background noise" on the
Internet for a variety of reasons. Of course, this comparison of the
level of worldwide IPv6 impairments to IPv4 impairments is
speculation, as the author is not aware of any good measurement of
IPv4-related impairments which are comparable in nature to the IPv6-
related impairment measurements which have recently been conducted
around the world.
[BA] It seems to me that discussion of measurement issues should probably come earlier in the document, possibly in its own section.
My suggestion is to move this paragraph as well other paragraphs referring to measurement into its own section (Section 1.1?).
The following paragraph from Section 3.2 might be a candidate:
[JL] Good suggestion - I have done so. I moved the impairment percentage citation to section 3 and have greatly re-worked section 3 to address this (and add a new motivation I've heard from one implementer).
Finally, some domains, have run IPv6 experiments whereby they added
AAAA resource records and observed and measured errors [Heise Online
Experiment], which should be important reading for any domain
contemplating either the use of DNS whitelisting or simply adding
IPv6 addressing to their site.
Section 6
This section talks about Adhoc versus universal deployment scenarios. It strikes me that the underlying distinction is not so much the universality of whitelisting deployment as much as whether the whitelists are shared or independent. The document seems to
argue that independence is the most likely outcome:
It is probably unlikely that a single clearinghouse for
managing whitelisting is possible; it will more likely be unique to
the source content owners and/or domains which implement DNS
whitelists.
[BA] While a single clearinghouse might be unlikely, I'm not sure that this necessarily argues against the likelihood of multiple clearinghouses. It might be helpful to provide a little more detail on the motivation behind the views on the likelihood of clearinghouses
emerging (e.g. is this based on discussions with content providers?). For example, if the concept of IPv6 whitelisting becomes more widespread among smaller content providers, it would seem that the need for clearinghouses might emerge.
[JL] Added a note on this.
Section 7.3.3
It seems to me that there might be some operational implications that might arise from some potential whitelisting mechanisms such as differentiating DNS queries sent over IPv6 versus IPv4.
[JL] Good feedback – I'll incorporate that into the I-D.
Section 7.6
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.
[BA] The issue of traffic control is a distinct problem. This is partially discussed in Section 3 (from the point of view of the recursive resolver owner),
but here it is referring to the problem as experienced by the content owner. Perhaps it would make sense to make the distinction between the
"impairment" and "traffic control" problems earlier? (maybe even in Section 1, referring to a subsequent discussion in Section 3).
Section 8.3.1
This section refers to fixes for the "impairment" problem, but as noted above, there may also be other potential motivations for whitelisting.
[JL] Indeed. Based on your suggestion for section 3, I hope to have addressed this.
Section 9
World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],
is scheduled to occur on June 8, 2011. This will be an opportunity
for domains to add AAAA resource records to the DNS without using DNS
whitelisting. As a result, this is likely an excellent opportunity
for domains to evaluate the utility or necessity of DNS whitelisting,
even in the short-term. A major German news website, Heise Online,
also ran a similar IPv6 experiment whereby they added AAAA resource
records and observed and measured any errors [Heise Online
Experiment], which is important reading for any domain contemplating
either the use of DNS whitelisting or simply adding IPv6 addressing
to their site.
[BA] You might consider moving this paragraph into a separate "measurement" section (e.g. Section 1.1).
[JL] Thanks for all the feedback!
_______________________________________________Ietf mailing list
Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf
|