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]