With respect to the discussion of the whitelist/blacklist terminology I believe it can be stipulated that the authors, the document shepherd, the working group chairs disagree with your conclusions as to the appropriateness of the term whitelist. thanks joel On May 29, 2011, at 9:50 AM, Dave CROCKER 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=/com.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 > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf