BEHAVE Working Group D. Wing
Internet-Draft Cisco
Intended status: Standards Track X. Wang
Expires: January 14, 2010 X. Xu
Huawei
July 13, 2009
Learning the IPv6 Prefixes of an IPv6/IPv4 Translator
draft-wing-behave-learn-prefix-03
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 January 14, 2010.
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
Some IPv6 applications obtain IPv4 address literals and want to
Wing, et al. Expires January 14, 2010 [Page 1]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
communicate with those IPv4 hosts through an IPv6/IPv4 translator.
The IPv6 application can send an IPv6 packet through the translator
if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many
IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed;
rather, the prefix is chosen by the network operator. This
specification provides three methods for a host to learn the IPv6
prefix of its IPv6/IPv4 translator. Unicast, any-source multicast
(ASM), and source-specific multicast (SSM) are supported.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanisms to Learn the IPv6 Prefix and Length . . . . . . . . 4
3.1. Using DNS . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Using DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Using IPv6 Router Advertisements (RA) . . . . . . . . . . 6
4. Authenticating the Learned Prefix . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. For future study . . . . . . . . . . . . . . . . . . 11
A.1. multi-homed hosts . . . . . . . . . . . . . . . . . . . . 12
A.2. Unicast and multicast translators . . . . . . . . . . . . 12
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 12
B.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 12
B.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12
B.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Wing, et al. Expires January 14, 2010 [Page 2]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 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 record from an A record
(also called "DNS rewriting" or "DNS-ALG"), described in
[I-D.bagnulo-behave-dns64].
LIR Prefix: A prefix assigned to an IPv6/IPv4 translator that uses
the same LIR (Local Internet Registry) prefix as assigned to the
network by that network's local Internet registry.
Edge router: The routers with some interfaces which attach to the
same multicast link with some hosts.
2. Introduction
Certain applications, operating in certain translation scenarios, can
benefit from knowing the IPv6 prefix of their IPv6/IPv4 translator.
First, the host must be operating in an IPv6-initiated scenario with
a local translator. The BEHAVE charter [Charter] describes these as
Scenario 1, "IPv6 network to IPv4 Internet", and Scenario 5, "An IPv6
network to an IPv4 network". Learning the prefix is useful for both
stateful translation and stateless translation.
With those scenarios, the IPv6 host usually performs a DNS AAAA query
which is processed by a DNS64 server. The DNS64 server generates a
synthetic AAAA response, when necessary. This synthetic AAAA
response contains the prefix of the IPv6/IPv4 translator. When the
IPv6 host sends a packet to that address returned in the AAAA
response, the packet is routed to the translator which translates it
to IPv4. This functionality is transparent to the IPv6 host, for the
most part.
Second, the IPv6 application obtains an IPv4 address literal via a
means outside of DNS, and wants to communicate with that IPv4
address. So far, the authors have identified the following
applications which can benefit knowing the IPv6 prefix of the host's
IPv6/IPv4 translator:
o host-based DNSSEC validation (Section 4.3 of
[I-D.bagnulo-behave-dns64])
Wing, et al. Expires January 14, 2010 [Page 3]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
o BitTorrent (Section 2.2 of [I-D.wing-behave-nat64-referrals])
o multicast translation ([I-D.venaas-behave-v4v6mc-framework] and
Section 4 of [I-D.venaas-behave-mcast46])
o URI schemes with host IPv4 address literals rather than domain
names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,
ipp://192.0.2.1)).
When an IPv6/IPv4 translator is used with an LIR prefix (rather than
the well-known prefix), it is necessary for such applications to
learn the IPv6 prefix (and length) of the translator so that the
application can create an IPv6 packet that will be routed to the
translator and be translated to IPv4.
3. Mechanisms to Learn the IPv6 Prefix and Length
Both the IPv6 prefix of the translator and the prefix length of the
translator need to be learned. With that information, the
application can generate an appropriate IPv6 address that will be
routed to the translator for the translator to process.
The host can learn the necessary information using DNS, DHCP, or
Router Alert, as described in the following sections.
Issue: If a conflict exists between DNS, DHCP, or RA, which
should take precedence? Should we choose one mechanism??
3.1. Using DNS
This specification defines a new U-NAPTR [RFC4848] application to
discover the translator's IPv6 prefix and length. The input domain
name is the exact same as would be used for a reverse DNS lookup,
derived 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 an IPv6/IPv4 translator is present on the network, the successful
result of one of those queries will produce a NAPTR record with the
desired service tag "TRANSLATE64:" which contains the unicast IPv6
prefix and prefix length of the translator, separated by a "/" (the
same syntax as specified in Section 2.3 of [RFC4291]). The service
tags "ASMTRANSLATE64:" and "SSMTRANSLATE:" are used for ASM and SSM.
For example, a host with the IP address 2001:db8:1:2:3:4:567:89ab
would first send an NAPTR query for
Wing, et al. Expires January 14, 2010 [Page 4]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
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 translator. If the BEHAVE working
group decides that all translators 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
A new DHCP option, OPTION_AFT_PREFIX_DHCP, is defined. It contains
the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and
their lengths) for the IPv6/IPv4 translator on this network.
Wing, et al. Expires January 14, 2010 [Page 5]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 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_DHCP | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| u-prefix-len | asm-prefix-len| ssm-prefix-len| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: IPv6 unicast prefix :
: (up to 16 octets) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 ASM prefix :
: (up to 16 octets) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 SSM prefix :
: (up to 16 octets) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_AFT_PREFIX_DHCP (TBD)
option-length: (varies)
u-prefix-length: Length for the unicast prefix in bits
IPv6 unicast prefix: The translator's IPv6 unicast prefix
IPv6 ASM prefix: The translator's IPv6 ASM prefix. If
none is provided, the length is 0.
IPv6 SSM prefix: The translator's IPv6 SSM prefix. If
none is provided, the length is 0.
Figure 1: DHCP option OPTION_AFT_PREFIX_DHCP
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.3. Using IPv6 Router Advertisements (RA)
The IPv6 prefix and the prefix length can be advertised to IPv6 hosts
by routers in Router Advertisement (RA) messages [RFC4861].
Wing, et al. Expires January 14, 2010 [Page 6]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
+------+
|IPv6-A|
+------+
| ,--------.
+------+ +--------+ +--------+ | +----------+ ,' `.
|IPv6-B|--|router-B|--|router-A|-+-|translator|--( IPv4 Network )
+------+ +--------+ +--------+ +----------+ `. ,'
`--------'
<---------IPv6 network------------------>|<---- IPv4 network --->
Figure 2: using RA message to learn prefix and length
In the scenario where the IPv6 hosts attach to the same multicast
link as the translator (i.e., IPv6-A in Figure 2), the translator can
transmit the IPv6 prefix and the length to IPv6 hosts in the RA
messages advertised periodically or in the responses to valid Router
Solicitation messages.
In the scenarios where IPv6 hosts are attached to a different
multicast link than the translator (i.e., IPv6-B in Figure 2), the
IPv6 prefix and the prefix length could be manually configured for
edge routers in the IPv6 domain such as router-B. Either the
translator can use the IGP (Interior Gateway Protocol, e.g., OSPF,
ISIS, RIP) to announce the IPv6 prefix and the prefix length to edge
routers in the IPv6 domain. Thus edge routers can transfer the IPv6
prefix and the length to IPv6 hosts in the RA messages advertised
periodically or in the responses to valid Router Solicitation
messages.
This mechanism requires extensions to both the RA message of Neighbor
Discovery protocol [RFC4861] and IGP allowing the IPv6 prefix and
prefix length to be communicated to IPv6 hosts or routers.
In the extension of RA messages, a new option type,
OPTION_AFT_PREFIX_RA, is defined. It contains the IPv6 prefix and
its length.
Wing, et al. Expires January 14, 2010 [Page 7]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBD) | Length | unicast Prefix-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASM prefix length | SSM prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: unicast IPv6 prefix (variable) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ASM IPv6 prefix (variable) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: SSM IPv6 prefix (variable) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RA option OPTION_AFT_PREFIX_RA
The definition of each field is similar to OPTION_AFT_PREFIX_DHCP of
Section 3.2.
Extending OSPF requires defining a new TLV type, TLV_AFT_PREFIX, of
Router Information LSA (Link State Advertisement) to transfer the
IPv6 prefix and the prefix length. The format of TLV_AFT_PREFIX is
the same as OPTION_AFT_PREFIX_DHCP of Section 3.2.
Extending other IGPs (e.g., ISIS, RIP) will be discussed in a future
version of this document.
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 translator's IPv6 prefix learned via one of
the mechanisms described earlier. To allow such authentication the
operator of the translator first creates a PTR record for the
translator (with 0's for the elements after the translator'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
Wing, et al. Expires January 14, 2010 [Page 8]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
translator's IPv6 prefix by performing the following steps:
a. The host sends a DNS PTR query for the IPv6 address of the
translator (for "ipv6.arpa"), using 0 for the elements after the
prefix length. This will return the fully-qualified hostname of
that translator device.
b. Verify the full-qualified hostname is on the host's configured
list of authorized translators (e.g.,
seattle.translator.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 translator'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.translator.example.net. The
host verifies that seattle.translator.example.net is on its
configured list of authorized translators, as maintained in a text
file. The host sends an AAAA query for
seattle.translator.example.net and verifies the AAAA response
contains the same IPv6 address. The host then validates the DNSSEC
signature for seattle.translator.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, DHCPv6 or RA message, as described in
Section 4.
6. IANA Considerations
A new DHCPv6 option, OPTION_AFT_PREFIX_DHCP, and RA option,
Wing, et al. Expires January 14, 2010 [Page 9]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
OPTION_AFT_PREFIX_RA, needs to be assigned by IANA.
A new TLV type, TLV_AFT_PREFIX, of Router Information LSA for OSPF
needs to be assigned by IANA.
The new NAPTR Application Service tag "TRANSLATE64" is registered
with IANA.
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. Thanks to Keith
Moore and Scott Brim for suggesting HTTP IPv4 address literals.
Thanks to Stig Venaas for help with multicast.
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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
8.2. Informative References
[Charter] IETF, "BEHAVE Charter", May 2009,
<http://www.ietf.org/html.charters/behave-charter.html>.
[I-D.bagnulo-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
M. Endo, "DNS64: DNS extensions for Network Address
Wing, et al. Expires January 14, 2010 [Page 10]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
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. and R. Bellis, "Location Information Server
(LIS) Discovery From Behind Residential Gateways",
draft-thomson-geopriv-res-gw-lis-discovery-01 (work in
progress), June 2009.
[I-D.van-beijnum-behave-ftp64]
Beijnum, I., "IPv6-to-IPv4 translation FTP
considerations", draft-van-beijnum-behave-ftp64-05 (work
in progress), July 2009.
[I-D.venaas-behave-mcast46]
Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
IPv4 - IPv6 multicast translator",
draft-venaas-behave-mcast46-01 (work in progress),
July 2009.
[I-D.venaas-behave-v4v6mc-framework]
Venaas, S., "Framework for IPv4/IPv6 Multicast
Translation", draft-venaas-behave-v4v6mc-framework-00
(work in progress), July 2009.
[I-D.wing-behave-nat64-referrals]
Wing, D., "Referrals Across a NAT64",
draft-wing-behave-nat64-referrals-00 (work in progress),
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
Wing, et al. Expires January 14, 2010 [Page 11]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
A.1. multi-homed hosts
A multi-homed host may have different translation devices available
on each of its networks, and can learn those via DNS, DHCP, or RA.
When using DNS to learn the translator's prefix (Section 3.1) or
using DNS to authenticate the translator 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].
A.2. Unicast and multicast translators
It may be necessary to use different prefixes for unicast, any source
multicast (ASM), and source-specific multicast (SSM) (Section 2 of
[I-D.venaas-behave-mcast46]).
Appendix B. Changes
B.1. Changes from -02 to -03
o Removed FTP interworking, because [I-D.van-beijnum-behave-ftp64]
proposes that FTP clients use the same IP address for the data
connection as the control connection. This eliminates the need
for the FTP client to learn the translator's prefix.
o Added multicast to DHCP and RA messages.
B.2. Changes from -01 to -02
o provided another method of using RA message for a host to learn
its translator's IPv6 prefix and length
o added IPv4 address literals in URIs and multicast as benefactors
for learning the translator's prefix.
o added FTP interworking using PASV
o clarified which Scenarios this applies to, and that this is for
stateful and stateless.
B.3. Changes from -00 to -01
o made clearer this is for NAT64 prefix (changed title and some
text).
Wing, et al. Expires January 14, 2010 [Page 12]
Internet-Draft Learning IPv6 Prefix of 6/4 Translator July 2009
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.
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Xuewei Wang
Huawei Technologies Co.,Ltd
No.9 Xinxi Rd.
Beijing, Hai-Dian District 100085
P.R. China
Email: wangxuewei@huawei.com
Xiaohu Xu
Huawei Technologies Co.,Ltd
No.9 Xinxi Rd.
Beijing, Hai-Dian District 100085
P.R. China
Email: xuxh@huawei.com
Wing, et al. Expires January 14, 2010 [Page 13]