Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt

From: [email-masked]
Date: Fri, 14 Oct 2011 06:45:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Considerations for Transitioning Content to IPv6
	Author(s)       : Jason Livingood
	Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt
	Pages           : 29
	Date            : 2011-10-14

   This document describes considerations for the transition of end user
   content on the Internet to IPv6.  While this is tailored to address
   end user content, which is typically web-based, many aspects of this
   document may be more broadly applicable to the transition to IPv6 of
   other applications and services.  This document explores the
   challenges involved in the transition to IPv6, potential transition
   techniques, possible transition phases, and other considerations.
   The audience for this document is the Internet community generally,
   particularly IPv6 implementers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 14 Oct 2011 13:54:36 +0000

This document previously went through WGLC but the IESG asked for a number of significant changes during IESG review, as I noted at the last IETF meeting. At that IETF meeting I also met with some key implementers who asked for major modifications to the I-D. During this time critical and valuable input came from Jari Arkko, Joel Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and Erik Kline.

I believe their input has *significantly* improved the document, and greatly appreciate that they took the time to do so. But, given all these changes, this also means that this WG will want to once again take a look at the document.

So… Please review @
http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

Thanks!
Jason

On 10/14/11 9:45 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "George, Wes" <[email-masked]>
Date: Fri, 14 Oct 2011 12:30:22 -0400

This is greatly improved. I have some additional comments -

Section 4 - I'm not sure I'd call these "transition techniques" - they are really more methods to resolve or reduce the risk of impaired IPv6 connectivity. Transition techniques is unfortunately a pretty overloaded term right now, but usually refers to methods to enable IPv6 capability, especially in the case where one or more elements in the path don't properly support IPv6, rather than to manage impairment, and I think this will cause confusion.
4.2/5.2 - might call these protocol (or address-family)-specific FQDNS instead of IPv6 transition names. Again, transition is sort of an overloaded term.

I think this document is remiss in not mentioning Happy Eyeballs as another method to prevent end-user impact due to impaired IPv6 connectivity. I'm not sure if we could go so far as to say that a critical-mass deployment of Happy Eyeballs will obviate the need for DNS whitelisting, but it certainly can help a lot. Those who disagree with that idea would do well to provide examples of failure scenarios where HE would not prevent customer impact while DNS whitelisting would. I see in the appendix where this was added and then removed - I do not believe that the draft would be delayed by using it as an informative reference. Normative, yes, but not informative.

Also, what about formally discussing the alternative of responding with AAAA records only to DNS queries received via IPv6 transport as its own section within section 4? This is a means to derive some assumptions about IPv6 connectivity, but does come with risks, as it doesn't conclusively determine anything other than the fact that IPv6 connectivity is good between the recursive name server and the auth server, not necessarily all the way to the querying host, nor does it validate the path from the destination server provided in the AAAA record and the querying host. Some of your comments in section 4.3 in the bottom of page 9 and top of page 12 (4.3.1) speak to this, but it is currently discussed in the context of whitelisting. Actually, I think you're missing an opportunity to clarify that in the cases where whitelisting is being done, the onus is on the domain doing the whitelisting to ensure that the servers being whitelisted represent a network that has proven to their satisfaction that they are IPv6-ready and this will not create unacceptable risk of poor service to the downstream users of the whitelisted server. This is not really the case with the alternative where you respond with a AAAA for any IPv6-transported query, and that's an important distinction to make between the two.

When you discuss automated implementations, I don't think  that this is specific to whitelisting. It can equally be applied to blacklisting, so it may make sense to talk about this in more generic terms outside of the section on whitelisting. Most notably, it may be easier to do blacklisting automatically based on a consistently-applied probe/test (when it exceeds a certain number of failures for a given address range/ASN/DNS resolver), since this would be a means to detect problems and reduce risk without shutting out other well-behaved servers/hosts.

4.4 - you say "It is unclear
   when and if it may be appropriate for a domain to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls."
I'm concerned with leaving it at that. This is a good place to put in a warning that these, especially whitelists, should not be considered an open-ended deployment, and that before deploying blacklist/whitelist, content providers/domain owners should have concrete criteria and means for consistently (if not continuously) testing those criteria so that it is clear when the risk of impairment has dropped below their threshold and this can be removed. In other words, I would like us to say "black/whitelisting shouldn't be used for longer than is necessary" while still acknowledging that everyone has a slightly different value of necessary.

Thanks,

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Friday, October 14, 2011 9:55 AM
To: [email-masked]
Subject: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

So... Please review @

Thanks!
Jason

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Oct 2011 11:19:03 -0700

On Fri, Oct 14, 2011 at 09:30, George, Wes wrote:

> I think this document is remiss in not mentioning Happy Eyeballs as another
> method to prevent end-user impact due to impaired IPv6 connectivity. I’m not
> sure if we could go so far as to say that a critical-mass deployment of
> Happy Eyeballs will obviate the need for DNS whitelisting, but it certainly
> can help a lot.
>

Agreed, the draft should mention happy eyeballs.

>  Those who disagree with that idea would do well to provide examples of
> failure scenarios where HE would not prevent customer impact while DNS
> whitelisting would.
>

One thing that happy eyeballs doesn't help you with is MTU holes.

