Network working group X. Xu
Internet Draft Huawei
Category: Standard Track C. Byrne
Expires: July 2010 T-Mobile USA
M. Boucadair
France Telecom
G.Chen
China Mobile
January 15, 2010
Hybrid Type Prefix for IPv4-Embedded IPv6 Addresses
draft-xu-behave-hybrid-type-prefix-00
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 July 15, 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).
Xu, et al. Expires July 15, 2010 [Page 1]
Internet-Draft Hybrid Type Prefix January 2010
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract
To build IPv4-Embedded IPv6 addresses for IPv4/IPv6 translation, the
Well-Known Prefix (WKP) and Network Specific Prefix (NSP)-based
address formats have been defined in [Address-Format]. However, both
of them have some limitations in several use cases. Hence, this
document aims at discussing the validity of the use cases and assess
the interest of the BEHAVE WG to meet the requirement of
unambiguously distinguishing IPv4-Embedded IPv6 addresses from
native IPv6 ones. Doing so would guide the address selection and
therefore allow avoiding crossing unnecessary or even useless
address family translators.
Conventions used in this document
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 RFC-2119 [RFC2119].
Table of Contents
1. Problem Statements...........................................3
1.1. Communications Involving Dual-Stack Hosts...............3
1.2. Load Balancing with WKP.................................4
2. Applicability Scope..........................................5
3. Hybrid Type Prefix...........................................5
4. Alternative Solutions........................................7
5. Security Considerations......................................7
6. IANA Considerations..........................................8
7. References...................................................8
7.1. Normative References....................................8
7.2. Informative References..................................8
Authors' Addresses..............................................9
Xu, et al. Expires July 15, 2010 [Page 2]
Internet-Draft Hybrid Type Prefix January 2010
1. Problem Statements
The Well-Known Prefix (WKP) and Network Specific Prefix (NSP) have
been defined in [Address-Format] to build IPv4-Embedded IPv6
addresses for IPv4/IPv6 translation purposes. However, some
limitations may be experienced when using these formats in some
network configuration scenarios as elaborated latter in this
document.
Without special mention, the NAT64 in the following description only
refers to stateful NAT64 [NAT64].
1.1. Communications Involving Dual-Stack Hosts
According to the rules defined in [RFC3484], native paths should be
preferred to paths involving address translation (including address
family translation). Particularly, in the context of IPv4-IPv6
interconnection, IPv4-Embedded IPv6 addresses should have a lower
priority than IPv4 addresses, otherwise IPv4-IPv6 translators may
not be off-loaded (The off-load is motivated by the need of
optimizing the resource of translators, especially stateful
translators) and even some communications may fail (e.g., when IP
addresses are enclosed in the application's payload and no specific
ALG is enabled in the IPv4-IPv6 translator). For this reason, means
to identify IPv4-Embedded IPv6 addresses may be required so as to
avoid crossing IPv4-IPv6 translators.
In some scenarios (e.g., the IPv6 host and the IPv4-IPv6 translator
are not located in the same administrative domain (e.g., AS)), the
NSP can not meet the above requirement of distinction between
synthesized and native IPv6 addresses because the NSP used by the
remote IPv4-IPv6 translator is not known to the IPv6 host.
Although the WKP allows for easy distinction between synthesized and
native IPv6 addresses, it does not meet all needs. For example, the
WKP is not suitable in the IPv6 Internet to an IPv4 networks
scenario because 1) the WKP can not be used to represent non-global
IPv4 addresses (e.g., the private addresses defined in [RFC1918]); 2)
even with global IPv4 addresses, the use of WKP will cause the
routing scalability issue on IPv6 routing systems due to importing
IPv4 routing table into IPv6 one. Hence the NSP is the only choice
for that scenario. Since it is difficult to distinguish IPv6
addresses synthesized with the NSP from native IPv6 addresses when
the translator and IPv6 host are not located in the same
administrative domain, it is possible that a suboptimal connectivity
will be chosen for communication involving dual-stack hosts. As
Xu, et al. Expires July 15, 2010 [Page 3]
Internet-Draft Hybrid Type Prefix January 2010
illustrated in Figure 1, H1 is a dual-stack host connected to a
dual-stack network, while H2 is an IPv4-only host connected to an
IPv4-only network. Assume H1 got the synthetic AAAA of H2 as a
return for its AAAA DNS query, H1 has no way of knowing the IPv6
address in the received AAAA response is not a real IPv6 address,
but a synthetic IPv6 address. H1 may therefore, be led to believe
that it has end-to-end IPv6 connectivity with H2. As a result, H1
may initiate IPv6 communication to H2 via the NAT64 device, even
using some IPv6-specific options (e.g., IPSec) that are not
supported by the NAT64 device.
+-----------------+
| |
+------------+ | IPv6 Internet | +-----+ +------------+
| Dual-stack +---+ +--+NAT64+--+ IPv4-only |
| | +-----------------+ +-----+ | |
| +----+ | | +----+ |
| | H1 | | +-----------------+ | | H2 | |
| +----+ +---+ +-----------+ +----+ |
+------------+ | IPv4 Internet | +------------+
| |
+-----------------+
Figure 1. Dual-stack Hosts Communicating to IPv4-only Hosts
Preventing dual-stack hosts from using DNS64 service [DNS64] is not
a feasible way to address the above issue since synthetic AAAA
records may be added to authoritative DNS servers.
Configuring NSPs in H1's address selection policy table and
assigning them a lower selection priority is also unpractical for
the above scenario.
1.2. Load Balancing with WKP
In the IPv6 network to IPv4 Internet scenario, assume multiple
stateful NAT64 devices are deployed at the border of the two address
realms for load-balancing [NAT-STANDBY] purpose. If the WKP is used,
they would have to synchronize their NAT states. Otherwise, internal
routing change will cause the interruption of the already
established sessions. Since it is unlikely that large networks will
be able to synchronize NAT state for tens to hundreds of millions of
users across thousands of kilometers, the network administrator
would have to use a unique NSP in each region to achieve proper
scale, redundancy, and fault isolation. As mentioned before, IPv6
addresses synthesized with NSP can not be easily distinguished from
regular IPv6 addresses, which can result in a non-optimal situation
Xu, et al. Expires July 15, 2010 [Page 4]
Internet-Draft Hybrid Type Prefix January 2010
where dual-stack hosts may initiate communications to IPv4 hosts
through address family translators, even though they have native
IPv4 connectivities with the destination hosts.
2. Applicability Scope
The proposed format is primary suitable for scenarios where the
IPv4-IPv6 interconnection service is not restricted to customers
attached to the same domain (e.g., AS) where the translator is
located.
Hybrid Type Prefix should be used only for IPv4-Converted IPv6
addresses [Address Format] but never for IPv4-Translatable IPv6 ones.
This document defines prefixes to solve the following issues:
- NAT64 optimization when dual-stack hosts are involved;
- NAT64 Load balancing with a WKP prefix.
This draft can be positioned as part of the further works required
for solving some of unaddressed issues (mainly address selection) as
analyzed in [64-Analysis].
3. Hybrid Type Prefix
To address the issues mentioned in Section 1, this document proposes
a new type of prefix (called Hybrid Type Prefix, HTP in short) used
for IPv6 address synthesis (i.e., used for building IPv4-Converted
IPv6 addresses). This specific prefix integrates the benefits from
both WKP and NSP.
+--------+----------------------------+
| 0064(2)| Network Specific Part(10) |
+--------+----------------------------+
Figure 2. Hybrid Type Prefix Format
As shown in Figure 2, the Hybrid Type Prefix is a special /96 prefix
which starts with a well-known two-octet value 0x0064 which is used
to identify synthetic IPv6 addresses. The remaining part (i.e.,
rightmost ten octets) of the prefix is network specific part which
should be allocated hierarchically in accordance with the current
IPv6 unicast address allocation scheme (e.g., The Hybrid Type Prefix
block will be allocated from IANA to RIRs, then from RIRs to LIRs,
finally from LIRs to subscribers). These Hybrid Type Prefixes are
topologically aggregatable in the IPv6 Internet and can be
Xu, et al. Expires July 15, 2010 [Page 5]
Internet-Draft Hybrid Type Prefix January 2010
aggregated into 64::/16 to utmost extent. The Hybrid Type Prefix can
replace the NSP defined in [Address-Format] when deployed in the use
case described in Section 2. The format of IPv4 Embedded IPv6
address which is synthesized with the Hybrid Type Prefix is shown in
Figure 3.
+--------+----------------------------+-----------+
| 0064(2)| Network Specific Part(10) | v4 addr(4)|
+--------+----------------------------+-----------+
Figure 3. Format of IPv4-Embeded IPv6 Address Synthesized with HTP
To facilitate the deployment of IPv6 network to the IPv4 Internet
scenario, a specific sub-block of prefixes which start with
64:FF9B::/80 is reserved from the Hybrid Type Prefix block. These
prefixes are called Well-Known Prefixes. As illustrated in Figure 4,
the rightmost two octets of the WKP are left for network
administrators to use. One possible usage of the WKP is to achieve
load-balancing on a set of NAT64 devices. For example,
64:FF9B:0:0:0:1::/96 is assigned to the first NAT64 device,
64:FF9B:0:0:0:2::/96 is assigned to the second NAT64 device, and so
on. For a single IPv6-only network, there could be up to 65536 NAT64
devices deployed for load-balancing purposes. Note that, as
specified in [Address-Format], 64:FF9B::/96 is reserved for hard-
coding into host stacks. In order to distinguish 64:FF9B::/96 from
other WKPs, here, 64:FF9B::/96 is called the strong WKP, while
others are called weak WKPs.
+-------------+----------------+------+
|0064:FF9B (4)| all zeros (6) | (2) |
+-------------+----------------+------+
Figure 4. Well-Known Prefix Format
The relationship among the Hybrid Type Prefix block, the WKP block
and the strong WKP is shown in Figure 5:
+-----------------------------------------+
| HTP Block 64::/16 |
| +----------------------------------+ |
| | WKP Block 64:FF9B::/80 | |
| | +-------------------------+ | |
| | | Strong WKP 64:FF9B::/96 | | |
| | +-------------------------+ | |
| +----------------------------------+ |
+-----------------------------------------+
Xu, et al. Expires July 15, 2010 [Page 6]
Internet-Draft Hybrid Type Prefix January 2010
Figure 5. Relationship between HTPs
As a counterpart, the cost of this solution is that it may require
an additional inter-domain advertisement to Hybrid Type Prefix.
However, since the Hybrid Type Prefixes are topologically
aggregatable, it will not cause the routing scalability issue in the
IPv6 routing system.
4. Alternative Solutions
As defined above, 64::/16 is used as the Hybrid Type Prefix block.
For the IPv4-only networks in the IPv6 internet to IPv4 networks
scenario, they need to apply a unique sub-prefix block from the
Hybrid Type Prefix block for address synthesis purposes. Once these
networks are upgraded to support IPv6, they should apply a new
regular IPv6 prefix block while releasing the already applied Hybrid
Type Prefix block. Before obtaining a Hybrid Type Prefix, the IPv4-
only networks can still use the NSP for address synthesis. Once the
issue mentioned in Section 1 needs to be solved, a Hybrid Type
Prefix would have to be applied from the LIRs to replace the NSP.
Hence, the use of Hybrid Type Prefix will not hinder the IPv6
deployment.
To avoid multiple address applications, one alternative solution is
proposed: Use a reserved value for some special bits of the
interface ID part to identify IPv4-Embedded IPv6 addresses. For
example, a special binary value of bit 64 to 66, which is not
conflicted with any allocated OUIs, is reserved for identifying
IPv4-embeded IPv6 address. Furthermore, different types of IPv4-
embeded IPv6 addresses can also be distinguished by the remaining
bits for that octet (e.g., bit 67 to 71). This alternative was
initially discussed in http://www.ietf.org/mail-
archive/web/behave/current/msg07582.html
Another alternative solution, which does not require any change to
the address format defined in [Address-Format], is to define a new
DNS record type to unambiguously distinguish synthetic AAAA records
from native AAAA ones. This proposal is specified in [DNS-A64]
(Refer particularly to Section 3.1).
5. Security Considerations
There is no new security risk introduced by using the Hybrid Type
Prefix for address synthesizing.
Xu, et al. Expires July 15, 2010 [Page 7]
Internet-Draft Hybrid Type Prefix January 2010
6. IANA Considerations
No action is required from IANA.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[Address-Format] Huitema, C., Bao, C., Bagnulo, M., Boucadair, M.,
and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-02 (work in progress),
December 2009.
[NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to
IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-07
(work in progress), December 2009.
[DNS64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", draft-ietf-behave-
dns64-03 (work in progress), December 2009.
[NAT-STANDBY] Xu, X., Boucadair, M., "Redundancy and Load Balancing
Mechanisms for Stateful Network Address Translators (NAT)",
draft-xu-behave-stateful-nat-standby-01 (work in progress),
June 2009.
[DNS-A64] Boucadair, M., Burgey, E., " A64: DNS Resource Record for
IPv4-mapped IPv6 Address", draft-boucadair-behave-dns-a64-
01 (work in progress), October 2009.
[64-Analysis] Penno, R., Saxena, T., Wing, D., "Analysis of 64
Translation", draft-penno-behave-64-analysis-02 (work in
progress), January 2010.
Xu, et al. Expires July 15, 2010 [Page 8]
Internet-Draft Hybrid Type Prefix January 2010
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Cameron Byrne
T-Mobile USA, Inc.
3617 131st Ave SE
Bellevue, WA 98006
USA
Email: cameron.byrne@t-mobile.com
Mohamed Boucadair
France Telecom
3, av Francois Chateau
Rennes 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Gang Chen
China Mobile