< draft-ietf-dnsop-as112-dname-01.txt   draft-ietf-dnsop-as112-dname-02.txt >
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-Draft Dyn, Inc. Internet-Draft Dyn, Inc.
Updates: 6304 (if approved) B. Dickson Updates: 6304 (if approved) B. Dickson
Intended status: Informational Verisign Labs Intended status: Informational Verisign Labs
Expires: August 18, 2014 W. Kumari Expires: August 18, 2014 W. Kumari
Google Google
G. Michaelson G. Michaelson
APNIC APNIC
February 14, 2014 February 14, 2014
AS112 Redirection using DNAME AS112 Redirection using DNAME
draft-ietf-dnsop-as112-dname-01 draft-ietf-dnsop-as112-dname-02
Abstract Abstract
Many sites connected to the Internet make use of IPv4 addresses that Many sites connected to the Internet make use of IPv4 addresses that
are not globally unique. Examples are the addresses designated in are not globally unique. Examples are the addresses designated in
RFC 1918 for private use within individual sites. RFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain Name Devices in such environments may occasionally originate Domain Name
System (DNS) queries (so-called "reverse lookups") corresponding to System (DNS) queries (so-called "reverse lookups") corresponding to
those private-use addresses. Since the addresses concerned have only those private-use addresses. Since the addresses concerned have only
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3. AS112 Operations . . . . . . . . . . . . . . . . . . . . . . . 6 3. AS112 Operations . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Extensions to Support DNAME Redirection . . . . . . . . . 6 3.1. Extensions to Support DNAME Redirection . . . . . . . . . 6
3.2. Redirection of Query Traffic to AS112 Servers . . . . . . 6 3.2. Redirection of Query Traffic to AS112 Servers . . . . . . 6
4. Continuity of AS112 Operations . . . . . . . . . . . . . . . . 8 4. Continuity of AS112 Operations . . . . . . . . . . . . . . . . 8
5. Candidate Zones for AS112 Redirection . . . . . . . . . . . . 9 5. Candidate Zones for AS112 Redirection . . . . . . . . . . . . 9
6. DNAME Deployment Considerations . . . . . . . . . . . . . . . 10 6. DNAME Deployment Considerations . . . . . . . . . . . . . . . 10
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 11 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Address Assignment . . . . . . . . . . . . . . . . . . . . 12 8.1. Address Assignment . . . . . . . . . . . . . . . . . . . . 12
8.2. Hosting of AS112.ARPA . . . . . . . . . . . . . . . . . . 12 8.2. Hosting of AS112.ARPA . . . . . . . . . . . . . . . . . . 13
8.3. Delegation of AS112.ARPA . . . . . . . . . . . . . . . . . 13 8.3. Delegation of AS112.ARPA . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Assessing Support for DNAME in the Real World . . . . 17 Appendix A. Assessing Support for DNAME in the Real World . . . . 19
A.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Editorial Notes . . . . . . . . . . . . . . . . . . . 20 Appendix B. Editorial Notes . . . . . . . . . . . . . . . . . . . 22
B.1. Change History . . . . . . . . . . . . . . . . . . . . . . 20 B.1. Change History . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The AS112 project is described in detail in [RFC6304]. The AS112 project is described in detail in [RFC6304].
The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG and The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG and
BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each
and every zone that is delegated to them. and every zone that is delegated to them.
If a zone is delegated to AS112 nameservers without those nameservers If a zone is delegated to AS112 nameservers without those nameservers
skipping to change at page 12, line 9 skipping to change at page 12, line 9
of AS112.ARPA as described in Section 8 is required. of AS112.ARPA as described in Section 8 is required.
Once IAB approval has been obtained, this section may be removed Once IAB approval has been obtained, this section may be removed
prior to publication or updated to include text that confirms the prior to publication or updated to include text that confirms the
IAB's decision, at the IAB's discretion. IAB's decision, at the IAB's discretion.
8. IANA Considerations 8. IANA Considerations
8.1. Address Assignment 8.1. Address Assignment
The IANA is requested to assign one IPv4 /24 netblock and one IPv6 The IANA is requested to assign one IPv4 /24 netblock and register
/48 netblock that, to the best of their knowledge, should be suitable its use in the IPv4 Special-Purpose Address Registry [RFC6890] as
for announcement as a single IPv4 /24 prefix and a single IPv6 prefix follows:
on the global Internet, respectively.
+----------------------+--------------------------------+
| Name | Value |
+----------------------+--------------------------------+
| Address Block | As determined by IANA |
| | |
| Name | AS112-v4 |
| | |
| RFC | This document (when published) |
| | |
| Allocation Date | As determined by IANA |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+--------------------------------+
We suggest that IANA assign 192.31.196.0/24 from the IPv4 Recovered
Address Space Registry, but any /24 which has been unassigned and
unadvertised for at least twelve months is acceptable.
The IANA is requested to assign one IPv6 /48 netblock and register
its use in the IPv6 Special-Purpose Address Registry [RFC6890] as
follows:
+----------------------+--------------------------------+
| Name | Value |
+----------------------+--------------------------------+
| Address Block | As determined by IANA |
| | |
| Name | AS112-v6 |
| | |
| RFC | This document (when published) |
| | |
| Allocation Date | As determined by IANA |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+--------------------------------+
We suggest that IANA assign 2001:112::/48 from the IETF Protocol
Assignments allocation [RFC2928], but /48 which has been unassigned
and unadvertised for at least twelve months is acceptable.
Once assigned, all occurrences of TBAv4 in this document should be Once assigned, all occurrences of TBAv4 in this document should be
replaced by the IPv4 netblock assigned, in conventional notation. replaced by the IPv4 netblock assigned, in conventional notation.
Occurrences of TBAv4-1 should be replaced with an address from the Occurrences of TBAv4-1 should be replaced with an address from the
netblock with lowest octet set to 1. Similarly, all occurrences of netblock with lowest octet set to 1. Similarly, all occurrences of
TBAv6 in this document should be replaced by the IPv6 netblock TBAv6 in this document should be replaced by the IPv6 netblock
assigned, in conventional notation, and TBAv6-1 replaced with an assigned, in conventional notation, and TBAv6-1 replaced with an
address from that netblock with the lowest 48 bits set to the value address from that netblock with the lowest 48 bits set to the value
1. Once those changes are made, this paragraph may be removed prior 1. Once those changes are made, this paragraph may be removed prior
to publication. to publication.
skipping to change at page 16, line 32 skipping to change at page 17, line 32
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012. DNS", RFC 6672, June 2012.
11.2. Informative References 11.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial
IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.
[RFC3172] Huston, G., "Management Guidelines & Operational [RFC3172] Huston, G., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, September 2001. Domain ("arpa")", BCP 52, RFC 3172, September 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010. Reserved for Documentation", RFC 5737, January 2010.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, July 2011. RFC 6303, July 2011.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, April 2013.
Appendix A. Assessing Support for DNAME in the Real World Appendix A. Assessing Support for DNAME in the Real World
To measure the extent to which the DNAME construct is supported in To measure the extent to which the DNAME construct is supported in
the Internet, we have used an experimental technique to test the DNS the Internet, we have used an experimental technique to test the DNS
resolvers used by end hosts, and derive from the test a measurement resolvers used by end hosts, and derive from the test a measurement
of DNAME support within the Internet. of DNAME support within the Internet.
A.1. Methodology A.1. Methodology
The test was conducted by loading a user's browser with 4 URLs to The test was conducted by loading a user's browser with 4 URLs to
skipping to change at page 21, line 5 skipping to change at page 22, line 26
changed to informational. Appendix on DNAME testing added, changed to informational. Appendix on DNAME testing added,
describing an experiment conducted by Geoff Huston and George describing an experiment conducted by Geoff Huston and George
Michaelson. Michaelson.
00 Adopted by dnsop in IETF88, Vancouver; resubmitted as 00 Adopted by dnsop in IETF88, Vancouver; resubmitted as
draft-ietf-dnsop-as112-dname. Changed contact info for Brian. draft-ietf-dnsop-as112-dname. Changed contact info for Brian.
01 Minor updates following submission of 01 Minor updates following submission of
[I-D.jabley-dnsop-rfc6304bis]. [I-D.jabley-dnsop-rfc6304bis].
02 Text in IANA Considerations section dealing with address
assignments modified following informal advice received from Leo
Vegoda.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Dyn, Inc. Dyn, Inc.
470 Moore Street 470 Moore Street
London, ON N6C 2C2 London, ON N6C 2C2
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@dyn.com Email: jabley@dyn.com
 End of changes. 6 change blocks. 
18 lines changed or deleted 88 lines changed or added

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