> Also, what about formally discussing the alternative of responding with
> AAAA records only to DNS queries received via IPv6 transport as its own
> section within section 4? This is a means to derive some assumptions about
> IPv6 connectivity, but does come with risks, as it doesn’t conclusively
> determine anything other than the fact that IPv6 connectivity is good
> between the recursive name server and the auth server, not necessarily all
> the way to the querying host, nor does it validate the path from the
> destination server provided in the AAAA record and the querying host.
>

Yes. If you want the draft document to be complete it should mention this
and why it's not necessarily a good idea because the fact that the resolver
has an IPv6 connection doesn't guarantee that the host has a working IPv6
connection. Also, it requires the website owner to publish AAAA glue
records, which can also affect performance (e.g., if there are resolvers
with broken IPv6).

> Actually, I think you’re missing an opportunity to clarify that in the
> cases where whitelisting is being done, the onus is on the domain doing the
> whitelisting to ensure that the servers being whitelisted represent a
> network that has proven to their satisfaction that they are IPv6-ready and
> this will not create unacceptable risk of poor service to the downstream
> users of the whitelisted server.
>

Yes, the draft doesn't say anything about how to measure this.

>  This is not really the case with the alternative where you respond with a
> AAAA for any IPv6-transported query, and that’s an important distinction to
> make between the two.
>

But if you respond with an AAAA record for any IPv6-transported query you're
not really checking whether the user has a working connection or not.

> When you discuss automated implementations, I don’t think  that this is
> specific to whitelisting. It can equally be applied to blacklisting, so it
> may make sense to talk about this in more generic terms outside of the
> section on whitelisting. Most notably, it may be easier to do blacklisting
> automatically based on a consistently-applied probe/test (when it exceeds a
> certain number of failures for a given address range/ASN/DNS resolver),
> since this would be a means to detect problems and reduce risk without
> shutting out other well-behaved servers/hosts.
>

That's definitely the way some operators will be doing it. There are a
couple of networks out there where the failure rate for IPv6 connections is
in the single-digit percentages. You can expect major websites not to hand
out IPv6 records to those networks unless happy eyeballs is pervasively
deployed.

> I’m concerned with leaving it at that. This is a good place to put in a
> warning that these, especially whitelists, should not be considered an
> open-ended deployment, and that before deploying blacklist/whitelist,
> content providers/domain owners should have concrete criteria and means for
> consistently (if not continuously) testing those criteria so that it is
> clear when the risk of impairment has dropped below their threshold and this
> can be removed. In other words, I would like us to say “black/whitelisting
> shouldn’t be used for longer than is necessary” while still acknowledging
> that everyone has a slightly different value of necessary.
>

Agreed. The broader issue with this draft is that it will shortly be
overtaken by events, as the major operators who employ whitelisting switch
to blacklisting and to unconditional AAAA records. So in effect this draft
is documenting a bootstrap phase that is nearly over. Not sure how much
value that has.

Cheers,
Lorenzo

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Oct 2011 11:29:25 -0700

> One thing that happy eyeballs doesn't help you with is MTU holes.

There are two obvious solutions to the PMTU problem: don't filter ICMP/ICMPv6, and

https://tools.ietf.org/html/rfc4821
4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner.
     March 2007. (Format: TXT=75665 bytes) (Status: PROPOSED STANDARD)

I'm in favor of both...

Not sure what that has to do with AAAA Whitelisting.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Oct 2011 11:53:50 -0700

Hi Fred, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fred Baker
> Sent: Friday, October 14, 2011 11:29 AM
> To: Lorenzo Colitti
> Cc: [email-masked]
> Subject: Re: [v6ops] Update of 
> draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
> 
> 

Agreed. Since tunnels are a major source of MTU
uncertainty, however, IMHO it would be beneficial
if the tunnels could also take care of delivering
the necessary ICMPs. This might take some extra
care, as ICMPs can often be lost inside tunnels.

Fred
[email-masked]

> [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Oct 2011 10:22:24 +1300

Firstly I'd like to ask the WG Chairs for a bit more than a week
for the new WGLC. There are a lot of changes, that look like
improvements, but it needs a careful re-read.

On 2011-10-15 05:30, George, Wes wrote:
...
> I think this document is remiss in not mentioning Happy Eyeballs as another method to prevent end-user impact due to impaired IPv6 connectivity.

If that is added, I think a reference to RFC6343 is also appropriate. That
contains specific advice to content providers about how to significantly
mitigate one class of problems.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Oct 2011 14:40:07 -0700

On Fri, Oct 14, 2011 at 06:54, Livingood, Jason <
[email-masked]> wrote:

>   I believe their input has *significantly* improved the document, and
> greatly appreciate that they took the time to do so. But, given all these
> changes, this also means that this WG will want to once again take a look at
> the document.
>
>  So… Please review @
>

It is much improved, yes. Thank you for the rewrite. Here are some
additional comments from a full reading of the draft.

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?

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.

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

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.

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

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.

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.

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?

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.

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).

Cheers,
Lorenzo

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Oct 2011 14:47:36 -0700

OK, two weeks. Consider this a normal WGLC.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Oct 2011 14:57:46 +1300

Apart from my comment below, I agree that this document is much improved.

I have a slight quibble with the revised title. I understand why the
the title has been broadened, but it now claims a very wide scope:
  Considerations for Transitioning Content to IPv6

I don't think it covers all of that topic by any means (and neither
does draft-carpenter-v6ops-icp-guidance). Really this draft covers
mitigation of problems caused for content by v4/v6 coexistence.
How about:
  Considerations for Content Provision during IPv4/IPv6 Coexistence

Regards
   Brian Carpenter

...