< draft-ietf-behave-nat64-discovery-heuristic-10.txt   draft-ietf-behave-nat64-discovery-heuristic-11.txt >
Behave WG T. Savolainen Behave WG T. Savolainen
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track J. Korhonen Intended status: Standards Track J. Korhonen
Expires: December 31, 2012 Nokia Siemens Networks Expires: January 31, 2013 Nokia Siemens Networks
D. Wing D. Wing
Cisco Systems Cisco Systems
June 29, 2012 July 30, 2012
Discovery of IPv6 Prefix Used for IPv6 Address Synthesis Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
draft-ietf-behave-nat64-discovery-heuristic-10.txt draft-ietf-behave-nat64-discovery-heuristic-11.txt
Abstract Abstract
This document describes a method for detecting the presence of DNS64 This document describes a method for detecting the presence of DNS64
and for learning the IPv6 prefix used for protocol translation on an and for learning the IPv6 prefix used for protocol translation on an
access network. The method depends on the existence of a well-known access network. The method depends on the existence of a well-known
IPv4-only domain name "ipv4only.arpa". The information learned IPv4-only domain name "ipv4only.arpa". The information learned
enables nodes to perform local IPv6 address synthesis and to enables nodes to perform local IPv6 address synthesis and to
potentially avoid NAT64 on dual-stack and multi-interface potentially avoid NAT64 on dual-stack and multi-interface
deployments. deployments.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 31, 2012. This Internet-Draft will expire on January 31, 2013.
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 2, line 36 skipping to change at page 2, line 36
5. Operational Considerations for DNS64 Operator . . . . . . . . 12 5. Operational Considerations for DNS64 Operator . . . . . . . . 12
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 12 5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes . . . . . 12
6. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Example of DNS Record Configuration . . . . . . . . . 16 Appendix A. Example of DNS Record Configuration . . . . . . . . . 16
Appendix B. About the IPv4 Address for the Well-Known Name . . . 18 Appendix B. About the IPv4 Address for the Well-Known Name . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 As part of the transition to IPv6, NAT64 [RFC6146] and DNS64
[RFC6147] technologies will be utilized by some access networks to [RFC6147] technologies will be utilized by some access networks to
provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64 provide IPv4 connectivity for IPv6-only nodes [RFC6144]. DNS64
utilizes IPv6 address synthesis to create local IPv6 addresses for utilizes IPv6 address synthesis to create local IPv6 addresses for
peers having only IPv4 addresses, hence allowing DNS-using IPv6-only peers having only IPv4 addresses, hence allowing DNS-using IPv6-only
nodes to communicate with IPv4-only peers. nodes to communicate with IPv4-only peers.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
location defined by RFC6052, the response will not disturb Pref64::/n location defined by RFC6052, the response will not disturb Pref64::/n
learning procedure. learning procedure.
A node MUST look through all of the received AAAA resource records to A node MUST look through all of the received AAAA resource records to
collect one or more Pref64::/n. The Pref64::/n list might include collect one or more Pref64::/n. The Pref64::/n list might include
the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network- the Well-Known Prefix 64:ff9b::/96 [RFC6052] or one or more Network-
Specific Prefixes. In the case of NSPs, the node SHALL determine the Specific Prefixes. In the case of NSPs, the node SHALL determine the
used address format by searching the received IPv6 addresses for the used address format by searching the received IPv6 addresses for the
WKN's well-known IPv4 addresses. The node SHALL assume the well- WKN's well-known IPv4 addresses. The node SHALL assume the well-
known IPv4 addresses might be found at the locations specified by known IPv4 addresses might be found at the locations specified by
RFC6052 section 2.2. If the well-known IPv4 addresses are not found RFC6052 section 2.2. The node MUST check on octet boundaries to
within the standard locations, it indicates that the network is not ensure a 32-bit well-known IPv4 address value is present only once in
using standard address format and the Pref64::/n cannot be an IPv6 address. In case another instance of the value is found
determined. Developers can over time learn of IPv6 translated inside the IPv6 address, the node SHALL repeat the search with the
address formats that are extensions or alternatives to the standard other well-known IPv4 address.
formats. Developers MAY at that point add additional steps to the
described discovery procedure. The additional steps are outside the
scope of the present document.
In case a node does not receive positive DNS reply to AAAA resource
record query, the node MAY perform DNS A resource record query for
the well-known name. If the node receives positive reply to the DNS
A resource record query it means the used recursive DNS server is not
DNS64 server.
The node MUST ensure a 32-bit well-known IPv4 address value is
present only once in an IPv6 address. In case another instance of
the value is found inside the IPv6 address, the node SHALL repeat the
search with the other well-known IPv4 address.
If only one Pref64::/n was present in the DNS response: a node SHALL If only one Pref64::/n was present in the DNS response: a node SHALL
use that Pref64::/n for both local synthesis and for detecting use that Pref64::/n for both local synthesis and for detecting
synthesis done by the DNS64 server on the network. synthesis done by the DNS64 server on the network.
If more than one Pref64::/n was present in the DNS response: a node If more than one Pref64::/n was present in the DNS response: a node
SHOULD use all of them when determining whether other received IPv6 SHOULD use all of them when determining whether other received IPv6
addresses are synthetic. The node MUST use all learned Pref64::/n addresses are synthetic. The node MUST use all learned Pref64::/n
when performing local IPv6 address synthesis, and use the prefixes in when performing local IPv6 address synthesis, and use the prefixes in
the order received from DNS64 server. That is, when the node is the order received from DNS64 server. That is, when the node is
providing a list of locally synthesized IPv6 addresses to upper providing a list of locally synthesized IPv6 addresses to upper
layers, IPv6 addresses MUST be synthesized by using all discovered layers, IPv6 addresses MUST be synthesized by using all discovered
Pref64::/n in the received order. Pref64::/n in the received order.
If the well-known IPv4 addresses are not found within the standard
locations, it indicates that the network is not using standard
address format and the Pref64::/n cannot be determined. Developers
can over time learn of IPv6 translated address formats that are
extensions or alternatives to the standard formats. Developers MAY
at that point add additional steps to the described discovery
procedure. The additional steps are outside the scope of the present
document.
In case a node does not receive positive DNS reply to AAAA resource
record query, the node MAY perform DNS A resource record query for
the well-known name. If the node receives positive reply to the DNS
A resource record query it means the used recursive DNS server is not
DNS64 server.
In the case of a negative response (NXDOMAIN, NXRRSET) or a DNS query In the case of a negative response (NXDOMAIN, NXRRSET) or a DNS query
timeout: a DNS64 server is not available on the access network, the timeout: a DNS64 server is not available on the access network, the
access network filtered out the well-known query, or something went access network filtered out the well-known query, or something went
wrong in the DNS resolution. All unsuccessful cases result in a node wrong in the DNS resolution. All unsuccessful cases result in a node
being unable to perform local IPv6 address synthesis. In the case of being unable to perform local IPv6 address synthesis. In the case of
timeout, the node SHOULD retransmit the DNS query like any other DNS timeout, the node SHOULD retransmit the DNS query like any other DNS
query the node makes [RFC1035]. In the case of a negative response query the node makes [RFC1035]. In the case of a negative response
(NXDOMAIN, NXRRSET), the node MUST obey the Time-To-Live [RFC1035] of (NXDOMAIN, NXRRSET), the node MUST obey the Time-To-Live [RFC1035] of
the response before resending the AAAA resource record query. The the response before resending the AAAA resource record query. The
node MAY monitor for DNS replies with IPv6 addresses constructed from node MAY monitor for DNS replies with IPv6 addresses constructed from
skipping to change at page 16, line 35 skipping to change at page 16, line 35
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, Provisioning Domains Problem Statement", RFC 6418,
November 2011. November 2011.
Appendix A. Example of DNS Record Configuration Appendix A. Example of DNS Record Configuration
The following BIND-style examples illustrate how A and AAAA records The following BIND-style examples illustrate how A and AAAA records
could be configured by a NAT64 operator. could be configured by a NAT64 operator.
The examples use Pref64::/n of 2001:db8::/96 and the example.com The examples use Pref64::/n of 2001:db8::/96, both WKAs, and the
domain. example.com domain.
The PTR record for reverse queries (Section 3.1.1 bullet 3): The PTR record for reverse queries (Section 3.1.1 bullet 3):
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA. $ORIGIN A.A.0.0.0.0.0.C\
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 12h 15m 3w 2h)
IN NS ns.example.com.
IN PTR nat64.example.com.
$ORIGIN B.A.0.0.0.0.0.C\
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. ( @ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 12h 15m 3w 2h) 2003080800 12h 15m 3w 2h)
IN NS ns.example.com. IN NS ns.example.com.
IN PTR nat64.example.com. IN PTR nat64.example.com.
If example.com does not use DNSSEC, the following configuration file If example.com does not use DNSSEC, the following configuration file
could be used. Please note tat nat64.example.com has both an AAAA could be used. Please note that nat64.example.com has both an AAAA
record with the Pref64::/n and an A record for the connectivity check record with the Pref64::/n and an A record for the connectivity check
(Section 3.1.1 bullet 2). (Section 3.1.1 bullet 2).
example.com. IN SOA ns.example.com. hostmaster.example.com. ( example.com. IN SOA ns.example.com. hostmaster.example.com. (
2002050501 ; serial 2002050501 ; serial
100 ; refresh (1 minute 40 seconds) 100 ; refresh (1 minute 40 seconds)
200 ; retry (3 minutes 20 seconds) 200 ; retry (3 minutes 20 seconds)
604800 ; expire (1 week) 604800 ; expire (1 week)
100 ; minimum (1 minute 40 seconds) 100 ; minimum (1 minute 40 seconds)
) )
example.com. IN NS ns.example.com. example.com. IN NS ns.example.com.
nat64.example.com. nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:0:0 IN AAAA 2001:db8:0:0:0:0:C000:00AA
nat64.example.com. IN AAAA 2001:db8:0:0:0:0:C000:00AB
IN A 192.0.2.1 IN A 192.0.2.1
If the example.com does use DNSSEC, the following configuration file To DNSSEC sign the records, the owner of the example.com zone would
could be used for A and AAAA records: have RRSIG records for both the AAAA and A records for
nat64.example.com. As a normal DNSSEC requirement, the zone and its
example.com. IN SOA ns.example.com. hostmaster.example.com. ( parent also need to be signed.
2002050501 ; serial
100 ; refresh (1 minute 40 seconds)
200 ; retry (3 minutes 20 seconds)
604800 ; expire (1 week)
100 ; minimum (1 minute 40 seconds)
)
example.com. IN RRSIG SOA 5 2 100 20090803071330 (
20090704071330 17000 example.com.
TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo
4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit
xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi
iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= )
example.com. IN NS ns.example.com.
example.com. IN RRSIG NS 5 2 100 20090803071330 (
20090704071330 17000 example.com.
Xuw7saDDi6+5Z7SmtC7FC2npPOiE8F9qMR87eA0egG0I
B+xFx7pIogoVIDpOd1h3jqYivhblpCoDSBQb2oMbVy3B
SX5cF0r7Iu/xKP8XrV4DjNiugpa+NnhEIaRqG5uoPFbX
4cYT51yNq70I5mJvvajJu7UjmdHl26ZlnK33xps= )
nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:0 nat64.example.com.
IN RRSIG SOA 5 2 100 20090803071330 (
20090704071330 17000 example.net.
TVgWsNQvsFmeNHAeccGi7+UI7KwcE9TXPuSvmV9yyJwo
4FvHkxVC1H+98EtrmbR4c/XcdUzdfgn+q+lBqNsnbAit
xFERwPxzxbX0+yeCdHbBjHe7OuOc2Gc+CH6SbT2lKwVi
iEx3ySqqNoVScoUyhRdnPV2A1LV0yd9GtG9mI4w= )
nat64.example.com.
IN A 192.0.2.1
Appendix B. About the IPv4 Address for the Well-Known Name Appendix B. About the IPv4 Address for the Well-Known Name
The IPv4 addresses for the well-known name cannot be non-global IPv4 The IPv4 addresses for the well-known name cannot be non-global IPv4
addresses as listed in the Section 3 of [RFC5735]. Otherwise DNS64 addresses as listed in the Section 3 of [RFC5735]. Otherwise DNS64
servers might not perform AAAA record synthesis when the well-known servers might not perform AAAA record synthesis when the well-known
prefix is used, as stated in Section 3.1 of [RFC6052]. However, the prefix is used, as stated in Section 3.1 of [RFC6052]. However, the
addresses do not have to be routable or allocated to any real node, addresses do not have to be routable or allocated to any real node,
as no communications will be initiated to these IPv4 address. as no communications will be initiated to these IPv4 address.
 End of changes. 12 change blocks. 
68 lines changed or deleted 45 lines changed or added

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