Network Working Group H. Miyata Internet-Draft Yokogawa Electric Corp. Intended status: Informational October 14, 2008 Expires: April 17, 2009 PREFIX64 Comparison draft-miyata-behave-prefix64-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 17, 2009. Miyata Expires April 17, 2009 [Page 1] Internet-Draft PREFIX64 Comparison October 2008 Abstract There are several NAT64 and/or NAT46 proposals. Each of them have recommended PREFIX64, which is used to represent IPv4 address in IPv6 address format. Each of them have advantages and shortcomes. Therefore the preferable PREFIX64 would depends on the utilization scene. This draft compares seven proposals for IPv6 and IPv4 coexistence.i Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. PREFIX64 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 3. PREFIX64 Comparison . . . . . . . . . . . . . . . . . . . . . 5 3.1. IVI Prefix . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Shortcomes . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Applicability . . . . . . . . . . . . . . . . . . . . 8 3.2. Local Prefix . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Shortcomes . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Configuration . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Applicability . . . . . . . . . . . . . . . . . . . . 13 3.3. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 14 3.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.2. Shortcomes . . . . . . . . . . . . . . . . . . . . . . 16 3.3.3. Configuration . . . . . . . . . . . . . . . . . . . . 17 3.3.4. Applicability . . . . . . . . . . . . . . . . . . . . 18 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Miyata Expires April 17, 2009 [Page 2] Internet-Draft PREFIX64 Comparison October 2008 1. Introduction In several proposals, some kinds of PREFIX64 ideas are introduced. Also, there are several scenarios to utilize translator technology. Each scenario may have each requirement for translator. For example, the home netwrok, which would be stub network, prior simpleness to scalability. In contrast, ISP network will prior scalability. Each proposed PREFIX64 has different characteristic. Therefore, to discuss which is recommended or not, the quantitative analysis is required. It is possible the preferabe PREFIX64 depends on the scenario or, in more detail, depends on the administrator's requirement. This document is attmpting to describe the advantages, shortcomes, required configuration and pereferable utilization for each PREFIX64. Miyata Expires April 17, 2009 [Page 3] Internet-Draft PREFIX64 Comparison October 2008 2. Terminology 2.1. PREFIX64 The IPv6 Prefix to map IPv4 address to IPv6 address. The prefix is advertised in an IPv6 network by the NAT64 gateway, and packets addressed to this Prefix will be routed to the NAT64 gateway. This Prefix is configured for each NAT64 gateway, and DNS re-writing function. The DNS re-writing function will use it to synthesize AAAA RR. 2.2. Requirements notation 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]. Miyata Expires April 17, 2009 [Page 4] Internet-Draft PREFIX64 Comparison October 2008 3. PREFIX64 Comparison This section describes the characteristics of each kind of PREFIX64. The prefixes, which this document analysis are classified into IVI Prefix, Local Prefix and Well-Known Prefix. If there are prefixes which is not covered by above three kinds of Prefix, please inform to the authers. 3.1. IVI Prefix The IVI Address is an IPv4 address embedded in an IPv6 address and predictable by the gateway and systems on either side. The selection of the LIR prefix, including its length and absolute value, is at the option of the network administration; it is not fixed. Figure 3.1.1 shows one possible model. It enables the IPv6 domain to assign the equivalent of IPv4 /24 prefixes to IPv6 LANs (/64). 0 8 16 24 32 40 48 56 64 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LIR Prefix | IPv4 addr | entirely 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |<-----prefix part ---->|<--- host part --->| Figure 3.1.1: Example IVI Address Format In Figure 3.1.2, shows the detail structure of LIR Prefix. | 0 |32 |40 --------------------+---+ | |FF | --------------------+---+ |<- IPv6 prefix ->| | Figure 3.1.2: LIR Prefix In the IPv4 domain, this represents a prefix no longer than /24. In the IPv6 domain, the "default route" advertising the entire IPv4 address space is the LIR /40 prefix. More specific prefixes up to /64 may be advertised as needed, or host (/128) routes. The objective here is to enable the network administration to be in control of the impact of the tradeoff on its routing. For more detail information about IVI, see [ID-baker] Miyata Expires April 17, 2009 [Page 5] Internet-Draft PREFIX64 Comparison October 2008 3.1.1. Benefits Address Mapping: The IVI address format allows stateless IPv6 address mapping to IPv6 addresses and vice versa. From an IVI style IPv6 address the correspondent IPv4 address, and vice versa, can be calcurated easily. Address Selection: As the LIR of IVI address has "0xFF" at the end, it matches to non-IVI IPv6 address no longer than 32 bit. So, a IPv6 client unlikely prior the IVI address to non-IVI IPv6 address by longest match manner. Also, the DNS re-writing function priors the normal IPv6 address to synthetic address. Therefore, when the client uses DNS to resolve the address, it can choose native connection naturally. Synthetic Address Detection: The LIR has the value "0xFF" at the last octet. If the value "0xFF" at the first 33 - 40 bit is globally assinged for synthetic address, it is possible to detect the synthetic address by the node and/or application. Multiple Gateway: The IVI address is independent to IVI gateway. Therefore any gateway can translate IPv6 packet to IPv4 packet addressed to IVI address. Also, since the IVI address has global IPv4 address in it, the higher 64 bit represents globally unique IPv4 addres space irrespectively the IVI gateway. Scalability: As IVI address allows complete stateless address mapping, it allows to use multiple gateway in one IPv6 realm. Also, it allows to omit the maintainance of address mapping table. Althogh, as described in "Routing" part, there is a concern on IPv6 routing table, the IVI address can be used for the scalabile solution in general. Miyata Expires April 17, 2009 [Page 6] Internet-Draft PREFIX64 Comparison October 2008 3.1.2. Shortcomes Access to IPv4 Private Address: Basically, the IVI is designed to provide the access between IPv6 node and IPv4 node w/ global IPv4 address. So, if the multiple sites uses the same private IPv4 address, it is impossible to distinguish under one LIR prefix. IPv4 Address Efficiency: The IVI address is designed to map the IPv4 address to IPv6 address in block unit. For example /24 address block. It allows to omit the 1:1 address mapping configuration. On the otherhand, it may cause the "Dead Stock" global IPv4 address. From this perspective the administrator must pay best effor to assign the address most efficiently. To make it efficient, the address block should be smaller, but it will increase the IPv6 routing table. So, the assignment efficiency and routing table size are trade- off. Routing: Since all of the IPv6 nodes unlikely need to be accessed from IPv4 side, an administrator of IPv6 network will provide non-IVI prefix by default. Additionally he/she would assign the IVI address if required. Then, the network needs to advertise at leaset two prefixes to be routed the packet. Also, each IVI prefix assigend to the IPv6 network would be advertised in IPv6 network.Therefore, the IPv6 routing table would be increased. The bigger IPv4 address block would reduce the increase of IPv6 routing table, but it will also reduce the efficiency of IPv4 address assignment. The administrator need to consider the balance of this trade-off. Others: There is a restriction to use the IVI address. As it is desinged to use in large scale service, like ISP, the LIR is 40 bit length. It means the administrator other than ISP can not use this address. 3.1.3. Configuration Host: Each IVI node needs to be assigned the IVI address administratively. The configuration should be done [number of IVI nodes] times. To use IVI DNS re-writing function, the IPv6 node Miyata Expires April 17, 2009 [Page 7] Internet-Draft PREFIX64 Comparison October 2008 should be configured to send DNS query to appropriate DNS server somehow. But it is same as ordinally DNS configuration. Router: Each router, which is attached to the IVI node, need to be configured to advertise the IVI prefix. The configuration should be done [number of IVI prefix] * [number of attached routers] times. Gateway: The IVI address is designed to map the IPv4 address to IPv6 address in block unit. For example /24 address block or more can be assigned. It allows to omit the 1:1 address mapping configuration. From the gateway configuration perspective, it is easy to support bunch of IPv6 devices. Each IVI gateway needs to be configured its LIR. Also, it should be configured to advertise the "default route" for IPv4 network on IPv6 network. The configuration should be done [once]. And it should be configured to advertise the route for IPv4 network assigned to IVI network on IPv4 network. The configuration should be done [number of Aggregated IPv4 Prefix] times. DNS: The DNS re-writing funtion must be configured the LIR Prefix to synthesize the AAAA address for IPv6 node. The configuration should be done [number of DNS re-writing function] times. The DNS server, which is in charge of IVI nodes, needs to be configured each IPv4 address assigned to IVI node if reqruired. The configuration should be done [number of mapped IPv4 address] times. 3.1.4. Applicability The preferable usage of IVI prefix is as follows. o Large scale, ISP grade, translation. o Highly redundant translation service. o Provide the access from IPv4 client to IPv6 server. Miyata Expires April 17, 2009 [Page 8] Internet-Draft PREFIX64 Comparison October 2008 o Provide the access from IPv6 client to global IPv4 server. 3.2. Local Prefix Transport Relay Translator (TRT) [RFC3142] and NAT-PT [RFC2766] have almost same idea for PREFIX64, though the description are a bit different. [RFC3142] calls the prefix "Dummy Prefix". Both RFCs proposed to use a part of "real" local prefix assigned to the site. Figure 3.2.1 shows the address format with "Dummy Prefix". 1 1 2 6 7 9 2 0123456789012345678901234...01234567890...01234567890...012345678 +------------------------//-----+------//-------+----//---------+ | IPv6 Prefix | all "0" | IPv4 Address | | 64 bit | 32 bit | 32 bit | +------------------------//-----+------//-------+----//---------+ | | |<---------Dummy Prefix-------->| Fig. 3.2.1 Dummy Prefix Format The length of Dummy Prefix is 64 bit. It is a routable unicast prefix of IPv6. Any prefix can be assigned by the administrator from the address space he/her is administrating as far as it is not assigned. The following 32 bit are filled with zero. And the last 32 bit are filled with IPv4 address. If we use a part of local preifx for PREFIX64, it is difficult to distinguish synthetic address from native address. So, [ID-miyata] proposed to put identifier bit at 64-95 bit of the synthetic address. The identifier bit is called IDENT bit in [ID-miyata]. Figure 3.2.2 shows the address format with IDENT bit. Miyata Expires April 17, 2009 [Page 9] Internet-Draft PREFIX64 Comparison October 2008 1 1 2 6 7 9 2 0123456789012345678901234...01234567890...01234567890...012345678 +------------------------//-----+------//-------+----//---------+ | IPv6 Prefix | IDENT | IPv4 Address | | 64 bit | 32 bit | 32 bit | +------------------------//-----+------//-------+----//---------+ | | | |<-----------PREFIX64---------->|<-identifier-->| Figure 3.2.2 Dummy Prefix w/ IDENT Format To distingush the synthetic address regardless the PREFIX64, the IDENT must be the global unique value. From address architecture perspective, the IDENT must be the OUI and following 8 bit. Acturely, IANA has its own OUI. And IANA has assigned "0xFE" from their own OUI(00-00-5E) to indicate that an IPv4 address is encoded in following 32-bit as represented in Figure 3.2.3. 0 23 31 63 | OUI | 0xFE | IPv4 address | 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx Figure 3.2.3 IPv4 embedded address Format According to the definition, it could be used for NAT64 technology as the address contains the encoded IPv4 address. But it is used by ISATAP [RFC5214], one of tunneling technologies. From address selection perspective, the preferences for tunneled destination and trnslated destination are different. And, in [RFC4966], it is stated that NAT-PT gateway existence in the path must be detected by the end-node. So, same value as ISATAP should not be used for NAT64. It is desired to assign another value to NAT64 technology. 3.2.1. Benefits Address Mapping: The Local Prefix allows automatic IPv6 address mapping to IPv4. One Local Prefix can represent entire IPv4 network address. Miyata Expires April 17, 2009 [Page 10] Internet-Draft PREFIX64 Comparison October 2008 But for the reverse direction, the translator needs to search some kinds of address mapping information. Access to IPv4 Private Address: Basically, the Local Prefix is assigned by the site administrator. So, each site should have individual Local Prefix. Therefore the private address in a site can be represented with different Local Prefix. It means the private address in each site can be distinguish as the individual global address. IPv4 Address Efficiency: Basically, to map the IPv6 address to IPv4 address, it does not require IPv4 address. Only when static 1:1 address mapping is configured, IPv4 addresses are required. But, even in this case, the mapping is done for each address. It will not cause the "Dead Stock" IPv4 address. Routing: Since the nodes does not need additional address, no additional IPv6 routing information is required, with the exception of the Local Prefixes. Others: As the Local Prefix can be chosen by the administrator from the prefix under his/her control. It allows the flexible operation. 3.2.2. Shortcomes Address Mapping: When translating IPv4 packet to IPv6, the translator needs to search some kinds of address mapping information. Address Selection: As Local Prefix is a part of the "real" IPv6 unicast address assigned to the site, the IPv6 nodes likely prefer the synthetic address by longest match manner, when it attmpts to access to the node in other site. To make the Local Prefix less preferable, the administrator needs to configure the address selection policy. Miyata Expires April 17, 2009 [Page 11] Internet-Draft PREFIX64 Comparison October 2008 The DNS re-writing function priors the normal IPv6 address to synthetic address. Therefore, when the client uses DNS to resolve the address, it can prior native connection naturally. Synthetic Address Detection: Without globally unique IDENT bit, it is very hard to distinguish the synthetic address, since the higher 64 bits are completelly "real" IPv6 prefix. With globally unique INDE bit, the IPv6 nodes and/or applications can distinguish the synthetic address. But, since the IDENT bit is placed in the middle of IPv6 address, it is not useful for address selection which takes longest match manner. To use the IDENT to prior native address to synthetic address, address selection need to be changed to be able to compare the intermediate bits. Multiple Gateway: If the Gateway maintain the address mapping information dynamically, like NAPT style. It is difficult to use Multiple Gateway, without synchronizing the state. If the addresses are mapped in static 1:1 style, and the address mapping information and Local Prefix are shared amang the gateways, it is possible. Scalability: As Local Prefix is used with some address mapping information, both dynamic and static, it is less scalable than stateless address mapping method. Also, as Local Prefix is chosen from the prefix assigned to the site, it fits to site level usage. Practically, it can work up to entreprise scale, since the behavior is almost same as IPv4 NAT. Also, load balancing can be provided by multiple translators with individual Local Prefix as described in [ID-endo]. 3.2.3. Configuration Host: To use DNS re-writing function, the IPv6 node should be configured to send DNS query to appropriate DNS server somehow. But it is same as ordinally DNS configuration. Therefore, no special configuration is required for both IPv6 and IPv4 hosts. Router: Miyata Expires April 17, 2009 [Page 12] Internet-Draft PREFIX64 Comparison October 2008 No special configuration is required of routers. Gateway: Each gateway needs to be configured its Local Prefix. Also, it should be configured to advertise the Local Prefix on IPv6 network. The configuration should be done [once] * [number of gateway] times. If the addresses are mapped in static 1:1 style, each mapping must be configured inappropreate gateway. The configuration should be done [number of mapped address] * [number of shareing gateway] times. And it should be configured to advertise the route to IPv4 addresses assigned to IPv6 nodes if required. The configuration should be done [number of Aggregated IPv4 Prefix] times. DNS: The DNS re-writing funtion must be configured the Local Prefix to synthesize the AAAA address for IPv6 node. The configuration should be done [number of Local Prefix] times. The DNS server, which is in charge of the IPv6 nodes, needs to be configured each IPv4 address assigned to them if reqruired. The configuration should be done [number of mapped IPv4 address] times. 3.2.4. Applicability As Local Prefix is used with some address mapping information, both dynamic and static, it is less scalable than stateless address mapping method. As Local Prefix is chosen from the prefix assigned to the site, it fits to site level usage. Practically, it can work up to entreprise scale, since the behavior is almost same as IPv4 NAT. The preferable usage of Local Prefix is as follows. o Small to Middle scale, Home to Enterprise, translation. o Middium level redundant translation service (by load balancing). o Provide the access from IPv6 client to global IPv4 server. Miyata Expires April 17, 2009 [Page 13] Internet-Draft PREFIX64 Comparison October 2008 A) Place the gateway at the edge of IPv6 stub site. (IPv6 stub network) (IPv4 global network) [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server] | +------------[IPv4 Server] Figure 3.2.4 IPv6 to global IPv4 (Client Side Gateway) B) Place the gateway in front of IPv4 server. (IPv6 global network) (IPv4 global network) [IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server] | [IPv6 Client]---------+ Figure 3.2.5 IPv6 to global IPv4 (Server Side Gateway) o Provide the access from IPv6 client to private IPv4 server. Place the gateway in front of IPv4 private network. (IPv6 global network) (IPv4 private network) [IPv6 Client]---------+------>------[Gateway]---->---[IPv4 Server] | [IPv6 Client]---------+ Figure 3.2.6 IPv6 to private IPv4 (Server Side Gateway) o Provide the access from IPv4 client to IPv6 server (by static 1:1 mapping). Place the gateway at the edge of IPv4 stub site. (IPv6 global network) (IPv4 private network) [IPv6 Server]---------+------<------[Gateway]---<----[IPv4 Client] | [IPv6 Server]---------+ Figure 3.2.7 Private IPv4 to IPv6 (Client Side Gateway) 3.3. Well-Known Prefix In contrast to IVI and Local Prefix, Well-known prefix is the fixed IPv6 prefix assigned to represent the IPv4 address. For example, SIIT [RFC2765] is designed to use the well-known prefix namely IPv4- mapped prefix (::ffff:0:0/96). The IPv4 address should be placed on the last 4 octets. Some other kinds of Well-Known Prefix would be Miyata Expires April 17, 2009 [Page 14] Internet-Draft PREFIX64 Comparison October 2008 considered. But both of them should have the same charactaristcs, namely Fixed and Common prefix. In this section, the Well-Known Prefix does not specifically mean IPv4-mapped prefix. Rather, it means the prefix, which has Fixed and Common charactaristics, assigned to represent the IPv4 address on IPv6 address format generally. As SIIT [RFC2765] provides the stateless translation using Well-Known prefix, it may be possible to provide the stateless translation somehow. But, in this document, we have an assumption that Well- Known Prefix is used to represent IPv4 address, no more no less. In other words, we have an assumption to use Well-known Prefix instead of Local Prefix. 3.3.1. Benefits Address Mapping: The Well-Known Prefix allows automatic IPv6 address mapping to IPv4. One Well-Known Prefix can represent entire IPv4 network address. But for the reverse direction, the translator needs to search some kinds of address mapping information. Address Selection: The Well-Known Prefix would be chosen from other address range than unicast address. Therefore the IPv6 node naturally choose native IPv6 address by longest match manner. The DNS re-writing function priors the normal IPv6 address to synthetic address. Therefore, when the client uses DNS to resolve the address, it can prior native connection naturally. To put less priority to synthetic address explicitly, the address selection policy should be modified. In contrast to IDENT bit in Local Prefix, the longest match manner can be handle this properly. Synthetic Address Detection: When using Well-Known Prefix, it is easy to distinguish from other unicast address. IPv4 Address Efficiency: Miyata Expires April 17, 2009 [Page 15] Internet-Draft PREFIX64 Comparison October 2008 Basically, to map the IPv6 address to IPv4 address, it does not require IPv4 address. Only when static 1:1 address mapping is configured, IPv4 addresses are required. But, even in this case, the mapping is done for each address. It will not cause the "Dead Stock" IPv4 address. Routing: Since the nodes does not need additional address, no additional IPv6 routing information is required, with the exception of the Well-Known Prefixes. The Well-Known Prefix must not be restributed to other IPv6 routing realm. 3.3.2. Shortcomes Access to IPv4 Private Address: Since the Well-Known Prefix is globally unique and common prefix, it can represent one private address realm per private address. So, if the multiple organizations are using the same private address, (e.g., 10.0.0.0/8), each of them would be represented as [Well-Known Prefix]+[10.x.y.z]. It is impossible to distinguish them. If the IPv6 network is small stub network and it is attached to one IPv4 private address, it can work well. The typical example of this is Home Network. Multiple Gateway: If the Gateway maintain the address mapping information dynamically, like NAPT style. It is difficult to use Multiple Gateway, without synchronizing the state. If the addresses are mapped in static 1:1 style, and the address mapping information and Local Prefix are shared amang the gateways, it is possible. Scalability: When using Well-Known Prefix, it is impossible to represent each IPv4 private address realm differently. So, Well-Known Prefix does not work well, when it is used in the gateway attached to multiple organizations using same IPv4 private address. Moreover, [Well-known Prefix] + [Private IPv4 Address] has different meaning in each routing realm. So, the routing information of Well-Known Miyata Expires April 17, 2009 [Page 16] Internet-Draft PREFIX64 Comparison October 2008 Prefix should not be re-distributed to other routign realm. Also, with Well-Known Prefix, load balancing function described in [ID-endo] can not be adapted. With above mentioned reasons, Well-Known Prefix is good for small scale solution. Others: As described in Scalability, Well-Known prefix can provide less control to the administrator. Therefore, it can provide easy configuration and less flexibility. 3.3.3. Configuration Host: To use DNS re-writing function, the IPv6 node should be configured to send DNS query to appropriate DNS server somehow. But it is same as ordinally DNS configuration. Therefore, no special configuration is required for both IPv6 and IPv4 hosts. Router: No special configuration is required of routers. Gateway: Each gateway needs to be configured Well-Known Prefix, but it may be configured by default. Also, it should be configured to advertise the Well-Known Prefix on IPv6 network. The configuration should be done [once] * [number of gateway] times. If the addresses are mapped in static 1:1 style, each mapping must be configured inappropreate gateway. The configuration should be done [number of mapped address] * [number of shareing gateway] times. And it should be configured to advertise the route for IPv4 addresses assigned to IPv6 nodes if required. The configuration should be done [number of Aggregated IPv4 Prefix] times. DNS: The DNS re-writing funtion must be configured the Well-Known Prefix to synthesize the AAAA address for IPv6 node, but it may be configured by default. The configuration should be done [number of Local Prefix] times. Miyata Expires April 17, 2009 [Page 17] Internet-Draft PREFIX64 Comparison October 2008 The DNS server, which is in charge of the IPv6 nodes, needs to be configured each IPv4 address assigned to them if reqruired. The configuration should be done [number of mapped IPv4 address] times. 3.3.4. Applicability As Well-Known Prefix is used with some address mapping information, both dynamic and static, it is less scalable than stateless address mapping method. The preferable usage of Well-Known Prefix is as follows. o Small scale translation (Home Network). o Less redundant translation service (no load balancing). o In stub IPv6 network. o Provide the access from IPv6 client in stub IPv6 network to global IPv4 server. Place the gateway at the edge of IPv6 stub site. (IPv6 stub network) (IPv4 global network) [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server] | +------------[IPv4 Server] Figure 3.3.1 IPv6 to global IPv4 (Client Side Gateway) o Provide the access from IPv6 client in stub IPv6 network to private/global IPv4 server (IPv6 stub network attached to a private IPv4 network). Place the gateway at the edge of IPv6 stub network. (IPv6 stub network) (IPv4 private network) [IPv6 Client]---->---[Gateway]----->----+------------[IPv4 Server] | [NAT] | +------------[IPv4 Server] (IPv4 global network) Figure 3.3.2 IPv6 to global IPv4 (Client Side Gateway) Miyata Expires April 17, 2009 [Page 18] Internet-Draft PREFIX64 Comparison October 2008 4. Conclusion The PREFIX64 is very important part of traslation technology. We need to discuss about this more deeply. This documetns attempt to clarify pros and cons of each proposed idea. So, is is the start point of the discussion. There are some mission aspect and information already discussed. If the reader found some of them, please send them to improve this document and conclude the PREFIX64 discusssion smoothly. As a preliminary conclusion. The Well-Known Prefix is not preferable idea. Actually, it has some benefits. But the utilization scenario is very limited and it must be carefully handled. The Local Prefix would cover small to middium scale usage. And it allows flexible usage. This idea is only one solution to achive the scenario "IPv6 network to IPv4 private network". So, many administrator would prefer this idea. The IVI Prefix allows large scale usage by stateless address mapping. THE LIR requires the administrator to have the right to control the prefix later than 32 bit. So, only the ISP or higher level user can adminsitrate this prefix. And it allows to map IPv4 address to IPv6 address. The smallest granularity is /24(256). There will be some argument if it is reasonable in current situation. The bright side of this argument may be the IPv4 address recycle system. If it works well, /24 address block could be used. If only the fragmented address space is recycled, the IPv4 address can not be aggragated. It result the increase of routing table in IPv6 network. Miyata Expires April 17, 2009 [Page 19] Internet-Draft PREFIX64 Comparison October 2008 5. IANA Considerations After the discussion of IDENT bit, a new value under IANA OUI may be requested to indicate the translator existense. Miyata Expires April 17, 2009 [Page 20] Internet-Draft PREFIX64 Comparison October 2008 6. Security Considerations TBD Miyata Expires April 17, 2009 [Page 21] Internet-Draft PREFIX64 Comparison October 2008 7. Acknowledgement To write this document, some essense are come from following documets. o [ID-bagnulo] o [ID-baker] o [ID-miyata] o [ID-endo] Miyata Expires April 17, 2009 [Page 22] Internet-Draft PREFIX64 Comparison October 2008 8. References 8.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. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transpot Relay Translator", RFC 3142, June 2001. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 8.2. Informative References [ID-bagnulo] Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Work in Progress draft-bagnulo-behave-nat64-01, September 2008. [ID-baker] Li, X., Bao, C., and F. Baker, "IVI Update to SIIT adn NAT-PT", Work in Progress draft-baker-behave-ivi-01, October 2008. [ID-endo] Endo, M. and H. Miyata, "Translator Friendly DNS Proxy", Work in Progress draft-endo-v6ops-dnsproxy-01, October 2008. [ID-miyata] Miyata, H. and M. Endo, "Simplified Network Address Translation - Protocol Translation", Work in Progress draft-miyata-v6ops-snatpt-02, September 2008. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. Miyata Expires April 17, 2009 [Page 23] Internet-Draft PREFIX64 Comparison October 2008 Author's Address Hiroshi Miyata Yokogawa Electric Corporation 2-9-32 Nakacho Musashino-shi, Tokyo 180-8750 JAPAN Email: h.miyata@jp.yokogawa.com Miyata Expires April 17, 2009 [Page 24] Internet-Draft PREFIX64 Comparison October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Miyata Expires April 17, 2009 [Page 25]