draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational February 23, 2012 Intended status: Informational February 27, 2012
Expires: August 26, 2012 Expires: August 30, 2012
Considerations for Transitioning Content to IPv6 Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11
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 26, 2012. This Internet-Draft will expire on August 30, 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 14 skipping to change at page 21, line 14
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 or a non-existence response,
these resource records must be signed, as well as any accompanying both types of response will be signed and will validate. In
NextSECure (NSEC) information that proves existence and/or not- practical terms this means that two separate views or zones are used,
existence of AAAA resource records. In practical terms this means each of which is signed, so that whether or not particular resource
that two separate views or zones are used, each of which is signed, records exist, the existence or non-existence of the record can still
so that whether or not particular resource records exist, the be validated using DNSSEC. As a result, there should not be any
existence or non-existence of the record can still be validated using negative impact on DNSSEC for those domains that have implemented
DNSSEC. As a result, there should not be any negative impact on both DNSSEC on their Security-Aware Authoritative Name Servers and
DNSSEC for those domains that have implemented both DNSSEC on their also implemented DNS Resolver Whitelisting. As for any party
Security-Aware Authoritative Name Servers and also implemented DNS implementing DNSSEC of course, such domains should ensure that
Resolver Whitelisting. As for any party implementing DNSSEC of resource records are being appropriately and reliably signed and
course, such domains should ensure that resource records are being consistent with the response being returned.
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 28, line 24 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]
-11: Minor update to one item to resolve a question from IETF Last
Call (same one as -09 and -10)
-10: Minor update to one sentence to resolve a question from IETF -10: Minor update to one sentence to resolve a question from IETF
Last Call 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.
 End of changes. 5 change blocks. 
17 lines changed or deleted 19 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/