draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational November 22, 2011 Intended status: Informational February 21, 2012
Expires: May 25, 2012 Expires: August 24, 2012
Considerations for Transitioning Content to IPv6 Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09
Abstract Abstract
This document describes considerations for the transition of end user This document describes considerations for the transition of end user
content on the Internet to IPv6. While this is tailored to address content on the Internet to IPv6. While this is tailored to address
end user content, which is typically web-based, many aspects of this end user content, which is typically web-based, many aspects of this
document may be more broadly applicable to the transition to IPv6 of document may be more broadly applicable to the transition to IPv6 of
other applications and services. This document explores the other applications and services. This document explores the
challenges involved in the transition to IPv6, potential migration challenges involved in the transition to IPv6, potential migration
tactics, possible migration phases, and other considerations. The tactics, possible migration phases, and other considerations. The
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2012. This Internet-Draft will expire on August 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.1. Security Considerations . . . . . . . . . . . . . . . . . 20 6.1. Security Considerations . . . . . . . . . . . . . . . . . 20
6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 21 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 22 6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 22
6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 23
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes considerations for the transition of end user This document describes considerations for the transition of end user
content on the Internet to IPv6. While this is tailored to address content on the Internet to IPv6. While this is tailored to address
end user content, which is typically web-based, many aspects of this end user content, which is typically web-based, many aspects of this
document may be more broadly applicable to the transition to IPv6 of document may be more broadly applicable to the transition to IPv6 of
other applications and services. The issues explored herein will be other applications and services. The issues explored herein will be
of particular interest to major web content sites (sometimes of particular interest to major web content sites (sometimes
skipping to change at page 10, line 17 skipping to change at page 10, line 17
of end users querying for one-time-use hostnames and then correlating of end users querying for one-time-use hostnames and then correlating
the domain's authoritative DNS server logs with their web server the domain's authoritative DNS server logs with their web server
logs. This can help implementers form a good picture of which DNS logs. This can help implementers form a good picture of which DNS
recursive resolvers have working IPv6 users behind them and which do recursive resolvers have working IPv6 users behind them and which do
not, what the latency impact of turning on IPv6 for any given DNS not, what the latency impact of turning on IPv6 for any given DNS
recursive resolver is, etc. In addition, given the current state of recursive resolver is, etc. In addition, given the current state of
global IPv6 deployment, this migration tactic allows content global IPv6 deployment, this migration tactic allows content
providers to selectively expose the availability of their IPv6 providers to selectively expose the availability of their IPv6
services. While opinions in the Internet community concerning DNS services. While opinions in the Internet community concerning DNS
Resolver Whitelisting are understandably quite varied, there is clear Resolver Whitelisting are understandably quite varied, there is clear
consensus that DNS Resolver Whitelisting can be a useful tactic a consensus that DNS Resolver Whitelisting can be a useful tactic for
domain may choose to use as they transition their services to IPv6. use during the transition of a domain to IPv6. In particular, some
In particular, some high-service-level domains view DNS Resolver high-service-level domains view DNS Resolver Whitelisting as one of
Whitelisting as one of the few practical and low-risk approaches the few practical and low-risk approaches enabling them to transition
enabling them to transition to IPv6, without which their transition to IPv6, without which their transition may not take place for some
may not take place for some time. However, there is also consensus time. However, there is also consensus that this practice is
that this practice is workable on a manual basis (see below) only in workable on a manual basis (see below) only in the short-term and
the short-term and that it will not scale over the long-term. Thus, that it will not scale over the long-term. Thus, some domains may
some domains may find DNS Resolver Whitelisting a beneficial find DNS Resolver Whitelisting a beneficial temporary tactic in their
temporary tactic in their transition to IPv6. transition to IPv6.
At the current time, generally speaking, a domain that implements DNS At the current time, generally speaking, a domain that implements DNS
Resolver Whitelisting does so manually. This means that a domain Resolver Whitelisting does so manually. This means that a domain
manually maintains a list of networks that are permitted to receive manually maintains a list of networks that are permitted to receive
IPv6 records (via their DNS resolver IP addresses) and that these IPv6 records (via their DNS resolver IP addresses) and that these
networks typically submit applications, or follow some other process networks typically submit applications, or follow some other process
established by the domain, in order to be added to the DNS Whitelist. established by the domain, in order to be added to the DNS Whitelist.
However, implementers foresee that a subsequent phase of DNS Resolver However, implementers foresee that a subsequent phase of DNS Resolver
Whitelisting is likely to emerge in the future, possibly in the near Whitelisting is likely to emerge in the future, possibly in the near
future. In this new phase a domain would return IPv6 and/or IPv4 future. In this new phase a domain would return IPv6 and/or IPv4
skipping to change at page 19, line 48 skipping to change at page 19, line 48
For a domain that decides to undertake DNS Resolver Whitelisting on a For a domain that decides to undertake DNS Resolver Whitelisting on a
manual basis, the domain may subsequently move to perform DNS manual basis, the domain may subsequently move to perform DNS
Resolver Whitelisting on an automated basis. This is explained in Resolver Whitelisting on an automated basis. This is explained in
Section 4.3, and can significantly ease any operational burdens Section 4.3, and can significantly ease any operational burdens
relating to a manually-maintained whitelist. relating to a manually-maintained whitelist.
5.5. Turning Off DNS Resolver Whitelisting 5.5. Turning Off DNS Resolver Whitelisting
Domains that choose to implement DNS Resolver Whitelisting generally Domains that choose to implement DNS Resolver Whitelisting generally
consider it to be a temporary measure. It is unclear how consider it to be a temporary measure. Many implementers have
implementers will judge when the network conditions will have changed announced that they plan to permanently turn off DNS Resolver
sufficiently to justify turning off DNS Resolver Whitelisting and/or Whitelisting beginning on the date of the World IPv6 Launch, on June
what the process and timing will be for discontinuing this practice, 6, 2012 [World IPv6 Launch]. For any implementers that do not turn
though the extent of IPv6 deployment to end users in networks, the off DNS Resolver Whitelisting at that time, it may be unclear how
state of IPv6-related impairment, and the maturity of IPv6 operations each and every one will judge when the network conditions to have
are all clearly factors. However, implementers may wish to take into changed sufficiently to justify turning off DNS Resolver
consideration that, as a practical matter, it will be impossible to Whitelisting. That being said, it is clear that the extent of IPv6
get to a point where there are no longer any IPv6-related deployment to end users in networks, the state of IPv6-related
impairments; some reasonably small number of hosts will inevitably be impairment, and the maturity of IPv6 operations are all important
left behind as end users elect not to upgrade them or as some hosts factors. Any such implementers may wish to take into consideration
are incapable of being upgraded. that, as a practical matter, it will be impossible to get to a point
where there are no longer any IPv6-related impairments; some
reasonably small number of hosts will inevitably be left behind as
end users elect not to upgrade them or as some hosts are incapable of
being upgraded.
5.6. Deploying DNS Blacklisting 5.6. Deploying DNS Blacklisting
Regardless of whether a domain has first implemented DNS Resolver Regardless of whether a domain has first implemented DNS Resolver
Whitelisting or has never done so, DNS Blacklisting as described in Whitelisting or has never done so, DNS Blacklisting as described in
Section 4.4 may become interesting. This may be at the point in time Section 4.4 may become interesting. This may be at the point in time
when domains wish to make their content widely available over IPv6 when domains wish to make their content widely available over IPv6
but still wish to protect end users of a few networks with well known but still wish to protect end users of a few networks with well known
IPv6 limitations from having a bad end user experience. IPv6 limitations from having a bad end user experience.
skipping to change at page 21, line 11 skipping to change at page 21, line 15
DNS security extensions defined in [RFC4033], [RFC4034], and DNS security extensions defined in [RFC4033], [RFC4034], and
[RFC4035] use cryptographic digital signatures to provide origin [RFC4035] use cryptographic digital signatures to provide origin
authentication and integrity assurance for DNS data. This is done by authentication and integrity assurance for DNS data. This is done by
creating signatures for DNS data on a Security-Aware Authoritative creating signatures for DNS data on a Security-Aware Authoritative
Name Server that can be used by Security-Aware Resolvers to verify Name Server that can be used by Security-Aware Resolvers to verify
the answers. Since DNS Resolver Whitelisting is implemented on an the answers. Since DNS Resolver Whitelisting is implemented on an
authoritative DNS server, which provides different answers depending authoritative DNS server, which provides different answers depending
upon which DNS resolver has sent a query, the DNSSEC chain of trust upon which DNS resolver has sent a query, the DNSSEC chain of trust
is not altered. So even though an authoritative DNS server will is not altered. So even though an authoritative DNS server will
selectively return AAAA resource records and/or A resource records, selectively return AAAA resource records and/or A resource records,
these resource records can certainly still be signed. As a result, these resource records can certainly still be signed. In practical
there should not be any negative impact on DNSSEC for those domains terms this means that two separate views or zones are used, each of
that have implemented both DNSSEC on their Security-Aware which is signed, so that whether or not particular resource records
Authoritative Name Servers and also implemented DNS Resolver exist, the existence or non-existence of the record can still be
Whitelisting. As for any party implementing DNSSEC of course, such validated using DNSSEC. As a result, there should not be any
domains should ensure that resource records are being appropriately negative impact on DNSSEC for those domains that have implemented
and reliably signed. both DNSSEC on their Security-Aware Authoritative Name Servers and
also implemented DNS Resolver Whitelisting. As for any party
implementing DNSSEC of course, such domains should ensure that
resource records are being appropriately and reliably signed.
However, network operators that run DNS recursive resolvers should be However, network operators that run DNS recursive resolvers should be
careful not to modify the responses received from authoritative DNS careful not to modify the responses received from authoritative DNS
servers. It is possible that some networks may attempt to do so in servers. It is possible that some networks may attempt to do so in
order to prevent AAAA record responses from going to end user hosts, order to prevent AAAA record responses from going to end user hosts,
due to some IPv6-related impairment or other lack of IPv6 readiness due to some IPv6-related impairment or other lack of IPv6 readiness
with that network. But when a network operates a Security-Aware with that network. But when a network operates a Security-Aware
Resolver, modifying or suppressing AAAA resource records for a Resolver, modifying or suppressing AAAA resource records for a
DNSSEC-signed domain could break the chain of trust established with DNSSEC-signed domain could break the chain of trust established with
DNSSEC. DNSSEC.
skipping to change at page 23, line 39 skipping to change at page 23, line 41
provided helpful and important guidance in the development of this provided helpful and important guidance in the development of this
document and/or in the development of the concepts covered in this document and/or in the development of the concepts covered in this
document. Other people assisted by performing a detailed review of document. Other people assisted by performing a detailed review of
this document, and then providing feedback and constructive criticism this document, and then providing feedback and constructive criticism
for revisions to this document, or engaged in a healthy debate over for revisions to this document, or engaged in a healthy debate over
the subject of the document. All of this was helpful and therefore the subject of the document. All of this was helpful and therefore
the following individuals merit acknowledgement: the following individuals merit acknowledgement:
- Bernard Aboba - Bernard Aboba
- Mark Andrews
- Jari Arkko - Jari Arkko
- Fred Baker - Fred Baker
- Ron Bonica - Ron Bonica
- Frank Bulk - Frank Bulk
- Brian Carpenter - Brian Carpenter
- Lorenzo Colitti - Lorenzo Colitti
- Alissa Cooper - Alissa Cooper
- Dave Crocker - Dave Crocker
- Ralph Droms - Ralph Droms
- Wesley Eddy - Wesley Eddy
- J.D. Falk - J.D. Falk
skipping to change at page 24, line 40 skipping to change at page 24, line 44
- Ray Hunter - Ray Hunter
- Joel Jaeggli - Joel Jaeggli
- Erik Kline - Erik Kline
- Suresh Krishnan - Suresh Krishnan
- Victor Kuarsingh - Victor Kuarsingh
- Marc Lampo
- Donn Lee - Donn Lee
- John Leslie - John Leslie
- John Mann - John Mann
- Danny McPherson - Danny McPherson
- Milo Medin - Milo Medin
- Martin Millnert - Martin Millnert
- Russ Mundy - Russ Mundy
- Thomas Narten - Thomas Narten
- Pekka Savola - Pekka Savola
- Robert Sparks - Robert Sparks
- Barbara Stark - Barbara Stark
skipping to change at page 26, line 33 skipping to change at page 26, line 39
9.2. Informative References 9.2. Informative References
[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de [Heise] Heise.de, "The Big IPv6 Experiment", Heise.de
Website http://www.h-online.com, January 2011, <http:// Website http://www.h-online.com, January 2011, <http://
www.h-online.com/features/ www.h-online.com/features/
The-big-IPv6-experiment-1165042.html>. The-big-IPv6-experiment-1165042.html>.
[I-D.ietf-v6ops-happy-eyeballs] [I-D.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-05 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07
(work in progress), October 2011. (work in progress), December 2011.
[IETF-77-DNSOP] [IETF-77-DNSOP]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6-Brokenness] [IPv6-Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, Reseaux IP Europeens (RIPE) 61st Meeting, November 2010,
skipping to change at page 28, line 7 skipping to change at page 28, line 13
Implementors Conference, June 2010, <http:// Implementors Conference, June 2010, <http://
sites.google.com/site/ipv6implementors/2010/agenda/ sites.google.com/site/ipv6implementors/2010/agenda/
IPv6_Whitelist_Operations.pdf>. IPv6_Whitelist_Operations.pdf>.
[Wild-Resolvers] [Wild-Resolvers]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm "Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010, Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>. <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[World IPv6 Launch]
The Internet Society, "World IPv6 Launch Website", 2012,
<http://www.worldipv6launch.org/>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-09: Minor updates to resolve questions in IETF Last Call
-08: Minor updates from v6ops WGLC -08: Minor updates from v6ops WGLC
-07: Significant re-write based on feedback from Jari Arkko, Joel -07: Significant re-write based on feedback from Jari Arkko, Joel
Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and
Erik Kline. Erik Kline.
-06: Removed the Open Issue #8 concerning the document name, at the -06: Removed the Open Issue #8 concerning the document name, at the
direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and
removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG
mailing list. Revised the Abstract and Intro as recommended by Tony mailing list. Revised the Abstract and Intro as recommended by Tony
 End of changes. 17 change blocks. 
39 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/