Dave - Thanks for the additional feedback. Any changes noted below will be made soon in a -06 update. See inline comments.
Regards Jason On 5/30/11 11:34 AM, "Dave CROCKER" <d...@dcrocker.net<mailto:d...@dcrocker.net>> wrote: (I see that you've posted -05. This response is for completeness.) On 5/29/2011 7:54 PM, Livingood, Jason wrote: [JL] Duly noted in my previous emails. I'm keeping the naming as an open issue in the –04 and will be seeking WG and WG co-chair guidance one way or the other. One of the reasons for cross-area review is to look for cross-area problems. Separate from the legal formalities, the purpose of 'trademark' is to try to avoid market confusion. Market confusion was exactly the reason that I raised concern about the naming and I wasn't the only one who noticed the problem. (My original, informal posting was directly result of that confusion...) So I'm sorry to see that the naming conflict is felt to be irrelevant by those running the working group. (I was also a little surprised to see that that core of folk constitute working group rough consensus, for removing open items.) As for the actual term "whitelisting" I suppose we should admire the boldness of the view that access to v6 is a priviledge -- note that that's the denotational perspective of the word whitelisting... [JL] Duly noted. operator of a website, such as www.example.com, the operator essentially applies an access control list (ACL) on the authoritative DNS servers for the domain example.com. The ACL is populated with An ACL usually is a yes/no mechanism. Here, however, the mechanism is for asserting a preference for IPv6 over IPv4. That does not seem to match the definition of ACL that I'm used to, unless the semantic is defined as denying IPv4 access to the listed clients. The term ACL is particularly odd to use if the mechanism pertains to responses rather than queries. [JL] I am using 'ACL' in the most general possible sense and am open to alternative descriptors if you wish to suggest one. But most people seem to know an ACL is a list that, if you are listed on it, grants you access to some resource. In this case if the resolver is on the list then it gets AAAA RRs. On reflection, the term is growing on me for this use. "AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good labels. They provide useful, direct and precise meaning, while avoiding the various referential and denotational problems of a loaded term like whitelist. [JL] Great! And I like thinking about it more in terms of granting "access" to AAAA RRs than viewing it as "blocking" AAAA RRs, as I find access control a more neutral term and one that is still easy to understand conceptually. [JL] I took a stab at a new diagram in –04 — so take a look and let me know if it is what you are suggesting (I've left the original one in for now). Took a quick look at the added diagram in the new draft. The thing about a protocol timeline diagram is that it uses verticality to provide ordering. So a response is lower down than a request. I don't get that from your Figure 2. [JL] Oh! Now I understand what you were asking for. See my email under separate cover with an example to see if I am getting closer. Others can see what I now have in draft form at https://img.skitch.com/20110531-j1r2ubr43273fd9i8xuj6btyn9.jpg (By the way, your first sub-scenario, with Resolver 1, shows only a v4 response, without indicating whether the resolver sent a v6 or v4 query. For the review, I think this distinction between transport and data -- "how is the query/response transported" vs. "what RRs are returned" -- was a continuing point of confusion for me. ) [JL] Ack. I'll add an extra note at the top of the diagram to clarify that the access control logic is independent of whether IPv6 transport is used between the host and resolver, or resolver and authority. 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 "At least one" seems a rather tiny statistic. Perhaps the actual statistic is significantly larger? [JL] It does not seem to be. Other than this being passed along by Google, I've not heard of any similar stories. Nevertheless, it seemed interesting enough to include. As an anecdote, it is perhaps interesting. As a basis for promoting the entire effort, not so much. I couldn't tell which role it was serving, but it felt like the latter. 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 So even though the site allows v6 DNS queries to go out from a host, it can't really support having the host use v6? [JL] A network isn't really in control of the end host's limitations w/r/t IPv6 impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/ That sort of commentary, along with the citation, might be good to include, for clarification. [JL] Done. 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 8 hundredths of one percent? I think that that's 8 of every 10,000 Internet users? That's considered a high percentage? [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that rate, it'd be cheaper and easier for me (an ISP) to just buy new computers for the affected "impaired" users than to have to navigate years of whitelisting with a variety of domains. In any case, one recent measurement estimates it at 0.05% now and another at 0.015%. Despite this, this practice is still generating some interest. I'm hoping World IPv6 Day goes well and is informative for the community as to this percentage on a widespread basis, across a wide variety of web sites. Even if it is 8%, is that considered high? [JL] 8% of the Internet finding google.com or facebook.com inaccessible would be bad for everyone. That could generate several hundred thousand support calls per day to a big ISP. On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out of every 10,000 users, nevermind a large multiple of that. (Although it does carry a backhanded note of encouragement about v6 adoption, I'm a bit suspicious of the statistic.) [JL] Important to keep in mind that the IPv6-impairment occurs in situations where someone usually does not have functioning IPv6 transport — just seeing the AAAA RR causes issues. troubleshooting standpoint. In this scenario, a DNS recursive resolver operator will have no way to systematically determine whether DNS whitelisting is or is not implemented for a domain, since the absence of AAAA resource records may simply be indicative that the domain has not yet added IPv6 addressing for the domain, rather than that they have done so but have restricted query access via DNS The premise is that, in large scale use, servers /will/ have a way to systematically determine whether it is implemented? What are the existing examples of having such a capability for other Internet protocols and services? [JL] Perhaps I'm overplaying this point, but you know someone has email service if they have an MX record for example, or a website if the host answers on TCP/80. But as I re-read this it is probably overkill and so I've deleted it. I have however moved some of the text to a prior section, since determining whether or not domains are whitelisting is still a challenge at scale. Note that a site can have email service without an MX and that TCP:80 is not merely an "indicator" of web service, but actually /is/ the web service. My point is that this idea of signaling/registering support of a service, as separate from actually providing the service, is not part of typical Internet service requirements and the simplification this provides is significant. We need to be careful that we do not inadvertently teach folks that "signaling support" is an expected feature. (And with this response, given that you already deleted the text, it's my turn to overplay a point...) nature, not to mention physics. For example, as Sir Issac Newton noted, "Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it" [Laws Code does not have momenum. Neither do configurations or lists. This really isn't about physics. [JL] But people and processes do have (operational) momentum… Indeed, and the process of dealing with the naming issue for this does seem to show that... It is entirely about group psychology, as you note, and the administrative challenges in the logistics of large-scale operational changes (which probably /does/ have something to with physics, but it seems a stretch to credit Newton. How about Heisenberg?...) [JL] Hmmm… I don't think it is Heisenberg-related. But it's such an interesting citation I feel it's almost a personal challenge to figure out a way to keep it in there. ;-) How certain of it's being a challenge are you? Does your certainty change as you think about it? [JL] I'm not wed to the reference. It was suggested earlier in the development of the document. If you have any better reference to the notion of momentum taking some effort to slow, I'm open to that. The way I think about it is that in 5 or 10 years none of the people working on the details of the IPv6 transition now will still be involved in the day-to-day operational work. But DNS Whitelisting could still be in place – and once something gets a momentum to it (people, processes, and organizations) it is really, really hard to change that. Well, I seriously applaud that concern, especially since its validity is proven every day (including in the IETF...) On the average, I tend to believe that the best way to instruct folks later is by imparting information about tradeoffs and, especially, cost vs. benefit. In the current case, the near-term cost/benefit makes some sense. In the long term, the scaling cost of maintenance and the architectural cost of losing spontaneous interoperability strike me as pretty f'ing expensive. 8.3. Do Not Implement DNS Whitelisting As an alternative to adopting DNS whitelisting, the Internet community generally can choose to take no action whatsoever, perpetuating the current predominant authoritative DNS operational model on the Internet, and leave it up to end users with IPv6-related impairments to discover and fix those impairments. That is, place the burden of fixing a problem on those creating it? [JL] In a way. It gets back to the question you asked about what level of impairment justifies this practice. One obvious option is to let end users sort it out (presumably by consulting with their ISPs / network operators). This may be simpler and it's the way solutions to non-IPv6 problems tend to work today. On the average, demanding that an end-user make an explicit decision about an operational tuning issue does not work very well. [JL] Thanks again for your feedback! Jason d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf