Network working group D. Zhang
Internet Draft Huawei
Category: Informational Y. Wang
Expires: February 2011 CNNIC
C. Byrne
T-Mobile USA
X. Wang
Huawei
August 25, 2010
Some Considerations on the Load-Balancer for NAT64
draft-wang-behave-nat64-load-balancer-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Wang Expires February 25, 2011 [Page 1]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
Abstract
[STANDBY] has discussed how to achieve load-balancing among a group
of NAT64 devices. However, it doesn't explore the issues with
achieving load-balancing with load-balancers. In this memo, we
propose our investigation on this topic.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Prefix Selection Policy........................................3
3.1. Source-Based Prefix Selection Policy......................4
3.2. Destination-Based Prefix Selection Policy.................4
3.3. Round-Robin Prefix Selection Policy.......................5
3.4. Dynamic Prefix Selection Policy...........................5
4. Load-balancer Selection........................................6
4.1. DNS64 as Load-balancer....................................6
4.2. Prefix64 Assigner as Load-balancer........................6
4.2.1. DNS Server as Load-balancer..........................7
4.2.2. DHCPv6 Server as Load-balancer.......................7
4.2.3. Default Gateway as Load-balancer.....................7
4.2.4. IPv6 Client as Load-balancer.........................8
5. Change Log.....................................................8
5.1.1. Changes between -00 and -01..........................8
6. References.....................................................8
6.1. Normative References......................................8
6.2. Informative References....................................8
Authors' Addresses...............................................10
Wang Expires February 25, 2011 [Page 2]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
1. Introduction
NAT64 gateways [NAT64] are facilities for data translation between
IP v4 and v6 address namespaces. With the development of the network,
the data transmission volume is increasing rapidly. It is reasonable
to expect that the overheads imposed on a NAT64 gateway system can
be very heavy in many circumstances. Therefore, in order to endow a
good scalability with NAT64 systems, the issues with the designing
of load-balancing mechanisms need to be carefully investigated. In
[STANDBY], some issues with load-balancing mechanism for NAT64 is
discussed, but the issues with load-balancer mechanisms have not
been not been well explored yet. This memo proposes several
candidate load-balancer approaches and compared several different
prefix selection policies. In practice, the load-balancer approaches
can work cooperatively with the address synthesis approaches defined
in [DNS64] and [Learn_Prefix].
2. Terminology
This memo makes use of the terms defined in [NAT64] and [DNS64].
Below are provided terms specific to this document:
Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses for
the IPv4 hosts. See [Format] for more details.
NAT64 System: one NAT64 device or two NAT64 devices in a 1+1
redundancy configuration. At NAT64 system is responsible for the
translation of all packets destine to a given Prefix64. There is a
tight coupling of a NAT64 device, Prefix64, and a set of public IPv4
addresses.
3. Prefix Selection Policy
A load-balancer is a facility which is able to select a NAT64
gateway from a group of gateway based on pre-specified policies and
assign the gateway to provide services for an IPv6 client. Typically,
the load-balancer achieves this by informing the client of an IPv6
address which the client can use to communicate with an IPv4 target.
Particularly, the IPv6 address consists of a prefix64 associated
with the selected gateway.
Assume there are two NAT64 gateways (NAT64-A and NAT64-B) in a NAT64
system which provides protocol translation services between an IPv6
network and the IPv4 Internet. The prefix64s of NAT64-A and NAT64-B
are noted as prefix64-A and prefix64-B respectively. In the IPv6
Wang Expires February 25, 2011 [Page 3]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
network, an IPv6 client needs to contact the load-balancer before it
attempts to communicate with an IPv4 server in the IPv4 Internet.
After receiving a request from a client, the load-balancer responds
with an IPv6 address. If the prefix of the IPv6 address is prefix64-
A, it is indicated that the client will the IPv6 address to
communicate with the IPv4 server under the assistance of NAT64-A.
Similarly, if the prefix of the IPv6 address is prefix64-B, it is
indicated that the client will communicate with the IPv4 server
under the assistance of NAT64-B. In this way, the payloads can be
distributed on different NAT64 gateways according to certain
policies.
In the remainder of this section, four types of prefix selection
policies are introduced. Three of them are static, and one is
dynamic.
3.1. Source-Based Prefix Selection Policy
A source-based prefix selection policy allows a load-balancer to
select prefix64s according to the IPv6 addresses of its clients. For
instance, when using a source-based prefix selection policy, the
load-balancer in the above example can allocate an IPv6 address with
prefix64-A for the IPv4 server if the IPv6 address of the client is
odd, and prefix64-B otherwise.
3.1.1. Pros
1. It is simple and has enough entropy to ensure reasonable load
balancing across different NAT64 gateways.
2. The users are consistently assigned to the same NAT64 for every
transaction. This is important because some application identify
a unique user across multiple transactions using the source IP
address, examples include FTP and SSL VPNs.
3.1.2. Cons
The cons of this policy are left for the future exploration.
3.2. Destination-Based Prefix Selection Policy
A destination-based prefix selection policy is that a load-balancer
chooses prefix64s according to the IP address of the IPv4 server.
For instance, when using a destination-Based Prefix Selection Policy,
the load-balancer in the above example can allocate an IPv6 address
Wang Expires February 25, 2011 [Page 4]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
with prefix64-A for the IPv4 server if the IPv4 address of the
server is odd, and prefix64-B otherwise.
3.2.1. Pros
The pros of this policy are left for the future exploration.
3.2.2. Cons
1. A given user will be represented by multiple public IPv4
addresses since a source will go to multiple NAT64 systems. This
is important because some application identify a unique user
across multiple transactions using the source IP address,
examples include FTP and SSL VPNs.
2. Since there are more viewers than content, there is not enough
entropy to ensure good load balancing. The NAT64 system that
services a major site like Google or Facebook will take too much
traffic. Though we can define some strategies to make major
sites evenly assigned to different NAT64s, e.g., Google to
NAT64-A, Facebook to NAT64-B, but that seems to be static and
manual process.
3.3. Round-Robin Prefix Selection Policy
A round-robin prefix selection policy allows a load-balancer to
choose prefix64s according to the arriving sequence of the
requesting session. In the above example, load-balancer can choose
prefix64-A to the first arriving requesting session, prefix64-B to
the second, prefix64-A to the third, prefix64-B to the fourth, and
so on.
3.3.1. Pros
The pros of this policy are left for the future exploration.
3.3.2. Cons
1 Requires DNS64 or DHCP to have a state table to keep track of
assignments
3.4. Dynamic Prefix Selection Policy
The above three policies are all static prefix selection policies,
though they could pre-evaluate the capabilities of NAT64 boxes based
Wang Expires February 25, 2011 [Page 5]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
on some criterions and allocate the prefix64s according to the
capabilities of their NAT64 boxes, whereas once the evaluation is
finished, these policies are fixed and can't reflect NAT64s' timely
load changes. If we intend to enable load-balancer to change the
prefix64s according to NAT64s' real-time load changes, a dynamic
prefix selection policy is necessary. A DNS64 system or DHCPv6 may
SNMP poll the NAT64 for key performance indicators such as CPU
utilization, free memory, concurrent sessions, and sessions per
second. Based on the relative loading of the systems, the load
balancing mechanism can distribute new load proportionally. This
method perhaps brings a certain amount of system complexities, so
some simplified performance indicators can be considered. This is
the choice of the implementers.
The pros and cons of this policy are left for the future exploration.
4. Load-balancer Selection
A load-balancer can be a DNS64, a DNS server, a DHCP server, an edge
router, or the IPv6 host self. There are some special considerations
with the different load-balancers.
4.1. DNS64 as Load-balancer
DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
from A RRs. Together with NAT64 translator; these two mechanisms
enable an IPv6-only client to initiate communications to an IPv4-
only server using the FQDN of the server. DNS64 synthesizes an AAAA
RR from an A RR containing a real IPv4 address of the responder and
a prefix64.
In the scenario of an IPv6 client in an IPv6 network wants to
initiate a communication with an IPv4 server in the IPv4 Internet,
for load balancing DNS64 decides which prefix64 to be used in the
synthesized response based on one of the prefix selection policies
defined in the section 3. With the synthesized IPv6 address, the
IPv6 client will choose the NAT64 corresponding to the prefix64 of
the IPv6 address is synthesized with to communicate with the IPv4
server.
4.2. Prefix64 Assigner as Load-balancer
[Learn_Prefix] has provided some mechanisms for the hosts in the
IPv6 network to obtain the prefix64 of their NAT64, with the
prefix64 the hosts could synthesize an appropriate IPv6 address that
Wang Expires February 25, 2011 [Page 6]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
will be routed to the translator for the translator to process. In
the context of load balancing for NAT64 boxes, these mechanisms have
some special consideration.
4.2.1. DNS Server as Load-balancer
[Learn_Prefix] has defined a NAPTR RR to represent NAT64's prefix64.
To achieve load balancing for NAT64 boxes, there is a requirement to
add multiple NAPTR RRs to zone file corresponding to each prefix64.
Upon receiving a NAPTR query, DNS server responses to the requestor
one of these NAPTR RRs based on source-based or round-robin or
dynamic prefix selection policy. Because having no knowledge of the
IP address of the queried IPv4 server, destination-based prefix
selection policy is not suitable in this case.
4.2.2. DHCPv6 Server as Load-balancer
Another mechanism for a host to learn the prefix64 of its NAT64
described in [Learn_Prefix] is to make DHCP server to allocate
prefix64 to the hosts. The prefix selection policy can be source-
based, round-robin, or dynamic. Because having no knowledge of the
IP address of the IPv4 server which its client wants to communicate
with, DHCPv6 server can't use destination-based prefix selection
policy.
Alternatively, the DHCPv6 server can allocate a DNS64 server as part
of the standard DHCPv6 host configuration process where the DHCPv6
server provides and DNS server to the client. The DNS64 server in
this instance provides synthesized AAAA records using a unique
prefix64 serviced by a unique NAT64 system. In this way, the DHCPv6
assigns one of many available DNS64 and NAT64 combinations which
serve synthesized AAAA to the host. So, the DHCPv6 pushes one of
many DNS64 servers to the host, and the DNS64 server drives traffic
to one of many NAT64 systems.
4.2.3. Default Gateway as Load-balancer
[Learn_Prefix] also uses Router Advertisement (RA) messages to
transfer the prefix64 to the IPv6 hosts. If the edge router is
attached to only one multicast link, no prefix selection policy
defined in the section 3 can be used. If the edge router is attached
to multiple multicast links, the prefix selection policy can be
source-based or round-robin or dynamic. Due to have no knowledge of
the IP address of the IPv4 server which its host wants to
Wang Expires February 25, 2011 [Page 7]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
communicate with, edge router can't use destination-based prefix
selection policy.
4.2.4. IPv6 Client as Load-balancer
Multiple prefix64s are learnt through the approaches defined in
[learn-prefix], it's up to the IPv6 client to determine which prefix
is used. The prefix selection policy can be destination-based,
source-based (only one prefix64 is used) or round-robin or dynamic.
5. Change Log
5.1.1. Changes between -00 and -01
There were several changes made between the -00 and -01 versions of
this draft:
o Added Cameron Byrne and Dacheng Zhang as co-authors.
o Added some discussions about pros and cons at section 3.1.
o Added a new mechanism at section 4.2.2.
o Add minor mathematical corrections.
6. References
6.1. Normative References
6.2. Informative References
[STANDBY] Xiaohu Xu, Mohamed Boucadair, " Redundancy and Load
Balancing Framework for Stateful Network Address
Translators (NAT)", draft-xu-behave-stateful-nat-
standby-01(work in progress), September, 2009.
[NAT64] Bagnulo, M., Matthews, P., and I. Beijnum, " NAT64:
Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers ", draft-ietf-behave-v6v4-
xlate-stateful-07(work in progress), December, 2009.
[DNS64] M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", draft-ietf-behave-
dns64-05(work in progress), December, 2009.
Wang Expires February 25, 2011 [Page 8]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
[Learn_Prefix] D. Wing, "Learning the IPv6 Prefix of a Network's
IPv6/IPv4 Translator", draft-wing-behave-learn-prefix-
04(work in progress), October, 2009.
[Format] Huitema,C., Bao, C., Bagnulo, M., Boucadair, M., Li,
X., "Framework for IPv4/IPv6 Translation", draft-ietf-
behave-address-format-00(work in progress), August,
2009.
Wang Expires February 25, 2011 [Page 9]
Internet-Draft Some Considerations on the August 2010
Load-Balancer for NAT64
Authors' Addresses
Dacheng Zhang
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: zhangdacheng@huawei.com
Yan Wang
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P. R. China
Phone: +86 10 58813315
Email: wangyan-lab@cnnic.cn
Cameron Byrne
T-Mobile USA
3617 131st Ave SE
Bellevue, WA 98006
Email: cameron.byrne@t-mobile.com
Xuewei Wang
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Phone: +86 10 82836075
Email: wangxuewei@huawei.com
Wang Expires February 25, 2011 [Page 10]