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]