draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational February 21, 2012 Intended status: Informational February 23, 2012
Expires: August 24, 2012 Expires: August 26, 2012
Considerations for Transitioning Content to IPv6 Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10
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 August 24, 2012. This Internet-Draft will expire on August 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 21, line 15 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. In practical these resource records must be signed, as well as any accompanying
terms this means that two separate views or zones are used, each of NextSECure (NSEC) information that proves existence and/or not-
which is signed, so that whether or not particular resource records existence of AAAA resource records. In practical terms this means
exist, the existence or non-existence of the record can still be that two separate views or zones are used, each of which is signed,
validated using DNSSEC. As a result, there should not be any so that whether or not particular resource records exist, the
negative impact on DNSSEC for those domains that have implemented existence or non-existence of the record can still be validated using
both DNSSEC on their Security-Aware Authoritative Name Servers and DNSSEC. As a result, there should not be any negative impact on
also implemented DNS Resolver Whitelisting. As for any party DNSSEC for those domains that have implemented both DNSSEC on their
implementing DNSSEC of course, such domains should ensure that Security-Aware Authoritative Name Servers and also implemented DNS
resource records are being appropriately and reliably signed. 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 22, line 19 skipping to change at page 22, line 21
Appropriate guidelines for any information sharing likely varies by Appropriate guidelines for any information sharing likely varies by
country and/or legal jurisdiction. Domains should consider any country and/or legal jurisdiction. Domains should consider any
potential privacy issues when considering what information can be potential privacy issues when considering what information can be
shared. If a domain does publish or share detailed impairment shared. If a domain does publish or share detailed impairment
statistics, they would be well advised to avoid identifying statistics, they would be well advised to avoid identifying
individual hosts or users. individual hosts or users.
Finally, if a domain chooses to contact end userd directly concerning Finally, if a domain chooses to contact end userd directly concerning
their IPv6 impairments, that domain should ensure that such their IPv6 impairments, that domain should ensure that such
communication is permissable under any applicable privacy policies of communication is permissible under any applicable privacy policies of
the domain or its websites. the domain or its websites.
6.3. Considerations with Poor IPv4 and Good IPv6 Transport 6.3. Considerations with Poor IPv4 and Good IPv6 Transport
There are situations where the differing quality of the IPv4 and IPv6 There are situations where the differing quality of the IPv4 and IPv6
connectivity of an end user could cause complications in accessing connectivity of an end user could cause complications in accessing
content when a domain is using an IPv6 migration tactic. While today content when a domain is using an IPv6 migration tactic. While today
most end users' IPv4 connectivity is typically superior to IPv6 most end users' IPv4 connectivity is typically superior to IPv6
connectivity (if such connectivity exists at all), there could be connectivity (if such connectivity exists at all), there could be
implications when the reverse is true and and end user has markedly implications when the reverse is true and and end user has markedly
skipping to change at page 28, line 21 skipping to change at page 28, line 24
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>. <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[World IPv6 Launch] [World IPv6 Launch]
The Internet Society, "World IPv6 Launch Website", 2012, The Internet Society, "World IPv6 Launch Website", 2012,
<http://www.worldipv6launch.org/>. <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]
-10: Minor update to one sentence to resolve a question from IETF
Last Call
-09: Minor updates to resolve questions in IETF Last Call -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
 End of changes. 6 change blocks. 
15 lines changed or deleted 20 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/