BEHAVE Working Group D. Wing
Internet-Draft Cisco
Intended status: Standards Track March 9, 2009
Expires: September 10, 2009
Learning the IPv6 Prefix of a NAT64
draft-wing-behave-learn-prefix-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
In some IPv6/IPv4 translation scenarios it is necessary for an IPv6
host to know the IPv6 prefix used by its NAT64. In some of the IPv6/
IPv4 translation proposals, the prefix is not fixed; that is, the
Wing Expires September 10, 2009 [Page 1]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
prefix is chosen by the network operator. This specification
provides two methods for a host learn its NAT64's IPv6 prefix and
length.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Learning IPv6 Prefix and Length . . . . . . . . . . . . . . . . 3
3.1. Using DNS to Learn IPv6 Prefix and Length . . . . . . . . . 3
3.2. Using DHCP to Learn IPv6 Prefix and Length . . . . . . . . 4
4. Authenticating the Learned Prefix . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. For future study . . . . . . . . . . . . . . . . . . . 8
A.1. multi-homed hosts . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 8
B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Wing Expires September 10, 2009 [Page 2]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
AFT: Address Family Translator. A device that translates between IP
address families.
DNS64: The function of synthesizing an AAAA response from an A
record.
2. Introduction
Several variations of Address Family Translators (AFT) have been
proposed for IPv6/IPv6 coexistence. For IPv6 hosts to access IPv4
hosts, a DNS function exists which synthesizes DNS AAAA records --
this function generally called "DNS64" (also "DNS rewriting")
[I-D.bagnulo-behave-dns64]. The DNS64 function, when used in
conjunction with an NAT64, allows a IPv6-only host to access IPv4-
only hosts. This access, for the most part, is transparent to the
IPv6 host -- to much the same degree that today's widely-deployed
NATs are transparent to IPv4 hosts. But, like with today's NATs,
there are applications which do not work with NAT64 or do not work
with DNS64, and require IPv6 hosts to implement additional
functionality.
So far, two applications have been identified which can benefit from
knowing the IPv6 prefix of the host's NAT64:
o host-based DNSSEC validation (as described in Section 4.3 of
[I-D.bagnulo-behave-dns64])
o BitTorrent (Section 2.2 of [I-D.wing-behave-nat64-referrals])
3. Learning IPv6 Prefix and Length
Both the IPv6 prefix and the prefix length need to be learned This
can be done using DNS or DHCP, as described in the following
sections.
3.1. Using DNS to Learn IPv6 Prefix and Length
This specification defines a new U-NAPTR [RFC4848] application to
discover the NAT64's IPv6 prefix and length. The input domain name
is the exact same as would be used for a reverse DNS lookup, derived
Wing Expires September 10, 2009 [Page 3]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
from the host's IPv6 in the ".ip6.arpa." tree and follows the
construction rules in Section 2.5 of [RFC3596]. This is shortened to
20 labels (representing a /64 network prefix) and, if DNS returns an
error is shortened to 16 labels (representing a /48 network prefix).
If a NAT64 is present on the network, the successful result of one of
those queries will produce a NAPTR record with the desired service
tag "NAT64:" which contains the IPv6 prefix and prefix length o the
NAT64, separated by a "/" (the same syntax as specified in Section
2.3 of [RFC4291]).
For example, a host with the IP address 2001:db8:1:2:3:4:567:89ab
would first send an NAPTR query for
3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (20 elements,
representing a /64 network prefix). If that fails (returns
NXDOMAIN), it would send an NAPTR query for
2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA (16 elements, representing a
/48 network prefix).
Note: Both /64 and /48 prefix lengths are shown in this version
of the document for illustrative purposes. The number of elements
of this query will depend on the prefix length(s) defined by the
BEHAVE working group for a NAT64. If the BEHAVE working group
decides that all NAT64's will have a certain prefix length, then
only one DNS query is sent.
If the host needs to authenticate the prefix it just learned (e.g.,
because the host is running a DNSSEC validator) the host performs the
additional authentication steps described in Section 4.
3.2. Using DHCP to Learn IPv6 Prefix and Length
A new DHCP option, OPTION_AFT_PREFIX, is defined. It contains the
IPv6 prefix and its length.
Wing Expires September 10, 2009 [Page 4]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AFT_PREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6 prefix |
| (up to 16 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
option-code: OPTION_AFT_PREFIX (TBD)
option-length: 17
prefix-length: Length for this prefix in bits
IPv6-prefix: An IPv6 prefix
Figure 1: DHCP option OPTION_AFT_PREFIX
In order to conserve space, it is RECOMMENDED that only the
significant bits of the IPv6 prefix be sent in the DHCP option.
If the host needs to authenticate the prefix it just learned (e.g.,
because the host is running a DNSSEC validator) the host performs the
additional authentication steps described in Section 4.
4. Authenticating the Learned Prefix
In some cases (e.g., a host performing DNSSEC validation), the host
needs to authenticate the NAT64's IPv6 prefix learned via one of the
mechanisms described earlier. To allow such authentication the
operator of the NAT64 first creates a PTR record for the NAT64 (with
0's for the elements after the NAT64's IPv6 prefix) which points to a
hostname. The hostname has a signed AAAA record for the same
0-padded IPv6 address returned by the PTR query. Once those
configuration steps are done, a host can validate the NAT64 IPv6
prefix by performing the following steps:
Wing Expires September 10, 2009 [Page 5]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
a. The host sends a DNS PTR query for the IPv6 address of the NAT64
(for "ipv6.arpa"), using 0 for the elements after the prefix
length. This will return the fully-qualified hostname of that
NAT64 device.
b. Verify the full-qualified hostname is on the host's configured
list of authorized translators (e.g., seattle.nat64.example.net).
c. Send a DNS AAAA query for that hostname.
d. Verify the AAAA response matches the IPv6 address obtained in
step 1.
e. Perform DNSSEC validation of the AAAA response.
For example, if the NAT64's IPv6 prefix length is /48, the host would
send a PTR query for 2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA which
would return a hostname, seattle.nat64.example.net. The host
verifies that seattle.nat64.example.net is on its configured list of
authorized NAT64 hosts, as maintained in a text file. The host sends
an AAAA query for seattle.nat64.example.net and verifies the AAAA
response contains the same IPv6 address. The host then validates the
DNSSEC signature for seattle.nat64.example.net.
5. Security Considerations
After learning the IPv6 prefix of its translator by following the
procedures in this specification, the IPv6 host will utilize this
information for subsequent actions (e.g., sending a packet to it, or
using that information to synthesize DNS records or to perform DNSSEC
validation). If an attacker provides a fraudulent IPv6 to the IPv6
host, the attacker can become on-path for traffic to/from that IPv6
host and preform passive or active eavesdropping or traffic analysis.
To protect against this attack, it is RECOMMENDED that IPv6 hosts be
configured with the names of authorized translators and RECOMMENDED
that IPv6 hosts uses DNSSEC to validate that name matches the IPv6
prefix learned via DNS or DHCPv6, as described in Section 4.
6. IANA Considerations
A new DHCPv6 option, OPTION_AFT_PREFIX, needs to be assigned by IANA.
The new NAPTR Application Service tag "NAT64" is registered with
IANA.
Wing Expires September 10, 2009 [Page 6]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
7. Acknowledgements
This draft was fostered by discussion on the 46translation mailing
list and at the v4v6 Interim in Montreal. Special thanks to Iljitsch
van Beijnum, Andrew Sullivan, Marcelo Bagnulo Braun, Fred Baker, and
Xing Li for their comments and dialog.
The mechanism to perform a shortened NAPTR query was described first
by Martin Thomson [I-D.thomson-geopriv-res-gw-lis-discovery].
Thanks to Ralph Droms for his help with DHCPv6. Thanks to John
Schnizlein for improving the DNS learning algorithm.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
8.2. Informative References
[I-D.bagnulo-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
M. Endo, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers",
draft-bagnulo-behave-dns64-02 (work in progress),
March 2009.
[I-D.savolainen-mif-dns-server-selection]
Savolainen, T., "DNS Server Selection on Multi-Homed
Hosts", draft-savolainen-mif-dns-server-selection-00 (work
in progress), February 2009.
[I-D.thomson-geopriv-res-gw-lis-discovery]
Thomson, M., "Location Information Server (LIS) Discovery
From Behind Residential Gateways",
draft-thomson-geopriv-res-gw-lis-discovery-00 (work in
progress), February 2009.
[I-D.wing-behave-nat64-referrals]
Wing, D., "Referrals Across a NAT64",
draft-wing-behave-nat64-referrals-00 (work in progress),
Wing Expires September 10, 2009 [Page 7]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
March 2009.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Appendix A. For future study
A.1. multi-homed hosts
A multi-homed host may have different NAT64 devices available on each
of its networks, and can learn those via DNS or via DHCP.
When using DNS to learn the NAT64 prefix (Section 3.1) or using DNS
to authenticate the NAT64 prefix (Section 4, it is possible a split
horizon DNS exists. Such a split DNS requires the host to query the
DNS server associated with that network prefix as described in
[I-D.savolainen-mif-dns-server-selection].
Appendix B. Changes
B.1. Changes from -00 to -01
o made clearer this is for NAT64 prefix (changed title and some
text).
o changed from querying for "_aft_prefix" TXT record to querying
ipv6.arpa NAPTR record.
o BitTorrent is another application that benefits from knowing the
NAT64 prefix; previously only DNSSEC was listed.
o changed to standards track.
Wing Expires September 10, 2009 [Page 8]
Internet-Draft Learning NAT64's IPv6 Prefix March 2009
Author's Address
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Wing Expires September 10, 2009 [Page 9]