It's still in my queue -- I have 10 or 11 emails remaining to go through. Jason On 5/29/11 12:50 PM, "Dave CROCKER" <dhc@xxxxxxxxxxxx> wrote: > >On 5/29/2011 7:46 AM, Livingood, Jason wrote: > > Hi Bernard I've finally found the time to close out the last bits of > > feedback > in this version of the draft. > > >Jason, > >Perhaps my filters misfiled your followup to the "formal" review I was >asked to >do, or perhaps my earlier, informal, and vary narrow review muddied the >waters, >but I am not finding your response to the Apps Area review. > >For convenience, here it is again. > >d/ > >-------- Original Message -------- >Subject: Review of: >draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 > *(formal for apps area)* >Date: Mon, 09 May 2011 10:18:51 -0700 >From: Dave CROCKER <dhc@xxxxxxxxxxxx> >Reply-To: dcrocker@xxxxxxxx >Organization: Brandenburg InternetWorking >To: IETF Discussion <ietf@xxxxxxxx> >CC: v6ops@xxxxxxxx <v6ops@xxxxxxxx>, Apps Review <apps-review@xxxxxxxx> > >(This is an "official" and significantly extended version of an informal >and >narrow review I posted earlier. /d) > > > >Howdy. > >I have been selected as the Applications Area Review Team reviewer for >this >draft (for background on apps-review, please see >http://www.apps.ietf.org/content/applications-area-review-team). > >Please resolve these comments along with any other Last Call comments you >may >receive. Please wait for direction from your document shepherd or AD >before >posting a new version of the draft. > > > >Review (v2): > >Title: IPv6 AAAA DNS Whitelisting Implications >I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 > >By: D. Crocker <dcrocker@xxxxxxxx> >Date: <> > > > >Summary >======= > >This draft covers a a dual-stack problem in which a target host's DNS >entry >contains records for IPv4 and IPv6, but returning IPv6 information to a >DNS >client can cause problems. The paper discusses for resolving this through >use of >a a DNS-based mechanism that manually lists response preferences to >select which >DNS records to return. The paper describes the mechanism and explores >various >effects and possibilities of its use, including the difference between >using it >selectively among a smaller number of sites, versus universally. > >The draft is a serious effort to explore the use of such a mechanism and >it >touches many different issues. It is generally well-organized and clearly >written, although it very much needs the aid of a professional technical >editor. >The writing often assumes too much knowledge by the reader. > >The paper's exploration of universal adoption seems to vary between >considering >that goal practical versus considering it only as a matter of >completeness for >discussing the full range of possibilities. That is, it is not clear >whether >the paper views this alternative as practically possible and even >preferred, >versus only a matter for academic thoroughness. The paper needs to take a >basic >position about feasibility, explain it in terms of comparable adoption >efforts >at Internet-scale, and then make its treatment of universal adoption a >bit more >consistent. > >When introducing terms, mechanisms, configurations and scenarios, the >paper >needs to be more careful to describe them adequately for a reader new to >the >topic. This is not a matter of having a tutorial about the DNS, but >rather a >tutorial for this type of mechanism and when and how it can be used. > >As a specific example, the document cites "domain-by-domain" use, but I >am not >clear how that would work, in terms of configuration and cross-net >information >exchange. One question is how the server knows the 'domain' of the >client? > >The document should careful to distinguish what is existing practice, >versus >what is being explored as added possibilities. The difference in >concreteness >and certitude between the two is substantial. > >The document's use of the term whitelisting appears to continue an >existing, >recent use, for this type of mechanism. Unfortunately it directly >conflicts >with long-standing use of the term by the anti-abuse community for >whitelisting >in the DNS. Its use here also seems to be a mismatch with the word's >dictionary >semantics, which is most naturally used to distinguish yes/no choices, >rather >than either/or choices. So there is no intuitive sense of "goodness" >(whitelist >= yes) or "badness" (blacklist) for this use. The word "preferences" >seems more >in line with the meaning of the mechanism. > > > >Detailed Comments >================= > > >> Abstract >> >> The objective of this document is to describe what the whitelisting >> of DNS AAAA resource records is, hereafter referred to as DNS > >RRs are whitelisted? Isn't it the addresses and not the records that are >whitelisted? > >Does this mean putting whitelisting records into the DNS or does it mean >something else? > >Comcast's own considerable expertise notwithstanding, has this doc been >vetted >with a range of organizations that actually DO whitelisting? Has it been >circulated through MAAWG and APWG? Any comments from Spamhaus? The >Acknowledgements list does not seem to indicate a range of whitelist ops >folks >whose names I know. (But then, I only know a few...) > > >> whitelisting, as well as the implications of this emerging practice >> and what alternatives may exist. The audience for this document is >> the Internet community generally, including the IETF and IPv6 >> implementers. > >I suspect that product marketers won't have much interest in this. I >suspect >that the target for this is anti-abuse technical and operations staff. In >any >event, the targetting statement should be more precise. > > >> 1. Introduction >> >> This document describes the emerging practice of whitelisting of DNS > >One natural, semantic problem with the term 'whitelist' is that it does >not >really match the function being performed. The white/black distinction >implies >goodness -- or as Wikipedia says, "priviledge". Instead, the use here is >for >preference or priority. What would a "blacklist" be, here? Also note it >is not >obvious what it means to be whitelisted, here? Does it mean to choose >the AAAA >records or the A records? > >This is more like a 'Preference' or 'Configuration' list. > >At the least, the name for this should be IPv6 Resolver Whitelisting. It >makes >clear /what/ is being "whitelisted". > > >> AAAA resource records (RRs), which contain IPv6 addresses, hereafter >> referred to as DNS whitelisting. The document explores the > >This provides a name, but not a function. That is, it does not say what >this >mechanisms actually /does/ or is /for/. > > >> implications of this emerging practice are and what alternatives may >> exist. >> >> The practice of DNS whitelisting appears to have first been used by >> major web content sites (sometimes described herein as "highly- > >It's use for email anti-abuse dates back farther. > > <http://www.dnswl.org/> > > <http://en.wikipedia.org/wiki/DNSBL> > > ><http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/co >m.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html> > >Specifically within the context of the DNS, the term whitelisting is >therefore >made ambiguous. > >A google query for "whitelist dns" also demonstrates the history and >current >ambiguity. > > >> trafficked domains" or "major domains"). These web site operators, >> or domain operators, observed that when they added AAAA resource >> records to their authoritative DNS servers in order to support IPv6 >> access to their content that a small fraction of end users had slow >> or otherwise impaired access to a given web site with both AAAA and A >> resource records. The fraction of users with such impaired access >> has been estimated to be roughly 0.078% of total Internet users >> [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 >> Brokenness]. Thus, in an example Internet Service Provider (ISP) >> network of 10 million users, approximately 7,800 of those users may >> experience such impaired access. > >At a minimum, these sorts of statistics need to be normalized across IPv6 >users/traffic, given how small a percentage that is, in total users and >total >traffic. If that's what is meant it should be stated. If it isn't, the >statistic should be recalculated and explained a bit more precisely. > > >> As a result of this impairment affecting end users of a given domain, >> a few major domains have either implemented DNS whitelisting or are >> considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. >> When implemented, DNS whitelisting in practice means that a domain's >> authoritative DNS will return a AAAA resource record to DNS recursive >> resolvers [RFC1035] on the whitelist, while returning no AAAA >> resource records to DNS resolvers which are not on the whitelist. It > >This explanation of the function should be offered sooner and should be >summarized in the Abstract. > > >> is important to note that these major domains are motivated by a >> desire to maintain a high-quality user experience for all of their > >Rather than being important to note, this sentence sounds oddly like >marketing >hype, in a technical specification. It is gratuitous because specified >features >are never added to /lower/ the quality of the user experience, for >example. > >In addition, the mechanism also affects client activity that has no user >directly involved. > > >> users. By engaging in DNS whitelisting, they are attempting to >> shield users with impaired access from the symptoms of those >> impairments. > >The /technical/ statement that should be here is that they are attempting >to >provide a work-around for problematic behaviors in dual-stack IPv4/IPv6 >environments. > >The paper should make more clear exactly where the problem lies and when. >If it >can occur for a number of reasons, explaining each of those scenarios >would be >useful. > > >> Critics of the practice of DNS whitelisting have articulated several >> concerns. Among these are that: >> >> o DNS whitelisting is a very different behavior from the current >> practice concerning the publishing of IPv4 address resource >> records, >> >> o that it may create a two-tiered Internet, >> >> o that policies concerning whitelisting and de-whitelisting are >> opaque, >> >> >> >> >> >> Livingood Expires August 26, 2011 [Page 5] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> o that DNS whitelisting reduces interest in the deployment of IPv6, >> >> o that new operational and management burdens are created, > >well, yeah... in fact it should be noted that the burdens are particularly >onerous at scale. > > >> o and that the costs and negative implications of DNS whitelisting >> outweigh the perceived benefits, compared to fixing underlying >> impairments. > >and it doesn't scale. > >and it violates an extremely basic premise of cross-Internet >interoperability by >requiring prior arrangement. > > >> This document explores the reasons and motivations for DNS >> whitelisting. It also explores the outlined concerns regarding this >> practice. Readers will hopefully better understand what DNS >> whitelisting is, why some parties are implementing it, and what >> criticisms of the practice exist. >> >> >> 2. How DNS Whitelisting Works > >How IPv6 AAAA DNS Whitelisting Works. > >(Anti-spam DNS Whitelisting works rather differently...) > > >> DNS whitelisting is implemented in authoritative DNS servers. These >> servers implement IP address-based restrictions on AAAA query >> responses. So far, DNS whitelisting has been primarily implemented >> by web server operators deploying IPv6-enabled services. For a given > >Really? This is web-specific? The same restrictions are not applied for >other >applications? > >So if the same client-side hosts attempt to contact the server for email >or >xmpp, they won't get the same handling? > > >> 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. > > >> the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive > >Either address type can be listed? So this really is a pure 'preferences' >mechanism? > >Which settings count as whitelisting? Do any count as blacklisting? > > > >> resolvers on the Internet, which have been authorized to receive AAAA >> resource record responses. These DNS recursive resolvers are >> operated by third parties, such as ISPs, universities, governments, >> businesses, and individual end users. If a DNS recursive resolver IS >> NOT matched in the ACL, then AAAA resource records will NOT be sent >> in response to a query for a hostname in the example.com domain. > >This configuration appears to ensure the maximum barrier to adoption for >IPv6, >since it means that IPv6 will not work automatically. It will only work >for >hosts that are manually configured to receive responses with v6 records. > >That's a rather major implication. It's a default that is probably meant >to >apply during the very early stages of adoption, when there are few users >of the >newer mechanism. > >It's probably worth discussing it in more detail, including discussing >when to >change the default... > > >> However, if a DNS recursive resolver IS matched in the ACL, then AAAA >> resource records will be sent in response to a query for a given >> hostname in the example.com domain. While these are not network- >> layer access controls they are nonetheless access controls that are a >> factor for end users and other parties like network operators, >> especially as networks and hosts transition from one network address >> family to another (IPv4 to IPv6). > > >Also, all of this clarifies the function of this listing mechanism and >suggests >a very different name, to be more precise and accurate in naming it: > > IPv6 DNS Response Preference List. > > >> 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. The large majority of >> DNS resolvers on the Internet will therefore receive only A resource >> records containing IPv4 addresses. Thus, quite simply, the >> authoritative server hands out different answers depending upon who >> is asking; with IPv4 and IPv6 resource records for some on the >> authorized whitelist, and only IPv4 resource records for everyone >> else. See Section 2.1 and Figure 1 for a description of how this >> >> >> >> Livingood Expires August 26, 2011 [Page 6] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> works. >> >> 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. >> >> 2.1. Description of the Operation of DNS Whitelisting >> >> The system logic of DNS whitelisting is as follows: >> >> 1. The authoritative DNS server for example.com receives DNS queries >> for the A (IPv4) and AAAA (IPv6) address resource records for the >> FQDN www.example.com, for which AAAA (IPv6) resource records >> exist. > >This means that the mechanism is /only/ triggered when /both/ address >records >are queried? A query for only one type of address record won't trigger >the list >lookup? I think that doesn't match other statements in the document. > > >> 2. The authoritative DNS server examines the IP address of the DNS >> recursive resolver sending the AAAA (IPv6) query. > >"examines"? Examines it for what? What does this step mean? > > >> 3. The authoritative DNS server checks this IP address against the >> access control list (ACL) that is the DNS whitelist. >> >> 4. If the DNS recursive resolver's IP address IS matched in the ACL, >> then the response to that specific DNS recursive resolver can >> contain AAAA (IPv6) address resource records. > >Oh. This is not about whether to send responses /over/ v6 vs. v4? This >is >whether to /include/ a particular type of RR in responses??? > >In that case an appropriate name for this mechanism is more like: > > DNS Response Content Preference List > >And this seems even less like an ACL than it did before. (I assume the >justification is that access is being prevented by virtue of not >supplying the >address, but still...) > > >> 5. If the DNS recursive resolver's IP address IS NOT matched in the >> ACL, then the response to that specific DNS recursive resolver >> cannot contain AAAA (IPv6) address resource records. In this >> case, the server should return a response with the response code >> (RCODE) being set to 0 (No Error) with an empty answer section >> for the AAAA record query. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Livingood Expires August 26, 2011 [Page 7] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> --------------------------------------------------------------------- >> A query is sent from a DNS recursive resolver that IS NOT on the DNS >> whitelist: >> >> Request Request >> www.example.com www.example.com >> AAAA +-------------+ AAAA +-----------------+ >> ++--++ ---------> | RESOLVER | ---------> | www.example.com | >> || || A | **IS NOT** | A | IN A exists | >> +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | >> +--------+ A | example.com | A | | >> Host <--------- | WHITELIST | <--------- | | >> Computer A Record +-------------+ A Record +-----------------+ >> Response DNS Recursive Response example.com >> (only IPv4) Resolver (only IPv4) Authoritative >> #1 Server >> --------------------------------------------------------------------- >> A query is sent from a DNS recursive resolver that IS on the DNS >> whitelist: >> >> Request Request >> www.example.com www.example.com >> AAAA +-------------+ AAAA +-----------------+ >> ++--++ ---------> | RESOLVER | ---------> | www.example.com | >> || || A | **IS** | A | IN A exists | >> +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | >> +--------+ AAAA | example.com | AAAA | | >> Host <--------- | WHITELIST | <--------- | | >> Computer A | | A | | >> <--------- | | <--------- | | >> A and AAAA +-------------+ A and AAAA +-----------------+ >> Record DNS Recursive Record example.com >> Responses Resolver Responses Authoritative >> (IPv4+IPv6) #2 (IPv4+IPv6) Server >> --------------------------------------------------------------------- >> >> Figure 1: DNS Whitelisting - Functional Diagram > >This diagram is confusing to me. I suspect that a protocol exchange >sequence >format, in the style of: > > Host Resolver 1 Authoritative > > ----------> > ---------> > <--------- > <---------- > >will be considerably more helpful. > > >> 3. What Problems Are Implementers Trying To Solve? > >This is a very useful section and it is probably worth moving it higher, >to >precede the 'how it works' section. > > >> 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). > >By the way, what does 'impaired v6 access' mean? > >I think there needs to be a simple, direct description of what occurs >without >this mechanism. > >For example, perhaps you mean that a host can send DNS queries using IPv6 >but >cannot receive DNS responses over IPv6? Perhaps you mean that the host >can send >IPv6 but cannot receive it. (That's a different scale and scope of >problem from >the first example I gave.) > >This brief, summary problem statement should be included in the Abstract, >to >make /much/ more clear what this mechanism is for. > > >> 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. It would affect access to all or most dual >> >> >> >> Livingood Expires August 26, 2011 [Page 8] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> stack services to which the user attempts to connect. This negative >> end user experience can range from someone slower than usual (as >> compared to native IPv4-based access), to extremely slow, to no >> access to the domain whatsoever. > >Rather than repeat that this is about end-users, it sounds more that this >is >about whether a service works or does not work, whether a user is directly >present or not. > > >> While one can debate whether DNS whitelisting is the optimal solution >> to the end user experience problem, it is quite clear that DNS >> whitelisting implementers are interested in maximizing the >> performance of their services for end users as a primary motivation >> for implementation. > >You keep citing 'performance' but haven't described what sort of >performance >degradation takes place. Is this really about relatively better or worse >performance -- and if so, how -- or is this about working or not working? > >Also rather than saying what implementers are interested in, it's >probably more >helpful to note that the practice is now significantly established and >therefore >worth documenting, independent of its possible controversy. > > >> 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? > > >> those recursive resolvers have expressed a concern that their IPv6 > >I suspect that it's not resolvers that are doing the expressing, since >their >vocabulary is usually too limited... > > >> 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? > >Wow. I do understand why service providers often have to work around >silliness >at the client side, but this problem at the client side seems particularly >egregious. > > >> 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 > >Again this goal of short-term usage is worth noting earlier, including in >the >Abstract. > > >> 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). >> >> Some implementers with highly-trafficked domains have explained that >> DNS whitelisting is a necessary, though temporary, risk reduction >> tactic intended to ease their transition to IPv6 and minimize any >> perceived risk in such a transition. As a result, they perceive this >> as a tactic to enable them to incrementally enable IPv6 connectivity >> to their domains during the early phases of their transition to IPv6. >> >> 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. >> >> >> 4. Concerns Regarding DNS Whitelisting >> >> 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 > >I think the implications are not conditional; they exist rather than being >potential. The 'potential' is that what is implicated will come to pass. > > > >> >> Livingood Expires August 26, 2011 [Page 9] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> enumerated here and in Section 7. > >Pro forma question: Why are implications discussed in multiple places? > > >> Some parties in the Internet community, including ISPs, are concerned > >This style of text personalizes the issues unnecessarily (IMO). It does >not >really matter who holds the concerns, or else they'd be described more >precisely. > >I suggest merely noting that there are concerns and then listing and >discussing >the concerns, rather than adding text to attribute the concerns to >others, even >if the conclusion of your text is that a particular concern is not valid. > > >> that the practice of DNS whitelisting for IPv6 address resource >> records represents a departure from the generally accepted practices >> regarding IPv4 address resource records in the DNS on the Internet >> [Whitelisting Concerns]. These parties explain their belief that for > >"These parties explain their belief" is an example of personalization >that is >not needed. This isn't about the believers. It is about possible >problems. > > >> A resource records, containing IPv4 addresses, once an authoritative >> server operator adds the A record to the DNS, then any DNS recursive >> resolver on the Internet can receive that A record in response to a > >This does not appear to be a grammatically valid sentence. My guess is >that >deleting "A resource... addresses" fixes this. > >And by the way, the document's reference to "recursive" resolvers is >mostly >likely incorrect. The problem is not restricted only to that very >specific type >of resolver, is it? > >If in fact it /is/ specific to them -- and your following text describes >an >indirect effects scenario where it might be -- I suggest calling out the >configuration at the beginning, along the lines of: > > One way the problem with returning AAAA records can be experienced >is when >recursive resolvers are used. Although that resolver might support IPv6, >its >client hosts might not. So, returning an AAAA record will mean that these >limited hosts will be given an unusable address. > >And this type of description belongs in the text describing the motivating >problem(s), rather than buried in the 'concerns' discussion. > >(The text, here, pertains to A records, but the problem I've described >uses the >same configuration but for AAAA records with mixed v6 support.) > > >> query. By extension, this means that any of the hosts connected to >> any of these DNS recursive resolvers can receive the IPv4 address >> resource records for a given FQDN. This enables new server hosts >> which are connected to the Internet, and for which a fully qualified >> domain name (FQDN) such as www.example.com has been added to the DNS >> with an IPv4 address record, to be almost immediately reachable by >> any host on the Internet. In this case, these new servers hosts >> become more and more widely accessible as new networks and new end >> user hosts connect to the Internet over time, capitalizing on and >> increasing so-called "network effects" (also called network >> externalities). It also means that the new server hosts do not need >> to know about these new networks and new end user hosts in order to >> make their content and applications available to them, in essence >> that each end in this end-to-end model is responsible for connecting >> to the Internet and once they have done so they can connect to each >> other without additional impediments or middle networks or >> intervening networks or servers knowing about these end points and >> whether one is allowed to contact the other. > >Hmmm. This rather lengthy bit of prose appears merely to be explaining >the >basic and long-standing DNS value proposition??? > > >> In contrast, the concern is that DNS whitelisting may fundamentally >> change this model. In the altered DNS whitelisting end-to-end model, >> one end (where the end user is located) cannot readily connect to the >> other end (where the content is located), without parts of the middle >> (recursive resolvers) used by one end (the client, or end user hosts) >> being known to an intermediary (authoritative nameservers) and >> approved for access to the resource at the end. As new networks >> connect to the Internet over time, those networks need to contact any >> and all domains which have implemented DNS whitelisting in order to >> apply to be added to their DNS whitelist, in the hopes of making the >> content and applications residing on named server hosts in those >> domains accessible by the end user hosts on that new network. >> Furthermore, this same need to contact all domains implementing DNS >> whitelisting also applies to all pre-existing (but not whitelisted) >> networks connected to the Internet. >> >> In the current IPv4 Internet when a new server host is added to the >> Internet it is generally widely available to all end user hosts and >> networks, when DNS whitelisting of IPv6 resource records is used, > >If it is available to the hosts, it is available to the network. > >networks, when -> networks. When > > >> >> >> >> Livingood Expires August 26, 2011 [Page 10] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> these new server hosts are not accessible to any end user hosts or >> networks until such time as the operator of the authoritative DNS > >They are still accessible. The IP-level mechanisms still work. > >They are not reachable when using the domain name. > > >> servers for those new server hosts expressly authorizes access to >> those new server hosts by adding DNS recursive resolvers around the >> Internet to the ACL. This has the potential to be a significant > >This is a good example of the reason the term ACL is inappropriate: It >implies >a security protection that does not actually exist. The hosts are still >accessible. > > >> change in reachability of content and applications by end users and >> networks as these end user hosts and networks transition to IPv6, >> resulting in more (but different) breakage. A concern expressed is >> that if much of the content that end users are most interested in is >> not accessible as a result, then end users and/or networks may resist >> adoption of IPv6 or actively seek alternatives to it, such as using >> multi-layer network address translation (NAT) techniques like NAT444 >> [I-D.shirasaki-nat444] on a long-term basis. There is also concern >> that this practice also could disrupt the continued increase in >> Internet adoption by end users if they cannot simply access new >> content and applications but must instead contact the operator of >> their DNS recursive resolver, such as their ISP or another third >> party, to have their DNS recursive resolver authorized for access to >> the content or applications that interests them. Meanwhile, these >> parties say, over 99.9% of the other end users that are also using >> that same network or DNS recursive resolver are unable to access the >> IPv6-based content, despite their experience being a positive one. >> >> 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? > >That's considered a high percentage? > >Even if it is 8%, is that considered high? > > >> 5.2. Similarities to DNS Load Balancing >> >> DNS whitelisting also has some similarities to DNS load balancing. >> There are of course many ways that DNS load balancing can be >> performed. In one example, multiple IP address resource records (A >> and/or AAAA) can be added to the DNS for a given FQDN. This approach >> is referred to as DNS round robin [RFC1794]. DNS round robin may >> also be employed where SRV resource records are used [RFC2782]. > >Right, but that's algorithmic rather than involving the manual method, >described >here. So it does not seem comparable. > > >> 6. Likely Deployment Scenarios >> >> In considering how DNS whitelisting may emerge more widely, there are >> two likely deployment scenarios, which are explored below. >> >> In either of these deployment scenarios, it is possible that >> reputable third parties could create and maintain DNS whitelists, in >> much the same way that blacklists are used for reducing email spam. >> In the email context, a mail operator subscribes to one or more of >> these lists and as such the operational processes for additions and >> deletions to the list are managed by a third party. A similar model >> could emerge for DNS whitelisting, whether deployment occurs >> universally or on an ad hoc basis. > >The challenges of email whitelists and blacklists should be cited, since >it >provides a rich base of experience for such an effort, at scale. > > >> 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis >> >> The seemingly most likely deployment scenario is where some > >Most likely? This is not already established practice? > > >> authoritative DNS server operators implement DNS whitelisting but >> many or most others do not do so. What can make this scenario >> challenging from the standpoint of a DNS recursive resolver operator >> is determining which domains implement DNS whitelisting, particularly >> since a domain may not do so as they initially transition to IPv6, >> and may instead do so later. Thus, a DNS recursive resolver operator >> >> >> >> Livingood Expires August 26, 2011 [Page 13] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> may initially believe that they can receive AAAA responses as a >> domain adopts IPv6, but then notice via end user reports that they no >> longer receive AAAA responses due to that domain adopting DNS >> whitelisting. Of course, a domain's IPv6 transition may be >> effectively invisible to recursive server operators due to the effect >> of DNS whitelisting. > >This suggests that every listing at the server needs a contact record for >periodic checks whether to renew the listing. > > >> >> In contrast to a universal deployment of DNS whitelisting >> Section 6.2, deployment on an ad hoc basis is likely to be >> significantly more challenging from an operational, monitoring, and > >Oh? Use in small scale is more challenging than use of manual exceptions >list >at large scale? That's a very unexpected view. > > >> 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? > > >> whitelisting. As a result, discovering which domains implement DNS >> whitelisting, in order to differentiate them from those that do not, >> is likely to be challenging. >> >> One benefit of DNS whitelisting being deployed on an ad hoc basis is >> that only the domains that are interested in doing so would have to >> upgrade their authoritative DNS servers in order to implement the >> ACLs necessary to perform DNS whitelisting. >> >> In this potential deployment scenario, it is also possible that a >> given domain will implement DNS whitelisting temporarily. A domain, >> particularly a highly-trafficked domain, may choose to do so in order >> to ease their transition to IPv6 through a selective deployment and >> minimize any perceived risk in such a transition. >> >> 6.2. Deploying DNS Whitelisting Universally >> >> The least likely deployment scenario is one where DNS whitelisting is >> implemented on all authoritative DNS servers, across the entire >> Internet. While this scenario seems less likely than ad hoc >> deployment due to some parties not sharing the concerns that have so >> far motivated the use of DNS whitelisting, it is nonetheless >> conceivable that it could be one of the ways in which DNS >> whitelisting is deployed. > >Significantly, the partial-deployment model casts this mechanism as a >transition >expedient -- as the document reasonably describes it -- whereas universal >deployment casts it as a fundamental change to the architecture. > >Given that it would take decades to achieve relatively full deployment of >this >'across the entire Internet', what is the benefit of discussing this >highly >unlikely scenario? Is it really "conceivable"? I doubt it. If you think >otherwise, the paper needs to explore the deployment and adoption issues >in much >more detail, because I don't see how it could work. > > >> In order for this deployment scenario to occur, it is likely that DNS >> whitelisting functionality would need to be built into all >> authoritative DNS server software, and that all operators of >> authoritative DNS servers would have to upgrade their software and >> enable this functionality. It is likely that new Internet Draft >> documents would need to be developed which describe how to properly >> configure, deploy, and maintain DNS whitelisting. As a result, it is >> >> >> >> Livingood Expires August 26, 2011 [Page 14] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> unlikely that DNS whitelisting would, at least in the next several >> years, become universally deployed. Furthermore, these DNS >> whitelists are likely to vary on a domain-by-domain basis, depending >> upon a variety of factors. Such factors may include the motivation >> of each domain owner, the location of the DNS recursive resolvers in >> relation to the source content, as well as various other parameters >> that may be transitory in nature, or unique to a specific end user >> host type. 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. >> >> While this scenario may be unlikely, it may carry some benefits. >> First, parties performing troubleshooting would not have to determine >> whether or not DNS whitelisting was being used, as it always would be >> in use. In addition, if universally deployed, it is possible that >> the criteria for being added to or removed from a DNS whitelist could >> be standardized across the entire Internet. Nevertheless, even if >> uniform DNS whitelisting policies were not standardized, is also >> possible that a central registry of these policies could be developed >> and deployed in order to make it easier to discover them, a key part >> of achieving transparency regarding DNS whitelisting. > >Is any of this paragraph realistic? Obviously my asking means I don't it >is. >These seem to be of theoretical rather than pragmatic interest. ("If >everyone >refuses to shoot, there will be no wars.") > >It's true that this is an "implications" paper rather than a BCP, but >still... > > >> >> 7. Implications of DNS Whitelisting >> >> There are many potential implications of DNS whitelisting. The key >> potential implications are detailed below. >> >> 7.1. Architectural Implications >> >> DNS whitelisting could be perceived as modifying the end-to-end model >> and/or the general notion of the architecture that prevails on the > >I'll suggest that perception is not a major issue about a technical topic >like >this. (It's not entirely irrelevant, of course, but I suspect it is >quite minor.) > >The major issue is whether it /actually/ modifies the end-to-end nature >of the >DNS. And I think it does, as well as modifying the "spontaneous >interoperability" expectation for most Internet mechanism, since it >requires >prior registration. > > >> 7.2. Public IPv6 Address Reachability Implications >> >> The predominant experience of end user hosts and servers on the IPv4- >> addressed Internet today is that when a new server with a public IPv4 >> address is added to the DNS, that it is then globally accessible by > >This sentence is not quite correct, in strict technical terms. Since >this is a >technical discussion, we need to be precise: the host is reachable when >the >routing tables make it reachable. That's strictly a mapper of IP Address >handling, not name-to-address mapping. > >What you mean is that its domain name is immediately useful for reaching >it. > > >> IPv4-addressed hosts. This is a generalization and in Section 5 >> there are examples of common cases where this may not necessarily be >> the case. For the purposes of this argument, that concept of >> accessibility can be considered "pervasive reachability". It has so >> far been assumed that the same expectations of pervasive reachability >> would exist in the IPv6-addressed Internet. However, if DNS >> whitelisting is deployed, this will not be the case since only end >> user hosts using DNS recursive resolvers which are included in the > >again, you mean /name-based/ reachability. > > >> >> >> >> Livingood Expires August 26, 2011 [Page 16] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> ACL of a given domain using DNS whitelisting would be able to reach >> new servers in that given domain via IPv6 addresses. The expectation >> of any end user host being able to connect to any server (essentially >> both hosts, just at either end of the network), defined here as >> "pervasive reachability", will change to "restricted reachability" >> with IPv6. >> >> Establishing DNS whitelisting as an accepted practice in the early >> phases of mass IPv6 deployment could well establish it as an integral >> part of how IPv6 DNS resource records are deployed globally. As a >> result, it is then possible that DNS whitelisting could live on for >> decades on the Internet as a key foundational element of domain name >> management that we will all live with for a long time. > >(that last sentence could benefit from some editing.) > > >> It is a critical to understand that the concept of reachability >> described above depends upon a knowledge or awareness of an address >> in the DNS. Thus, in order to establish reachability to an end >> point, a host is dependent upon looking up an IP address in the DNS > >If this section were started with a sentence like this, then there would >not be >a problem with the other references' being confused with address-based >routing >reachability. > > >> when a FQDN is used. When DNS whitelisting is used, it is quite >> likely the case that an IPv6-enabled end user host could ping or >> connect to an example server host, even though the FQDN associated >> with that server host is restricted via a DNS whitelist. Since most > >First, I suspect that "example" doesn't add meaning to the sentence. >Second, >pinging and connecting might happen with or without the whitelist entry. >So I >do not understand what import there is in this sentence. > > >> Internet applications and hosts such as web servers depend upon the >> DNS, and as end users connect to FQDNs such as www.example.com and do >> not remember or wish to type in an IP address, the notion of >> reachability described here should be understood to include knowledge >> how to associate a name with a network address. > >Again, this 'premise' statement should introduce the sub-section, not end >it. > > >> >> 7.3. Operational Implications >> >> This section explores some of the operational implications which may >> occur as a result of, are related to, or become necessary when >> engaging in the practice of DNS whitelisting. >> >> 7.3.1. De-Whitelisting May Occur > >The more general version of this issue is 'synchronization'. Entries in >the >whitelist need to be synchronized with host status and capabilities. > > >> It is possible for a DNS recursive resolver added to a whitelist to >> then be removed from the whitelist, also known as de-whitelisting. >> Since de-whitelisting can occur, through a decision by the >> authoritative server operator, the domain owner, or even due to a >> technical error, an operator of a DNS recursive resolver will have >> new operational and monitoring requirements and/or needs as noted in >> Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. >> >> 7.3.2. Authoritative DNS Server Operational Implications >> >> Operators of authoritative servers may need to maintain an ACL a > >a -> on a (?) > > >> server-wide basis affecting all domains, on a domain-by-domain basis, >> >> >> Livingood Expires August 26, 2011 [Page 17] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> as well as on a combination of the two. As a result, operational > >I'm not really understanding the first sentence. One problem might be >that its >discussing an implication of some configuration or usage options that >have not >been previously specified, so that the reference here might be overly >cryptic. > >For example, I don't know what "affecting all domains" actually means. It >almost sounds as if it could mean "everyone gets AAAA records" or "no one >gets >AAAA records" yet I'm reaonably certain that is /not/ what is meant. > > >> practices and software capabilities may need to be developed in order >> to support such functionality. In addition, processes may need to be >> put in place to protect against inadvertently adding or removing IP >> addresses, as well as systems and/or processes to respond to such >> incidents if and when they occur. For example, a system may be >> needed to record DNS whitelisting requests, report on their status >> along a workflow, add IP addresses when whitelisting has been >> approved, remove IP addresses when they have been de-whitelisted, log >> the personnel involved and timing of changes, schedule changes to >> occur in the future, and to roll back any inadvertent changes. > >Might be worth starting with a simple, broad summary statement, possibly >along >the lines of: > > An AAAA DNS Whitelist serves as a critical infrastructure service; to >be >useful it needs careful and extensive administration, monitoring and >operation. > Each new and essential mechanism creates substantial follow-on support >costs. > > >> Operators may also need implement new forms of monitoring in order to >> apply change control, as noted briefly in Section 7.3.4. >> >> 7.3.3. DNS Recursive Resolver Server Operational Implications >> >> Operators of DNS recursive resolvers, which may include ISPs, >> enterprises, universities, governments, individual end users, and >> many other parties, are likely to need to implement new forms of >> monitoring, as noted briefly in Section 7.3.4. But more critically, >> such operators may need to add people, processes, and systems in >> order to manage large numbers of DNS whitelisting applications as >> part of their own IPv6 transition, for all domains that the end users >> of such servers are interested in now or in which they may be > >I think the summary observation is simple and should be stated directly: >This >is a manual mechanism that becomes expensive in time and personnel effort >as it >scales up. > > >> interested in the future. As anticipation of interesting domains is >> likely infeasible, it is more likely that operators may either choose >> to only apply to be whitelisted for a domain based upon one or more >> end user requests, or that they will attempt to do so for all domains >> that they can ascertain to be engaging in DNS whitelisting. > >"attempt to do so for all domain that they can ascertain to be engaging >in DNS >whitelisting" appears to be saying to do whitelisting for domains that do >whitelisting. I don't understand. > > >> >> When operators apply for DNS whitelisting for all domains, that may > >"apply for DNS whitelisting for all domains" -- again I'm not >understanding what >this means. > > >> 7.3.5. Implications of Operational Momentum >> >> It seems plausible that once DNS whitelisting is implemented it will >> be very difficult to deprecate such technical and operational >> practices. This assumption is based in an understanding of human > >in -> on > > >> 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. > >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?...) > > >> of Motion]. Thus, once DNS whitelisting is implemented it is quite >> likely that it would take considerable effort to deprecate the >> practice and remove it everywhere on the Internet - it will otherwise >> simply remain in place in perpetuity. To better illustrate this >> point, one could consider one example (of many) that there are many >> email servers continuing to attempt to query or otherwise check anti- >> >> >> >> Livingood Expires August 26, 2011 [Page 19] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> spam DNS blocklists which have long ago ceased to exist. >> >> 7.3.6. Troubleshooting Implications >> >> The implications of DNS whitelisted present many challenges, which >> have been detailed in Section 7. These challenges may negatively > >But this is /still/ section 7. Can you be more specific? Or perhaps say >"throughout this section". > > >> affect the end users' ability to troubleshoot, as well as that of DNS >> recursive resolver operators, ISPs, content providers, domain owners >> (where they may be different from the operator of the authoritative >> DNS server for their domain), and other third parties. This may make >> the process of determining why a server is not reachable >> significantly more complex. >> >> 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis >> >> Additional implications, should this be deployed on an ad hoc basis, >> could include scalability problems relating to operational processes, > >I'm pretty sure that scaling problems for this exist in all scenarios, >not just >ad hoc usage. > > >> monitoring, and ACL updates. In particular, it seems likely that as >> the number of domains that are using DNS whitelisting increases, as >> well as the number of IPv6-capable networks requesting to be >> whitelisted, that there is an increased likelihood of configuration >> and other operational errors, especially with respect to the ACLs >> themselves. >> >> 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 > >Actually the question of coordination is quite clear and rather >fundamental: > > No. > >Anyone believing otherwise needs to cite a successful example, at >Internet scale >and diversity, more recently than the 1983 switch to IP (which didn't go >all >that well anyhow...) > >Simple, unambiguous showstoppers should be stated in a simple and direct >manner. > When there is room for debate, softer language makes sense. Again, if >the >question of coordination really is subject to debate, then the basis >needs to be >stated. (Good luck!) > > >> 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. >> >> One further potential implication is that an end user with only an >> IPv4 address, using a DNS resolver which has not been whitelisted by >> any domains, would not be able to get any AAAA resource records. In >> such a case, this could give that end user the incorrect impression >> that there is no IPv6-based content on the Internet since they are >> unable to discover any IPv6 addresses via the DNS. >> >> 7.4. Homogeneity May Be Encouraged >> >> A broad trend which has existed on the Internet appears to be a move >> towards increasing levels of heterogeneity. One manifestation of > >increasing levels of heterogeneity -> more heterogeneity > >(I think heterogeneity does not have 'levels'.) > >Substantively: say the nature of the heterogeneity within the initial >claim. >For example, there is /less/ heterogeneity of ISPs, given industry >consolidation. There is less heterogeneity of infrastructure equipment >such as >routers. Etc. > > >> this is in an increasing number, variety, and customization of end >> user hosts, including home network, operating systems, client >> >> >> >> Livingood Expires August 26, 2011 [Page 20] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> software, home network devices, and personal computing devices. This >> trend appears to have had a positive effect on the development and >> growth of the Internet. A key facet of this that has evolved is the >> ability of the end user to connect any technically compliant device >> or use any technically compatible software to connect to the >> Internet. Not only does this trend towards greater heterogeneity >> reduce the control which is exerted in the middle of the network, >> described in positive terms in [Tussle in Cyberspace], [Rethinking >> the Internet], and [RFC3724], but it can also help to enable greater >> and more rapid innovation at the edges. >> >> An unfortunate implication of the adoption of DNS whitelisting may be >> the encouragement of a reversal of this trend, which would be a move > >the encouragement of -> to encourage > > >> 8.1. Implement DNS Whitelisting Universally >> >> One obvious solution is to implement DNS whitelisted universally, and >> to do so using some sort of centralized registry of DNS whitelisting >> policies, contracts, processes, or other information. This potential >> solution seems unlikely at the current time. > >I'm pretty sure that the only thing that is obvious about a premise of >universal >adoption is that it's not practical. Seriously. > >At the least, this section needs to be less cavalier about putting this >alternative forward as a "solution", especially given the rather serious >drawbacks/problems with it. > > >> 8.2. Implement DNS Whitelisting On An Ad Hoc Basis >> >> If DNS whitelisting is to be adopted, it is likely to be adopted on > >"is to be"? I thought it already had a significant installed base. > > >> this ad hoc, or domain-by-domain basis. Therefore, only those >> domains interested in DNS whitelisting would need to adopt the >> practice, though as noted herein discovering that they a given domain >> has done so may be problematic. Also in this scenario, ad hoc use by >> a particular domain may be a temporary measure that has been adopted >> to ease the transition of the domain to IPv6 over some short-term >> timeframe. >> >> 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? > > >> >> >> >> >> Livingood Expires August 26, 2011 [Page 23] >> >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 >> >> >> 8.3.1. Solving Current End User IPv6 Impairments >> >> A further extension of not implementing DNS whitelisting, is to also >> endeavor to actually fix the underlying technical problems that have >> prompted the consideration of DNS whitelisting in the first place, as >> an alternative to trying to apply temporary workarounds to avoid the >> symptoms of underlying end user IPv6 impairments. A first step is >> obviously to identify which users have such impairments, which would >> appear to be possible, and then to communicate this information to >> end users. Such end user communication is likely to be most helpful >> if the end user is not only alerted to a potential problem but is >> given careful and detailed advice on how to resolve this on their >> own, or where they can seek help in doing so. Section 11 may also be >> relevant in this case. >> >> One challenge with this option is the potential difficulty of >> motivating members of the Internet community to work collectively >> towards this goal, sharing the labor, time, and costs related to such >> an effort. Of course, since just such a community effort is now >> underway for IPv6, it is possible that this would call for only a >> moderate amount of additional work. > >This 'challenge' is at the core of /all/ adoption efforts for Internet >protocols >and services that entail distributed adoption. > > >> Despite any potential challenges, many in the Internet community are >> already working towards this goal and/or have expressed a general >> preference for this approach. > >If this is not already an organized effort with a website, sponsoring >consortium, or the like, it should be. If it is, then cite it in this >doc! > >> >> 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. > >I do not understand what this means. > >What is it for? What are the results? How are theyused? > > >> 9. Is DNS Whitelisting a Recommended Practice? >> >> Opinions in the Internet community concerning whether or not DNS >> whitelisting is a recommended practice are understandably quite >> varied. However, there is clear consensus that DNS whitelisting is >> at best a useful temporary measure which a domain may choose to > >If that is a clear consensus, then it makes even less sense to promote >the idea >of universal adoption, given the timescale needed to achieve it. > > >> 10. Security Considerations >> >> There are no particular security considerations if DNS whitelisting >> is not adopted, as this is how the public Internet works today with A >> resource records. > >Or rather, failure to adopt a mechanism like this or repair the underlying >problem, for those sites experiencing that problem, will result in a >denial of >service, albeit not an intentional one. Still, that's a pretty basic >security >issue. > > >d/ >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf > > >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf