Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 Nov 2011 15:52:39 +0000

Thanks for the feedback, Lorenzo. All of this will be factored into the –08 update shortly. Specific responses inline below.

- Jason

On 10/14/11 5:40 PM, "Lorenzo Colitti" <[email-masked]<mailto:[email-masked]>> wrote:
1. I don't like the wording "high-traffic domains". This is not about traffic, it is about domains that desire to provide a service level that is greater than that offered, in the aggregate, by the current IPv6 Internet. When Google implemented whitelisting, we did not do so to control traffic, but because it was the only way to serve IPv6 users without imposing an unacceptable penalty to users on the rest of the Internet. To a certain extent the two go hand in hand, because large, high-traffic sites tend to have higher SLAs than smaller sites, but you could imagine other cases too, for example the website of a financial institution that doesn't serve a lot of traffic but has tightly bound SLAs. I'm not sure what you'd want to use instead. "High-SLA domains", maybe?

Ack. Changed to high-service-level domains.

2. "more recent measurements indicate this is declining [Impairment-Tracker]." It is not appropriate to cite that URL, because it stopped collecting meaningful data after December 2010 (with the exception of a single week in May 2011). Our brokenness numbers for the Internet as a whole have been mostly stable (actually, slowly rising) since after World IPv6 Day. June 10 was 0.074% and October 10 was 0.078%, with a mostly smooth linear rise in between.

Ack. Struck the reference and the last part of the sentence you were concerned with.

3. As Wes points out, "transition" is an overloaded term, so you might want to use something else. "Migration strategies"?

Ack. Changed to "Potential Migration Tactics".

4. Where you say "One potential tactic may be to identify which users have such impairments and then to communicate this information to affected users" you should note that in many cases this is forbidden by website operators' privacy policies.

Ack. That section already has a reference to the Privacy Considerations section. So I have added this to that section:
Finally, if a domain chooses to contact end userd directly concerning their IPv6 impairments, that domain should ensure that such communication is permissable under any applicable privacy policies of the domain or its websites.

5. In section 4.3, "is not users" -> "is not used".

Fixed.

6. I disagree with this piece of text:

   This tactic will not have a direct
   impact on reducing IPv6-related impairments Section 2.1, though it
   can help a domain address operational maturity concerns Section 2.2
   and concerns and risks related to traffic volume Section 2.3.

While whitelisting doesn't solve IPv6-related impairments, it can *avoid users that have them*. So it completely removes their impact in all but the few networks that are whitelisted. This is the primary reason why whitelisting exists, so it should be mentioned. You might also want to note that whitelisting allows a website operator to protect non-IPv6 networks (i.e., networks that don't support IPv6 and/or have plans to do so) from IPv6-related impairments in their networks.

Ack. Added this:
While DNS Resolver Whitelisting does not solve IPv6-related impairments, it can help a domain to avoid users that have them. As a result, the tactic removes their impact in all but the few networks that are whitelisted. DNS Resolver Whitelisting also allows a website operator to protect non-IPv6 networks (i.e. networks that do not support IPv6 and/or do not have plans to do so in the future) from IPv6-related impairments in their networks.

7. Where you say:

   Additionally, the IP
   address of a DNS recursive resolver is not a precise indicator of the
   IPv6 preparedness, or lack of IPv6-related impairment, of end user
   hosts which query (use) a particular DNS recursive resolver.

While it's true that the IP address of the resolver by itself is not an indicator of IPv6 preparedness, it's possible to measure the level of preparedness of the users behind any given resolver, e.g., by conducting ongoing large-scale measurements of IPv6 preparedness of clients using one-time hostnames and correlating the DNS logs with web logs. This is what Google does, and we have a pretty good picture of which DNS resolvers have working IPv6 users behind them and which don't, what the latency impact of turning on IPv6 for any given resolver is, etc.

Ack. Have now updated this section as follows, with the new underlined text:

While the IP addresses of DNS recursive resolvers on networks known to have deployed IPv6 may be an imperfect proxy for judging IPv6 preparedness, or lack of IPv6-related impairment, it is one of the better available methods at the current time. For example, implementers have found that it is possible to measure the level of IPv6 preparedness of the end users behind any given DNS recursive resolver by conducting ongoing measurement of the IPv6 preparedness of end users querying for one-time-use hostnames and then correlating the domain's authoritative DNS server logs with their web server logs. This can help implementers form a good picture of which DNS recursive resolvers have working IPv6 users behind them and which do not, what the latency impact of turning on IPv6 for any given DNS recursive resolver is, etc.

8. "If a DNS recursive resolver IS NOT matched in the whitelist, then AAAA resource records WILL NOT be sent". Do you need capitals here?

Ack. Changed to lower case.

9. I don't think the discussion of middleboxes in section 4.3.5 is relevant. It seems to me that "middleboxes" are boxes that are in the path of data packets, whereas DNS is completely orthogonal to actual data transport.

Understood. It is a minor note there. I think it is important to keep some pointer to such concerns so we don't lose that completely. I think this is a pretty well balanced section overall and would prefer not to tweak it further.

10. You may want to note that some DNS server implementations such as Bind 9.7 support filtering out AAAA replies if the original request was made over IPv4. This can be used by an operator to blacklist its own users. It was used by certain networks on World IPv6 Day (e.g., in Japan).

Understood, but this only works if someone is not using DNSSEC validation on their resolver. As this opens up a whole can of worms around DNS filtering with and without DNSSEC – tied to the whole SOPA/PIPA thing in the U.S., I'd prefer not to open that can of worms. ;-)

Thanks again,
Jason

---

From: John Mann <[email-masked]>
Date: Wed, 23 Nov 2011 11:01:23 +1100

Hi,

These comments apply to both -07 and -08

As for the title being over-reaching, you could soften it by changing it
from
   Considerations for Transitioning Content to IPv6
to
   Some Considerations for Transitioning Content to IPv6
;-)

---

3.  IPv6 Adoption Implications

---
Can you split the first paragraph into separate ideas e.g. at "A
substantial delay"

Also perhaps add something like
    Over time, there should be more IPv6-capable users and per-user traffic
should increase.
    Delaying (the start of) migration of content will mean that when it
does happen the Section 2.2 Volume-Based Concerns will be larger.

---

4.3.1.  How DNS Resolver Whitelisting Works

   ...  In the case of DNS Resolver

   Whitelisting, the resource that an end user seeks is a name, not an
   IP address or IP address family.  Thus, an end user is seeking a name
   such as www.example.com, without regard to the underlying IP address
   family (IPv4 or IPv6) which may be used to access that resource.

---
I think this is a bit wrong.
A user doesn't seek a "name", they seek a Internet host/service with a
particular name.

---
4.3.1.1

   1.  The authoritative DNS server for example.com receives DNS queries
       for the A (IPv4) and/or AAAA (IPv6) address resource records for
       the Fully Qualified Domain Name (FQDN) www.example.com, for which
       AAAA (IPv6) resource records exist.

   2.  The authoritative DNS server checks the IP address (IPv4, IPv6,
       or both) of the DNS recursive resolver sending the AAAA (IPv6)
       query against the whitelist that is the DNS Whitelist.

---
Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queries ??

The server does not know all the addresses of the resolver, only the
address used by the query packet.
Also  whitelist ... Whitelist.

    2. The authoritative DNS server checks the source IP address (IPv4 or
IPv6) of the DNS query packet
    from the DNS recursive resolver against the whitelist.

---

6.2.  Privacy Considerations

----
No mention is made here of recursive resolvers.

Questions for whole mailing list, and my view:

Are recursive resolver IP addresses privacy sensitive?
Not much since these addresses are visible on packets flowing across the
open Internet.

Can content providers share recursive resolver white/blacklists?
Probably, since it can improve the Internet without exposing information
widely.
Tricky due to responsibility / liability issues.

Should the general public not/be allowed to discover if a recursive
resolver is on a white/blacklist (as discussed in 4.4 for e-mail
blacklists)?
Probably, but extra work for content providers.

Should netblock owners be allowed to discover if recursive resolvers in
their address range are on a list?
Definitely

Thanks,
    John

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 23 Nov 2011 13:06:05 +0000

Inline.

- Jason

On 11/22/11 7:01 PM, "John Mann" <[email-masked]<mailto:[email-masked]>> wrote:
---

---
Can you split the first paragraph into separate ideas e.g. at "A substantial delay"

Also perhaps add something like
    Over time, there should be more IPv6-capable users and per-user traffic should increase.
    Delaying (the start of) migration of content will mean that when it does happen the Section 2.2 Volume-Based Concerns will be larger.

As this seems like a minor stylistic recommendation, I prefer not to make any more of those in the document given where it stands in the process.

---

   Whitelisting, the resource that an end user seeks is a name, not an IP address or IP address family.  Thus, an end user is seeking a name such as www.example.com<http://www.example.com>, without regard to the underlying IP address family (IPv4 or IPv6) which may be used to access that resource.

---
I think this is a bit wrong.
A user doesn't seek a "name", they seek a Internet host/service with a particular name.

This specific text was arrived at following detailed discussions with implementers, the WG chairs, and the ADs. I believe it works as-is, and implementers in particular felt very strongly that end users were seeking a name. I also think it largely stylistic to making it say they are seeking a host or service with a name rather than seeking a name (which is a simpler way of saying it anyway).

---
4.3.1.1

   1.  The authoritative DNS server for example.com<http://example.com> receives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource records for the Fully Qualified Domain Name (FQDN) www.example.com<http://www.example.com>, for which AAAA (IPv6) resource records exist.

   2.  The authoritative DNS server checks the IP address (IPv4, IPv6, or both) of the DNS recursive resolver sending the AAAA (IPv6) query against the whitelist that is the DNS Whitelist.

---
Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queries ??
The server does not know all the addresses of the resolver, only the address used by the query packet.
Also  whitelist ... Whitelist.

Yes, this was intended; this is AAAA whitelisting – not both A and AAAA whitelisting. Also, when referring to whitelisting and blacklisting generally, those terms are not capitalized on their own.

---

----

Are recursive resolver IP addresses privacy sensitive?
Not much since these addresses are visible on packets flowing across the open Internet.

It seems correct and obvious that the IP addresses of DNS recursive resolvers are not privacy sensitive.

Sure, why not.

Probably, since it can improve the Internet without exposing information widely.
Tricky due to responsibility / liability issues.

Liability concepts are out of scope of this document.

Should the general public not/be allowed to discover if a recursive resolver is on a white/blacklist (as discussed in 4.4 for e-mail blacklists)?
Probably, but extra work for content providers.

Should netblock owners be allowed to discover if recursive resolvers in their address range are on a list?
Definitely

I don't disagree but this is considered out of scope for this document based on IETF discussions. For information about those concerns, please see http://www.bitag.org/documents/BITAG_TWG_Report-DNS_Whitelisting.pdf

Thanks!
Jason

Thanks,
    John

---

From: John Mann <[email-masked]>
Date: Thu, 24 Nov 2011 09:30:54 +1100

On 24 November 2011 00:06, Livingood, Jason <
[email-masked]> wrote:

>
>   ---
> 4.3.1.1
>
>    1.  The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource records for the Fully Qualified Domain Name (FQDN) www.example.com, for which AAAA (IPv6) resource records exist.
>
>
>  Yes, this was intended; this is AAAA whitelisting – not both A and AAAA
> whitelisting. Also, when referring to whitelisting and blacklisting
> generally, those terms are not capitalized on their own.
>

Let me try making myself clearer.

a) "DNS query for the A (IPv4) and/or AAAA (IPv6) address resource records"

   A DNS query for the A resource records would match step 1.
   There is not much need to run this algorithm if the query only asks for
A records.

   I think a DNS query can only ask one question, and so can't explicitly
ask for "A and AAAA" records.

Also, there are other queries that can return AAAA records that the
requestor would then use -- in the Answer section
---
$ dig any www.apnic.net

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> any www.apnic.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57785
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:
;www.apnic.net. IN ANY

;; ANSWER SECTION:
www.apnic.net. 178 IN AAAA 2001:dc0:2001:11::194
www.apnic.net. 178 IN AAAA 2001:dc0:2001:11::211
www.apnic.net. 11 IN A 202.12.29.194
www.apnic.net. 11 IN A 202.12.29.211
...
---

Or in the Additional section
---
$ dig mx apnic.net

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> mx apnic.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4548
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 8, ADDITIONAL: 11

;; QUESTION SECTION:
;apnic.net. IN MX

;; ANSWER SECTION:
apnic.net. 137 IN MX 15 tofu.apnic.net.
apnic.net. 137 IN MX 35 hoisin.apnic.net.
apnic.net. 137 IN MX 40 fennel.apnic.net.

;; AUTHORITY SECTION:
apnic.net. 10429 IN NS ns3.apnic.net.
apnic.net. 10429 IN NS ns4.apnic.com.
apnic.net. 10429 IN NS ns4.apnic.net.
apnic.net. 10429 IN NS sec1.apnic.net.
apnic.net. 10429 IN NS sec1.authdns.ripe.net.
apnic.net. 10429 IN NS tinnie.arin.net.
apnic.net. 10429 IN NS tinnie.apnic.net.
apnic.net. 10429 IN NS ns1.apnic.net.

;; ADDITIONAL SECTION:
tofu.apnic.net. 2422 IN A 202.12.29.195
tofu.apnic.net. 2422 IN AAAA 2001:dc0:2001:11::195
hoisin.apnic.net. 9602 IN A 202.12.29.215
hoisin.apnic.net. 2402 IN AAAA 2001:dc0:2001:11::215
fennel.apnic.net. 2415 IN A 202.12.31.144
fennel.apnic.net. 2415 IN AAAA 2001:dc0:4001:1:0:1836:0:144
...
---
Note here that the AAAA records belong to the mail hosts, not to the FQDN
specified in the query.

So, I think better words could be
---
   1. The authoritative DNS server for example.com receives a DNS query
(AAAA, ANY, MX, NS etc) that could return AAAA (IPv6) resource records.
---

b) In step 2, the server does not know more than one addresses of the
resolver, only the particular address used in the query packet.
    The text ", or both" is wrong.

c) The text repeats itself where it says "the whitelist that is the DNS
Whitelist".

    John