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.
Section 2.1
Is the term "IP address" here intended to include both IPv4 and IPv6 addresses?
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:
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:
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.
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.
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.
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).
=============================================
From: The IESG <iesg-secretary@xxxxxxxx>
To: IETF-Announce <ietf-announce@xxxxxxxx>
Reply-to: iesg-secretary@xxxxxxxx
Subject: Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> (IPv6
AAAA DNS Whitelisting Implications) to Informational RFC
X-RSN: 1/0/934/8529/9220
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an
Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2011-04-29. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
|