Network Working Group H. Miyata
Internet-Draft Yokogawa Electric Corp.
Intended status: Informational M. Bagnulo
Expires: September 10, 2009 UC3M
March 9, 2009
PREFIX64 Comparison
draft-miyata-behave-prefix64-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
Miyata & Bagnulo Expires September 10, 2009 [Page 1]
Internet-Draft PREFIX64 Comparison March 2009
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.
Miyata & Bagnulo Expires September 10, 2009 [Page 2]
Internet-Draft PREFIX64 Comparison March 2009
Abstract
This draft compares different IPv6 prefix formats that can be used by
IPv6-IPv4 translator to represent IPv4 addresses in the IPv6
Internet. The goal of the draft is asses the benefits and problems
of each proposed format and make a recommendation about which prefix
to use in the different scenarios considered.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. PREFIX64 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Types of prefixes considered . . . . . . . . . . . . . . . . . 7
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. IPv6 Routing system scalability . . . . . . . . . . . . . 9
5.2. Prefix length . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Referral support . . . . . . . . . . . . . . . . . . . . . 12
5.4. Native connectivity preference in communications
involving dual stack nodes . . . . . . . . . . . . . . . . 16
5.5. DNSALG configuration . . . . . . . . . . . . . . . . . . . 17
5.6. Support for multiple translators . . . . . . . . . . . . . 17
6. Preliminary conclusion . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Miyata & Bagnulo Expires September 10, 2009 [Page 3]
Internet-Draft PREFIX64 Comparison March 2009
1. Introduction
IPv6-IPv4 translators are needed in order to enable communication
between IPv4 and IPv6 nodes during the IPv4-IPv6 coexistence phase.
In order to perform the required function, the translator needs to
represent IPv4 addresses in the IPv6 address space and the IPv6
addresses in the IPv4 address space. Now, representing the IPv6
addresses in the IPv4 address space requires some form of translation
state that will define the mapping between the original IPv6 address
and its representation in the IPv4 address space, However, due to the
abundance of bits in the IPv6 address space, it is possible to
represent an IPv4 address in the IPv6 Internet by embedding the
original IPv4 address in the IPv6 address that will serve as its
representation in the IPv6 address space.
The IPv6 address representing the IPv4 address will then be formed by
prepending an IPv6 prefix and optionally appending a suffix. This
memo analyzes the different options to form the IPv6 representation
of an IPv4 address. This document attempts to describe the
advantages, shortcomings, required configuration and preferable
utilization for each option.
Miyata & Bagnulo Expires September 10, 2009 [Page 4]
Internet-Draft PREFIX64 Comparison March 2009
2. Terminology
o NAT64: is a translator device that translates communications
initiated from the IPv6 side towards the IPv4 side.
o NAT46: is a translator device that translates communications
initiated from the IPv4 side towards the IPv6 side.
o DNS64: is a DNS-ALG that synthesizes AAAA RRs for IPv6 nodes
served by a NAT64 box querying for an FQDN that has no AAAA RR but
does have an A RR associated.
2.1. PREFIX64
The IPv6 representation of an IPv4 address will be formed by
concatenating a prefix, the IPv4 address and optionally a suffix.
The prefix is called the PREFIX64 and the suffix is called SUFFIX64.
The resulting IPv6 representation is depicted in the figure below.
0 127
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX64 | IPv4 addr | SUFFIX64 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2.1: IPv6 representation of an IPv4 address
The NAT64 device will announce a route in the IPv6 network to sink
packets directed to the IPv4 network. This route will contain an
IPv6 prefix that contains part if not all the IPv6 addresses
representing the IPv4 addresses. This means that the prefix
announced can be the PREFIX64 part alone (if the NAT64 is injecting
an IPv4 default route), or can be the PREFIX64 plus part of the IPv4
address (if only a part of the IPv4 address space is routed through
the particular NAT64 box) In addition, the PREFIX64 and the SUFFIX64
(if used) are used by the DNS64 function to synthesize AAAA RR. So,
the PREFIX64 and the SUFFIX64 (if used) are configured for each NAT64
gateway, and DNS64 function.
Miyata & Bagnulo Expires September 10, 2009 [Page 5]
Internet-Draft PREFIX64 Comparison March 2009
3. Scenarios
Four transition scenarios have been identified as relevant:
o IPv6 Internet to an IPv4 network
o IPv4 Internet to an IPv6 network
o An IPv6 network to the IPv4 Internet
o An IPv4 network to the IPv6 Internet
Miyata & Bagnulo Expires September 10, 2009 [Page 6]
Internet-Draft PREFIX64 Comparison March 2009
4. Types of prefixes considered
In this section we describe the different prefixes that can be used
to represent an IPv4 address in the IPv6 address space. The relevant
characteristics of the prefix are:
o LIR prefix versus Well-Known prefix: In the Well-Known option, the
most significant bits of the prefix used to represent IPv4
addresses in the IPv6 address space can come from a special well
known prefix assigned by IANA for this purpose or they can come
from the address block that has been assigned to the network that
is running the translator box. In the LIR (Local Internet
Registry) option, each site allocates one prefix of its own IPv6
address block to represent IPv4 addresses in the IPv6 address
space. In the case of a Well-Known prefix, there would be a
single representation of a public IPv4 address in the IPv6 address
space, while in the case of the LIR prefix, each network running a
translator will use a separate representation of the IPv4 address
space.
o Prefix length: The prefix can have different lengths (irrespective
of whether the prefix is LIR or Well-Known). One possible choice
is to have a /96 prefix. In this case, the IPv6 representation of
an IPv4 address is simply the prefix concatenated with the IPv4
address. Another option is to have a /32 prefix. In this case,
the address representing an IPv4 address would be the prefix
concatenated to the IPv4 address and then a suffix (that can be
::). In this case, all the "relevant" information is located in
the upper 64 bits, which can be used for routing following the
IPv6 address architecture guidelines. Other prefix lengths can be
also considered, depending on the case. For instance, using a /40
prefix would allow to represent an IPv4 /24 as an IPv6 /64.
o Other elements being considered include:
* IDENT bits: The idea is to stuff a bit pattern in the interface
identifier part of the IPv6 address that represents an IPv4
address to mark the address as an IPv6 representation of an
IPv4 address. In particular, it is possible to use the IANA
OUI for IPv4 address representation.
* NAT selector bits: The idea here is to include some bits (6-8
bits) to select the NAT that will be used to route the packets
towards the IPv4 Internet. In this way, in the case a site is
being served by multiple translators, they all can use the same
prefix while still identifying a given exit route through a
particular translator. One way to do this is for those bits to
be part of the LIR prefix, and give each NAT64 a different LIR
prefix. Another way to do this would be to use the Well-Known
prefix followed by some bit to identify a particular NAT64 box
(these bits would be managed locally)
Miyata & Bagnulo Expires September 10, 2009 [Page 7]
Internet-Draft PREFIX64 Comparison March 2009
* Additional information that may be useful to stuff into the
IPv6 address regarding the IPv4 packet, notably the port
information, for potential usage with A+P type of proposals.
Miyata & Bagnulo Expires September 10, 2009 [Page 8]
Internet-Draft PREFIX64 Comparison March 2009
5. Analysis
In this section, we analyze the impact of the prefix type in the
different scenarios.
5.1. IPv6 Routing system scalability
One critical issue to consider when understanding the impact of the
type of prefix used is related to the scalability of the routing
system. Since a goal of the transition is to make IPv4 only-hosts
reachable by IPv6-only nodes, the IPv6 addresses representing IPv4
addresses need to be routable in the portion of the IPv6 network
served by the NAT64 device. This implies that the PREFIX64 must be
contained in one of the routes in the IPv6 domain. One option is to
use a default route in the IPv6 domain which would obviously cover
the PREFIX64. Another option is to inject one or more routes
covering the PREFIX64. Thus, depending on the prefix used and the
scenario considered, the contribution to the IPv6 routing table may
vary. In this section we analyze the effect of the different
possible prefixes in the IPv6 routing system.
The scenarios described above can be classified in two classes,
depending on the scope of the routing information injected by the
translator:
o Connecting an IPv4 Network and the IPv6 Internet: In this case,
the routing information for reaching the IPv6 prefix used to map
the IPv4 addresses we want to communicate with is injected to the
whole IPv6 Internet. There are two of the above scenarios in this
class, namely:
* IPv6 Internet to an IPv4 network
* An IPv4 network to the IPv6 Internet
o Connecting an IPv6 network and the IPv4 Internet: In this case,
the scope of the routing information about the IPv6 prefix that
represents the IPv4 addresses is limited to the IPv6 network.
There are two of the above scenarios in this class, namely:
* IPv4 Internet to an IPv6 network
* An IPv6 network to the IPv4 Internet
A scenario falling in the first class (Connecting an IPv4 Network and
the IPv6 Internet) is depicted in the figure below. In this case a
translator box is located in one of the ends of the link between the
IPv4 site and the IPv6-only ISP.
Miyata & Bagnulo Expires September 10, 2009 [Page 9]
Internet-Draft PREFIX64 Comparison March 2009
+--------------------------------------+
| |
| IPv6 Internet |
| |
+--------------------------------------+
| | | |
| | | |
| | | |
+-----------+ +--------------------+
| | | Rest of |
| IPv6 ISP |------| IPv4 Internet |
| | +--------------------+
| | |
+-----------+ +-----------+
| | | IPv4 site |
| +-----| Pref4 |
| +-----------+
|
| +-----------+
+-------------| IPv6 site |
+-----------+
Figure: IPv6 Internet to an IPv4 network
Private and overlapped IPv4 addresses
In the case that the IPv4 site is using private or overlapped IPv4
addresses (e.g. [I-D.shirasaki-isp-shared-addr]), then the option of
using a Well-Known prefix for the IPv6 representation is not
possible, because multiple sites using private addresses would use
the same IPv6 representation breaking uniqueness of address
allocation. In this case, the only option is to use a LIR prefix
(either allocated to the IPv6 ISP or directly allocated to the end
site). It should be noted that in the face of the imminent IPv4
depletion, this scenario is expected to be fairly common.
Public addressing
In the case the IPv4 end site is using public addresses, the usage of
the Well-Known prefix would not lead into address collision.
However, it seems that it may have a negative effect on the BGP
global routing table. In particular, in the case depicted above, the
IPv6 ISP would need to inject a route for each non aggregatable IPv4
address block its customers have (the IPv6 route injected would
announce the prefix formed by concatenating the Well-Known prefix and
the IPv4 prefix). On the other hand, if a LIR prefix is used, the
ISP would only need to announce its own prefix, which would contain
Miyata & Bagnulo Expires September 10, 2009 [Page 10]
Internet-Draft PREFIX64 Comparison March 2009
the IPv6 representation of the IPv4 address of its customers. So,
again in this case, it seems that the LIR option is preferred.
For the scenarios in the second class (Connecting an IPv6 network and
the IPv4 Internet) the routing scalability issue seems much less
relevant, as the scope of the routing information is limited to the
IPv6 network. In this case, it is most likely that a default route
to the IPv4 Internet is enough and in the case additional routes are
needed, their scope will be limited to the IPv6 network. So, in the
scenarios of this class, other criteria seems to be more relevant
than this one.
5.2. Prefix length
One issue that is worth considering is the one related to IPv6
address consumption. In particular, depending on the selected prefix
length, IPv6 address consumption can become an issue. If we consider
the case of the Well-Known prefix, the prefix would be allocated by
IANA for this particular purpose. As such, it seems reasonable that
a short prefix can be obtained for this. Requesting for a /24 or
even a few bits shorter seems feasible. If a prefix shorter than a
/32 is obtained, the potential benefit is that IPv4 prefixes can be
represented as IPv6 prefixes that are shorter than 64 bits. This
would result in routing based on the upper 64 bits, which is
compatible with current IPv6 practices. For instance, if we use a
/24 for the Well-Known prefix, an IPv4 /24 would result in an IPv6
/48, which seems somehow equivalent from the routing perspective.
On the other hand, if we go for the LIR prefix option, then the
prefix must come out of the IPv6 allocation for the site running the
translator. If the site running the translator is an ISP, then
probably the allocation of the ISP is a /32 or shorter, so, it may be
possible for the ISP to allocate a somehow short prefix for this,
maybe a /40. However, if the translator is run by an end site, which
normal allocation is a /48, then the LIR prefix for the translator
should be much longer than that, possibly a /56. So, in the case the
site needs to route based on the IPv4 prefix embedded in the IPv6
address (e.g. in order to access to different parts of the IPv4 space
through different routes or different NAT64 devices), then it is
likely that it will need to route on the lower 64 bits of the IPv6
address.
According to current specifications, routers must handle routes
containing prefixes of any valid length, from 0 to 128. However,
some users have reported that routers exhibit worse performance when
routing using long prefixes, in particular when using prefixes longer
than 80 bits. This implies that using prefixes shorter than that
would result in better performance in some cases.
Miyata & Bagnulo Expires September 10, 2009 [Page 11]
Internet-Draft PREFIX64 Comparison March 2009
Conclusion: a Well-Known prefix seems to allow a site running a NAT64
to always route in the higher 80 bits, so it seems to provide some
additional advantage.
5.3. Referral support
This section analyzes the impact of the prefix type selected for
representing the IPv4 addresses in the IPv6 Internet (Pref64::/N) in
the referral operations.
A referral operation is when a host A passes the IP address of a Host
B to a third Host C as application data. The host Host C will then
initiate a communication towards the Host B using the IP address
received. This is a common operation in some type of applications,
such as VoIP or peer-to-peer applications.
In this section, we perform a general analysis of basic referral
operations. A more in depth analysis for the case of SIP can be
found in [I-D.wing-behave-nat64-referrals]
There are several referral scenarios as described in this table:
| Host A | Host B | Host C |
---------------------------------------
Scenario 1 | v6 | v6 | v4 |
---------------------------------------
Scenario 2 | v6 | v4 | v6 |
---------------------------------------
Scenario 3 | v4 | v6 | v6 |
---------------------------------------
Scenario 4 | v6 | v4 | v4 |
---------------------------------------
Scenario 5 | v4 | v6 | v4 |
---------------------------------------
Scenario 6 | v4 | v4 | v6 |
---------------------------------------
All the scenarios where Host A and Host C use a different IP version
require a specific ALG, since the IP address information contained as
application data must be translated, in order to be meaningful to the
receiver (these are scenarios 1, 3, 4 and 6). Scenarios 2 and 5
could work without ALG.
In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is
IPv6 will need some form of static NAT configuration (either the
stateless translation or manual configuration of bindings) to work
Miyata & Bagnulo Expires September 10, 2009 [Page 12]
Internet-Draft PREFIX64 Comparison March 2009
because they imply an IPv4 node initiating a communication towards an
IPv6 node.
Let's consider the scenario 2, which should work in the dynamic
binding case without ALGs first:
There are two relevant configurations for scenario 2: when both Host
A and Host C are using the same NAT64 box to reach Host B and when
Host A and Host C are using different NAT64 boxes to reach Host C.
The case where different NAT64 boxes are involved is considered next
and then we will move to the case where a single NAT64 box is
involved.
The case where different NAT64 boxes are involved is depicted next:
|
|
Host_A ---(ISP_A)---NAT64--\
| | >---Host_B (IPB)
Host_C ---(ISP_B)---NAT64--/
|
|
IPv6 Internet | IPv4 Internet
Figure: Referral scenario #2 involving multiple NAT64 boxes
So, in this case, Host A will be sending Host B's address to Host C
as application data. Now, in the eyes of Host A, Host B's address is
Pref64_1:IPB:suffix (the suffix is optional, depending on whether
Pref64_1 is 96 bits long or shorter).
Host C will then receive Pref64_1:IPB:suffix and will try to initiate
a communication toward host B using that address.
We now have two options depending on if the prefix Pref64_1 is a
Well-Known prefix or is a LIR prefix.
o LIR prefix: Host C sends a packet towards Pref64_1:IPB:suffix.
The packet is routed towards Site 1 since Pref64_1 is part of
site's 1 address block. Now, Site 1 has 3 options. Either it
forwards the packet to the IPv4 internet or drops it (it can drop
it at the ingress or in the translator box). This option doesn't
make economical sense for site 1 to forward the packet towards the
v4 internet, because if it did so, it would be providing free v6
Miyata & Bagnulo Expires September 10, 2009 [Page 13]
Internet-Draft PREFIX64 Comparison March 2009
to v4 transit. So, it makes sense for site 1 to drop the packet.
Now, if Site 1 drops packets addressed to Pref64_1 coming from the
outside, referrals break.
o Well-Known prefix: In this case Pref64_1=Pref64_2=Pref64. So,
HostA sends Pref64:IPB_suffix to Host C. Host C now sends a packet
to Pref64:IPB:suffix. In this case, the packet will flow through
whatever route Site2 has to connect to the IPv4 Internet. In the
case depicted in the picture, site2 has its own translator, that
then would announce a route towards Pref64, so the packet will
flow through the direct route Site2 has to the IPv4 Internet. So,
from this analysis, referrals would work if a Well-Known prefix is
used.
|
|
Host_A --------------NAT64-->---Host_B (IPB)
/ |
Host_C ---/ |
|
|
IPv6 Internet | IPv4 Internet
Figure: Referral scenario #2 involving a single NAT64 box
This scenario can occur in two different situations. One situation
where this can happen is when we are in the IPv6-network-to-IPv4-
Internet and that both Host A and Host C are in the same site or
served by the same ISP (which is providing NAT64 services). The
other case where this can happen is on the IPv6-Internet-to-An-IPv4-
network and the IPv4 network is running the NAT64 box.
In this case, both the Well-Known prefix and the LIR prefix would
work, cause the is a single IPv6 representation of the IPv4 address
of Host B involved, cause there is only one NAT64 box involved.
So, let's consider the scenarios that may require an ALG next.
Scenarios 1, 3, 4 and 6.
A general observation about these scenarios is that in the case a
Well-Known prefix is used, it would be possible for the ALG to
identify the IPv6 addresses containing an embedded IPv4 address and
translate it, cause they could identify the Well-Known prefix and
Miyata & Bagnulo Expires September 10, 2009 [Page 14]
Internet-Draft PREFIX64 Comparison March 2009
know that are not general use IPv6 addresses. If the Pref64 is a LIR
prefix, it may be possible for the ALG to translate the address in
the referral, as long as the translator is configured to know that
this specific prefix is unused to map IPv4 addresses.
Another possible case is when the application running in Host A and
Host C supports both IPv6 and IPv4, but that the hosts have only one
type of connectivity. In this case, if the application receives an
IPv6 address, it could extract the IPv4 address and use it if it
knows there is only IPv4 connectivity available. Similarly, if the
application could create an IPv6 address from the IPv4 address and
use it if it knows there is only IPv6 connectivity available. So, in
scenarios 1 and 4, Host A is v6 and Host C is v4. Let's assume that
the application performing the referral supports both v4 and v6. In
scenarios 1 and 4, Host A would pass an IPv6 address embedding an
IPv4 address to Host C. Host C has only IPv4 connectivity. The
application in Host C could take the IPv6 address and if the well-
known prefix is used, identify that this is an IPv6 representation of
an IPv4 address and extract the IPv4 address and use it. If the LIR
prefix is used, the application would need to know the LIR prefix to
be able to do this, which is not true in the general case. In
scenarios 3 and 6, Host A is v4, so it will send an IPv4 address.
Host C is v6 but the application is v4 and v6. In this case, the
application can create the IPv6 representation of the received IPv4
address. In order to do that, it needs to discover the PREFIX64 used
for that. If the well known prefix is used, the prefix can be
hardcoded in the application. If the LIR prefix is used, the
application will need to implement additional tools to discover it.
So, we can say that a Well Known prefix is more likely to work with
referral in the case that an ALG is needed than the LIR prefix. In
scenarios 1 and 4, referrals are more likely to work with the Well-
known prefix, even without ALG and in scenarios 3 and 6, referrals
are likely to require additional tools to discover the LIR prefix if
this is used.
Scenario 5
Host A is v4, host B is v6 and host C is v4
In this case, we need a representation of Host B in the v4 world. In
this case, the Pref64 seems hardly relevant.
Conclusion: We can say that in some scenarios, the LIR and the Well-
Known prefix provide a similar support for referrals, while there are
other scenarios a Well-Known prefix is more likely to work with
referral that the LIR prefix.
Miyata & Bagnulo Expires September 10, 2009 [Page 15]
Internet-Draft PREFIX64 Comparison March 2009
5.4. Native connectivity preference in communications involving dual
stack nodes
When dual stack nodes are involved in the communication, the
potential issue is that they prefer translated connectivity over the
native connectivity. There are multiple ways to try to deal with
this issue.
There are two different cases involving dual-stack nodes.
Communication initiated from a dual stack node towards an IPv4-only
node and communication initiated from an IPv6-only node towards a
dual stack node. We will next consider each one of these cases.
Communication initiated from an IPv6-only node towards a dual stack
node
In this case, the IPv6 only node will query for the FQDN of the dual
stack node. The DNS64 function will try first to get the AAAA RR.
Since there is one available, it will return it and no AAAA RR will
be synthesized from the A RR of the dual stack node. However, it
should be noted that the DNS64 must first try to get the real AAAA RR
before starting the synthesis, if not, it may result in the
aforementioned problem. This case seems orthogonal to the type of
PREFIX64 used, so it provides no additional criteria on this matter.
Communication initiated from a dual stack node toward an IPv4 only
node
Nodes that have both IPv6 and IPv4 connectivity and are configured
with an address for a DNS64 as their resolving nameserver may receive
responses containing synthetic AAAA resource records. If the node
prefers IPv6 over IPv4, using the addresses in the synthetic AAAA RRs
means that the node will attempt to communicate through the NAT64
mechanism first, and only fall back to native IPv4 connectivity if
connecting through NAT64 fails (if the application tries the full set
of destination addresses). (We are assuming that the IPv4 only node
has a public IPv4 address, so it can be reached through IPv4 and also
be reached from the IPv6 Internet using a NAT64. In the case, the
IPv4 only host has only a private IPv4 address, then there is no A RR
so, the only possible connectivity is through the NAT64 and there is
no issue)
In order for the node to prefer native connectivity, we can configure
the PREFIX64 in the RFC3484 policy table. If a Well-Known prefix is
used, it can be configured in the default policy table. If we use a
LIR prefix, we need a means to properly configure the policy table,
which is not currently available (only manual configuration is
currently defined) (see [I-D.ietf-6man-addr-select-sol] for more on
Miyata & Bagnulo Expires September 10, 2009 [Page 16]
Internet-Draft PREFIX64 Comparison March 2009
this topic).
5.5. DNSALG configuration
The DNS64 address rewriting function translates A records to AAAA
records and needs to know the PREFIX64. This is straight forward if
the PREFIX64 is a well-known prefix.
If the PREFIX64 is the LIR prefix, it needs to be configured into the
host performing the DNS64 function. If this is a server, such
configuration is trivial. However, an end host would need to learn
the PREFIX64 automatically (e.g., using DHCP) but DNSSEC would also
require secure learning of the PREFIX64. Mechanisms to learn
PREFIX64 securely, without a pre-shared secret [RFC3118], are still
being studied.
The result is that the LIR prefix option requires more tools than the
Well Known prefix in the IPv6-network-to-IPv4-Internet case.
5.6. Support for multiple translators
Consider the following scenario:
Miyata & Bagnulo Expires September 10, 2009 [Page 17]
Internet-Draft PREFIX64 Comparison March 2009
+--------------------------------------+
| +--+ |
| |H2| IPv4 Internet |
| +--+ |
+--------------------------------------+
| |
| |
| |
+-------+ +-------+
+-|NAT64_1|------------------|NAT64_2|--+
| +-------+ +-------+ |
| | | |
| +--+ +--+ |
| |R1|----------------------|R3| |
| +--+ +--+ |
| | | |
| +--+ | |
| |R2|-----+ | |
| +--+ | | |
| ----------------------- |
| | LAN1 |
| +--+ |
| |H1| |
| IPv6 site +--+ |
+---------------------------------------+
Figure: Multiple translator scenario
Routing hiccups
Consider the case host H1 is communicating with host H2 using TCP.
Suppose that shortest path routing based on hop count is used in the
IPv6 site.
If both translators are using the same prefix to represent IPv4
addresses in the IPv6 Internet, then both NAT64_1 and NAT64_2 would
announce a route to the prefix in the IGP. In that case, packets
from H1 to H2 will flow through NAT64_2. Suppose now that the
interface of R3 that is attached to LAN1 goes down. The result is
that NAT64_1 is closer from H1 than NAT64_2 in the new topology, so
packet will flow through NAT64_1. As a consequence, the established
TCP connection will break, cause the IPv4 address presented to H2
will change after packets start flowing through NAT64_1.
On the other hand, if a different prefix is assigned to each
translator, then the situation is that each translator will be
announcing a route to a different prefix so, no matter what changes
Miyata & Bagnulo Expires September 10, 2009 [Page 18]
Internet-Draft PREFIX64 Comparison March 2009
occur in the intra site routing, the communication will always flow
through the same NAT64 device as long as there is a path available.
However, this is not the only scenario to be considered when dealing
with multiple NAT64 boxes. Consider next the interaction with the
DNS64. In the case there is a single prefix being used by both
translators, then the task of the DNS64 is simple, it needs to
synthesize AAAA RR using the prefix. As long as there is a
translator working and announcing a route to the prefix, the
communication will flow. On the other hand, if there are multiple
prefixes, then the DNS64 needs to select which prefixes to use when
synthesizing the AAAA RR. This may be tricky when one of the
translators is down. In that case, using the prefix assigned to that
translator would prevent the communication. There are multiple ways
to deal with this situation. One option is to allow the DNS64 to
synthesize multiple AAAA RRs using the different prefixes and
eventually return them in a round robin order to achieve load
balancing. If the translator associated to the first prefix is down,
then the host would retry with the second address corresponding to
the alternative translator. The problem with this approach is that a
host's different TCP connections would likely go out different
NAT64s. And because each NAT64 has a different public IPv4 address,
the host's different TCP connections now have different IPv4
addresses -- which most of the IPv4 Internet regards as "different
identities" (because IPv4 address = identity). This breaks certain
applications [e.g., see http://cr.yp.to/ftp/security.html, web
applications that embed IP addresses in cookies or their
authorization mechanisms). Other options would include both
translators injecting routes to both prefixes, but with different IGP
weight, or that the DNS64 probes the NAT64 boxes for availability.
This issue is somehow orthogonal on whether the prefix is Well-Known
or LIR. In both cases, it is possible to use a single prefix for
multiple translators or different prefixes for different translators.
In any case, this would be achieved by inserting (or not) some subnet
bits between the prefix and the embedded IPv4 address that would be
used to identify the translator box. This issue does have
implications on some of the different issues considered before. In
particular, if a per translator prefix is used, then there is the
need to configure the prefix in the DNSALG, so the non configuration
feature of the Well-Known prefix is no longer achieved.
Miyata & Bagnulo Expires September 10, 2009 [Page 19]
Internet-Draft PREFIX64 Comparison March 2009
6. Preliminary conclusion
Strong conclusion: The LIR prefix seems suitable option for the IPv6-
Internet-to-an-IPv4-network scenario.
Weak conclusion: The Well-Known prefix seems to provide some
advantages over the LIR prefix in the An-IPv6-network-to-IPv4-
Internet scenario.
Miyata & Bagnulo Expires September 10, 2009 [Page 20]
Internet-Draft PREFIX64 Comparison March 2009
7. Security Considerations
The PREFIX64 is a critical piece of information when synthesizing
AAAA RR by the DNS64. So, the PREFIX64 must be learn in a secure
fashion by the DNS64. As we discussed previously, if PREFIX64 is a
Well-Known prefix it can be hardcoded in the DNS64, but it is a LIR
prefix, additional means need to be provided to allow DNS64 to learn
the PREFIX64 to be used in a secure manner.
Miyata & Bagnulo Expires September 10, 2009 [Page 21]
Internet-Draft PREFIX64 Comparison March 2009
8. Acknowledgement
This draft has benefits from contributions from Fred Baker, Erik
Nordmark, Dan wing, Dave Thaler, Iljitsch van Beijnum and Xing Li.
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
Miyata & Bagnulo Expires September 10, 2009 [Page 22]
Internet-Draft PREFIX64 Comparison March 2009
9. References
9.1. Normative References
[RFC2119] Bradner, S. and E. Davies, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, BCP 14,
March 1997.
9.2. Informative References
[I-D.ietf-6man-addr-select-sol]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Solution approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-01 (work in progress),
June 2008.
[I-D.shirasaki-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "ISP Shared Address",
draft-shirasaki-isp-shared-addr-01 (work in progress),
October 2008.
[I-D.wing-behave-nat64-referrals]
Wing, D., "Referrals Across a NAT64",
draft-wing-behave-nat64-referrals-00 (work in progress),
March 2009.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
Miyata & Bagnulo Expires September 10, 2009 [Page 23]
Internet-Draft PREFIX64 Comparison March 2009
Authors' Addresses
Hiroshi Miyata
Yokogawa Electric Corporation
2-9-32 Nakacho
Musashino-shi, Tokyo 180-8750
JAPAN
Email: h.miyata@jp.yokogawa.com
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
ESPANA
Email: marcelo@it.uc3m.es
Miyata & Bagnulo Expires September 10, 2009 [Page 24]