[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wang-behave-nat64-load-balancer) 00 01 02 03

Network Working Group                                      D. Zhang, Ed.
Internet-Draft                                                X. Xu, Ed.
Intended status: Informational               Huawei Technologies Co.,Ltd
Expires: August 5, 2011                                M. Boucadair, Ed.
                                                          France Telecom
                                                                 X. Wang
                                             Huawei Technologies Co.,Ltd
                                                                 Y. Wang
                                                                   CNNIC
                                                                C. Byrne
                                                            T-Mobile USA
                                                                D. Zhang
                                                         Huawei Symantec
                                                       February 01, 2011


                 Considerations on NAT64 Load-Balancing
               draft-zhang-behave-nat64-load-balancing-01

Abstract

   This document investigates several load-balancing approaches for
   NAT64 devices and analyses the advantages and disadvantages of
   various prefix selection policies.  Both stateless and stateful NAT64
   schemes are considered in this document.

Requirements Language

   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].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 5, 2011.



Zhang, et al.            Expires August 5, 2011                 [Page 1]


Internet-Draft            NAT64 Load Balancing             February 2011


Copyright Notice

   Copyright (c) 2011 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Reminder on the Load Balancing Objectives  . . . . . . . . . .  3
     3.1.  Inbound Load Balancing . . . . . . . . . . . . . . . . . .  4
     3.2.  Outbound Load Balancing  . . . . . . . . . . . . . . . . .  5
   4.  Basic Load Balancing Considerations  . . . . . . . . . . . . .  5
   5.  Stateless NAT64  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Anycast-based Mode . . . . . . . . . . . . . . . . . . . .  6
     5.2.  DHCPv6-based Mode  . . . . . . . . . . . . . . . . . . . .  7
     5.3.  NAT64 Farm . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Anycast-based Mode . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Prefix64 Selection Policy  . . . . . . . . . . . . . . . .  8
       6.2.1.  Source-Based Prefix Selection Policy . . . . . . . . .  9
       6.2.2.  Destination-Based Prefix Selection Policy  . . . . . .  9
       6.2.3.  Round-Robin Prefix Selection Policy  . . . . . . . . . 10
       6.2.4.  Dynamic Prefix Selection Policy  . . . . . . . . . . . 11
     6.3.  Options for Implementing Load-balancers  . . . . . . . . . 11
       6.3.1.  DNS64 Servers  . . . . . . . . . . . . . . . . . . . . 11
       6.3.2.  Prefix64 Assigners . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15







Zhang, et al.            Expires August 5, 2011                 [Page 2]


Internet-Draft            NAT64 Load Balancing             February 2011


1.  Introduction

   NAT64 devices [I-D.ietf-behave-v6v4-xlate-stateful] are facilities
   deployed on the boundaries between IPv6 and IPv4 networks to
   facilitate the communication between IPv6-only clients and IPv4
   servers.

   This document proposes several load-balancing approaches for NAT64
   devices, which can be utilized in the delivery of highly available
   services, and compares the advantages and disadvantages of various
   prefix selection policies.

   The issues with failover and redundancy are outside the scope of this
   document.  An in depth analysis of those issues is elaborated in
   [I-D.xu-behave-stateful-nat-standby].


2.  Terminology

   This document makes use of the terms defined in
   [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-dns64] and
   [RFC6052].  Below are provided the terms specific to this document:

   o  Prefix64: an IPv6 prefix used for synthesizing IPv6 addresses
      representing IPv4 hosts in the IPv6 realm.  See [RFC6052] for more
      details on how IPv4-embedded IPv6 addresses are built.

   o  NAT64-enabled device (or NAT64 device for short): is a device
      which embeds a NAT64 function as defined in
      [I-D.ietf-behave-v6v4-xlate-stateful].

   o  A load-balancer is a facility which can select a NAT64 device from
      a set of deployed devices for a given IPv6-only client according
      to the pre-specified policy.  Typically, a load-balancer
      provisions a client with an IPv6 address of the IPv4-only server
      that the client is going to access.  Prefix64 is elaborately
      selected by the load-balancer so that the corresponding NAT64
      device can intercept the packets between the above communicating
      parties and correctly process them.


3.  Reminder on the Load Balancing Objectives

   Load balancing is a technique used by network operators (including
   service providers, enterprise networks, etc.) to distribute the load
   among several ingress/egress points, several paths, several
   topologies, etc.




Zhang, et al.            Expires August 5, 2011                 [Page 3]


Internet-Draft            NAT64 Load Balancing             February 2011


   In the context of IPv4-IPv6 interconnection, load balancing is mainly
   motivated by the needs listed below:

   o  to optimize the resources usage of deployed NAT64 devices (e.g.,
      several ingress/egress NAT64 devices);

   o  to avoid congesting a single NAT64 device while other free
      resources are still available;

   o  to optimize IPv6-IPv4 interconnection costs especially when
      several NAT64 providers are involved.

   Techniques to balance the load among a set of NAT64 devices can be
   achieved on a load-balancer managing a farm of NAT64 devices, on a
   single NAT64 device to select the appropriate outbound interface, or
   it can be implicitly achieved owing to dedicated tweaking operations
   (e.g., use of anycast-based service, use of distinct Prefix64, etc.).
   Note that considerations to balance the traffic between several
   outbound interfaces of a NAT64 device are out of scope of this
   document.

   Various types of load balancing can be considered as defined in the
   following sub-sections.

3.1.  Inbound Load Balancing

   Inbound load balancing means that incoming traffic (i.e., the traffic
   received from an IPv4-only host) is distributed among a set of NAT64
   devices located at the boundary of the IPv4 realm and the IPv6 one.

   In a stateful NAT64 case, inbound load balancing cannot be explicitly
   configured because IPv4-only clients can not initiate sessions to an
   IPv6-only server (except for IPv6-only hosts which pre-installed
   static entries in the NAT64 using PCP [I-D.ietf-pcp-base] for
   instance).

   In a stateless NAT64 case, inbound load balancing can be achieved by
   configuring distinct IPv4 address pools on each stateless NAT64
   device (or these pools are to be configured with distinct routing
   metrics in each NAT64 device).  This practice may lead to asymmetric
   paths (i.e., distinct NAT64 devices will handle the outgoing and the
   inbound packets) if the same NSP (Network Specific Prefix, [RFC6052])
   is provisioned on those NAT64 devices.  This can be seen as an issue
   for some operators because the legal stored data and activity logs
   can be increased.  If downstream and upstream paths have similar
   characteristics (e.g., one-way delay, one-way delay variation,
   throughput), the path asymmetry is not an issue from a service
   perspective.



Zhang, et al.            Expires August 5, 2011                 [Page 4]


Internet-Draft            NAT64 Load Balancing             February 2011


      [[Note: As an alternative to address this problem, a load balancer
      needs to be deployed on each side of the NAT64 devices.  The
      balancers need to know the policies of each other so as to work in
      a cooperative way.  Refer to Section 6.2 for more discussion.]]

3.2.  Outbound Load Balancing

   Outbound load balancing means the effort of distributing outgoing
   traffic (i.e., the traffic issued by IPv6-only hosts) among a set of
   NAT64 devices.

   Only this flavor of load balancing is elaborated in the remainder of
   this document.


4.  Basic Load Balancing Considerations

   In practice, it is important to guarantee the outgoing traffic and
   the associated incoming traffic is stuck to a same stateful NAT64
   device, so that the NAT64 device can get essential knowledge to
   correctly process the incoming packets.  That is, if a stateful NAT64
   device processes a request from an IPv6 client to an IPv4 server, it
   MUST be able to intercept and process the correspondent reply from
   the server.  To achieve this, distinct external IPv4 addresses SHOULD
   be configured on each stateful NAT64 device.  Otherwise, if the same
   IPv4 address pool is provisioned on two distinct NAT64 devices (e.g.,
   NAT64-A and NAT64-B) and since the routing paths may not be
   symmetric, outbound packets may be intercepted by NAT64-A while
   inbound packets may be received by NAT64-B.  NAT64-B will reject the
   packets it received because no state to process these packets was
   instantiated beforehand, and thus the communication will fail.

   The load balancing SHOULD NOT be solely done based on the traffic
   load distribution but SHOULD persevere the assignment of the same
   external IPv4 address for all active sessions initiated by an IPv6-
   only host.  The criteria for distributing customers among a set of
   NAT64 devices may be implemented during the IPv6 configuration phase
   of a IPv6-only host or during the processing of actual traffic issued
   by that host.

   In the circumstances where the static mapping entries of an IPv6-only
   client are pre-installed in a given stateful NAT64 device, the
   enforced load-balancing technique SHOULD "redirect" the traffic from
   the client to the NAT64-device where its static mappings are pre-
   installed.

   [[Note: Some dynamic protocols such as PCP may include manes to
   detect the unavailability of a NAT64 and to re-install the mappings



Zhang, et al.            Expires August 5, 2011                 [Page 5]


Internet-Draft            NAT64 Load Balancing             February 2011


   in the new discovered NAT64.  But, for the manually configured
   mappings, the issue is still there.]]

   From the operator's perspective, a load balancing solution SHOULD be
   deterministic, that is, that the actual traffic distribution should
   be strictly compliant with what is expected by the system manager.
   Furthermore, the operations of distributing the load among multiple
   NAT64 devices SHOULD be covered from end-users.  This means that end-
   users should not be aware of the presence of multiple NAT64 devices
   in the core network and the selection of the appropriate NAT64 device
   should not assume any intervention by the customer/host.

   When implementing load balancing, load balancing should not lead to
   (severe) QoS degradation between potential paths.  Note that the
   perceived quality may not only depend on the load balancing technique
   to distribute the traffic among available path/nodes but it is
   closely related to the underlying topology (i.e., location of the
   NAT64 devices, routing metrics configuration, etc.).

   An efficient load balancing system SHOULD NOT redirect the traffic to
   a congested NAT64 device while other NAT64 resources are available.
   Load indicators (i.e., the data reflecting the load imposed on NAT64
   devices) may be disseminated to drive the process of selecting a
   NAT64 device to handle an ongoing IPv6 packet.  These indicators may
   be based on (almost) real-time measurement tools or based on a
   traffic logic configured on the load-balancer (e.g., a NAT64 device
   can handle N IPv6-only hosts).


5.  Stateless NAT64

   According to [RFC6052], IPv4-Translated and IPv4-Converted IPv6
   addresses SHOULD use the same Network Specific Prefix (NSP).  To
   distribute the traffic among a set of stateless NAT64 devices, the
   alternatives described hereafter can be envisaged.  For the anycast-
   based mode the same Prefix64 is used while for the remaining options,
   specific Prefix64s are used.

5.1.  Anycast-based Mode

   The same IPv6 NSP is provisioned to all stateless NAT64 devices; IPv6
   hosts are distributed natively among several stateless NAT64 devices.
   This means that the closest (from a routing perspective) stateless
   NAT64 device will be used to process IPv6 (resp. IPv4) packets
   destined to an IPv4 (resp. IPv6) destination.

   The efficiency of this mode largely depends on the underlying
   topology (e.g., location of NAT64 devices) and routing engineering



Zhang, et al.            Expires August 5, 2011                 [Page 6]


Internet-Draft            NAT64 Load Balancing             February 2011


   policies.  Moreover, a stateless NAT64 device may be overloaded if
   the routing is not appropriately tuned and/or if the NAT64 devices
   are not appropriately dimensioned.

   The introduction or the removal of NAT64 device(s) can be achieved
   without modifying the configuration of DHCPv6 servers.  During
   failure events of a NAT64 system, other NAT64 devices can handle the
   traffic without any intervention.

5.2.  DHCPv6-based Mode

   To implement this mode, each stateless NAT64 device is configured
   with a dedicated NSP.  During the IPv6 prefix assignment phase,
   requesting IPv6 hosts are provided with IPv4-Translated IPv6 prefix
   using the NSP of the NAT64 device that will be used to handle traffic
   issued from those hosts and destined to an IPv4 host.

   If DHCPv6 is used for the provisioning of IPv6 prefixes, DHCPv6
   servers SHOULD be provided with the number of customers to be
   serviced per dedicated NSP (i.e., an NSP prefix identifies a
   stateless NAT64 device).  Dynamic load information (based on real
   time monitoring) MAY be provided to the DHCPv6 to drive the process
   of IPv6 prefix assignment and for better utilization of available
   NAT64 resources.  Furthermore, and for routing optimization purposes
   and for service stability purpose (e.g., use the same NAT64 device
   hosting PCP-instructed port forwarding entries), other topological
   information such as Line-ID SHOULD be used to tag the customers that
   should be serviced by each NAT64 device.

5.3.  NAT64 Farm

   An additional scheme would be the deployment of a farm of NAT64
   devices with a load-balancer which is responsible for redirecting the
   traffic to the appropriate NAT64 instance.  Unlike stateful NAT64,
   both IPv4 and IPv6 flows can be load balanced.

   In this scenario, the same NSP SHOULD be used for all NAT64 devices
   belonging to the same farm.

   Techniques to distribute the load among the NAT64 devices of the farm
   are similar to load-balancing techniques among several outbound
   interfaces of the same NAT64 system.


6.  Stateful NAT64

   Tow variant of the load balancing techniques are elaborated
   hereafter.  Unlike the first mode, anycast-based, the second category



Zhang, et al.            Expires August 5, 2011                 [Page 7]


Internet-Draft            NAT64 Load Balancing             February 2011


   requires Prefix64 selection to achieve load balancing.  More details
   are provided below.

      [[Note: Add a comparison between anaycast-based approach and the
      ones based on the Prefix64 selection.]]

6.1.  Anycast-based Mode

   This mode assumes that the same IPv6 prefix (i.e., NSP or WKP, see
   [RFC6052]) is provisioned to all deployed stateful NAT64 devices.
   DNS64 function is provisioned with that prefix used for synthesizing
   AAAA records.

   As stated in Section 4, distinct IPv4 address pools are configured to
   each NAT64 device.  This ensures path symmetry; which means that the
   same NAT64 device will be used for handling both outbound and inbound
   packets exchanged in a same stateful conversation between two hosts.

   The distribution of the traffic among deployed NAT64 devices is
   natively achieved relying on the underlying routing configuration.
   Off-line traffic engineering tools can be used to appropriately tweak
   the routing metrics so as to allow for acceptable traffic
   distribution.

   The same NAT64 device SHOULD be used to handle all the packets issued
   by a given IPv6 host so that the same external IPv4 address is used
   to represent that host in the IPv4 realm.  This means that
   oscillation phenomena induced by underlying routing MUST be avoided.
   By oscillation it is meant that the traffic customer is balanced
   between two NAT64 devices.  The routing oscillation can be avoided
   owing to (off-line/on-line) traffic engineering techniques to select
   the appropriate location of the NAT64 devices in the network, the
   setting of underlying routing weights, establishment of explicit MPLS
   LSPs, etc.

6.2.  Prefix64 Selection Policy

   It is RECOMMENDED that the functionality of load balancers should be
   integrated into dedicated servers.  Therefore, load-balancing can be
   transparent for IPv6-only hosts.  The design options of load
   balancers are discussed in Section 6.3.

   The following sub-sections elaborate on various modes for the prefix
   selection.







Zhang, et al.            Expires August 5, 2011                 [Page 8]


Internet-Draft            NAT64 Load Balancing             February 2011


6.2.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 IPv6-only
   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-only server if the IPv6 address
   of the client is odd, and Prefix64-B otherwise.

6.2.1.1.  Pros

   +  It is simple and has enough entropy to ensure reasonable load
      balancing across different NAT64 devices. 2.

   +  The users are consistently assigned to the same NAT64 device for
      every outbound session.  This is important because some
      applications identify a unique user across multiple transactions
      using the source IP address; examples include FTP and SSL VPNs.
      In addition, it is easier for a network management system (NMS) to
      monitor and manage the activities of a user.  For instance, a NMS
      can collect the information about number of the concurrent
      sessions initiated by a user from a single NAT64 device.  However,
      when using other policies, a user is not stuck to a NAT64 device,
      and thus NMS may have to collect such information from multiple
      NAT64 devices.

6.2.1.2.  Cons

   -  The efficiency of this procedure depends on the selection criteria
      and may not be deterministic in some cases where the traffic may
      be redirected to a congested NAT64 device.

6.2.2.  Destination-Based Prefix Selection Policy

   A destination-based prefix selection policy requires a load-balancer
   to choose Prefix64s according to the IP addresses of the IPv4
   targets.  For instance, when using a destination-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 IPv4
   address of the server is odd, and prefix64-B otherwise.  In practice,
   this type of policy can have lots of variations.  For instance, when
   a DNS server is utilized as a load balancer, the server can select a
   prefix64 according to the hash value of the FQDN of the target
   server.







Zhang, et al.            Expires August 5, 2011                 [Page 9]


Internet-Draft            NAT64 Load Balancing             February 2011


6.2.2.1.  Pros

   +  It is simple to implement;

6.2.2.2.  Cons

   -  A user accessing multiple IPv4 servers may be represented by
      multiple public IPv4 addresses since its traffic may be processed
      by different NAT64 systems.  This will cause authentication
      problems in the applications (e.g., FTP and SSL VPNs) which take
      advantage of the source IP addresses to identify users across
      different sessions. 2.

   -  A user can not be redirected to the NAT64 device where it has
      instructed its port forwarding entries; 3.

   -  Since there are more users than the servers providing contents,
      there is not enough entropy to ensure good load balancing.  The
      NAT64 device that services a popular web-site will have to
      undertake much traffic.  It is possible to define some strategies
      to make major sites evenly assigned to different NAT64s, e.g.-
      Google to NAT64-A, Facebook to NAT64-B, However, this solution can
      be onerous and requires heavy human involvement.

6.2.3.  Round-Robin Prefix Selection Policy

   A round-robin prefix selection policy allows a load-balancer to use
   various Prefix64s circularly in different requesting sessions.  For
   instance, in the above example, the load-balancer can choose
   Prefix64-A in the first requesting session, choose Prefix64-B in the
   second, choose Prefix64-A in the third, choose Prefix64-B in the
   fourth, and so on.

6.2.3.1.  Pros

   +  Ensures reasonable distribution among a set of NAT64 devices.

6.2.3.2.  Cons

   -  A given IPv6-only hosts may be redirected to distinct NAT64
      devices.  Therefore, distinct IPv4 address may be used to
      represent the IPv6-only host in the IPv4 realm;

   -  A user can not be redirected to the NAT64 device where it has
      instructed its port forwarding entries;






Zhang, et al.            Expires August 5, 2011                [Page 10]


Internet-Draft            NAT64 Load Balancing             February 2011


   -  Requires a load balancer (e.g., a DNS64 or a DHCP server) to keep
      track of the assignments.

6.2.4.  Dynamic Prefix Selection Policy

   Although the capability of NAT64 devices can be considered as a
   factor in the designing of the above three types of policies, they
   are still static and not able to be adjusted according the load
   changes of NAT64 devices in a timely fashion.  If we intend to enable
   a load-balancer to dynamically modify its policies according to
   NAT64s' real-time load changes, a dynamic prefix selection policy is
   necessary.  For instance, a DNS64 system or DHCPv6 can use SNMP to
   collect the information of the overheads (e.g., CPU utilizing rates,
   free memory amounts, concurrent session numbers, and session numbers
   per second) imposed on different NAT64-based devices.  Based on such
   information, the load-balancer can distribute the loads on different
   NAT64 devices in a more reasonable way.

6.2.4.1.  Pros

   +  This type of policy can effectively avoid the unbalanced
      distribution of overheads on different NAT64 devices.

6.2.4.2.  Cons

   -  Such a policy may introduce additional communication and
      management complexities to a NAT64 device.  The complexity depends
      on the means used to disseminate the NAT64 load.

6.3.  Options for Implementing Load-balancers

   In practice, the functionality of a load-balancer can be performed
   by, e.g.- a DNS64 server, a DNS server, a DHCP server, an edge
   router, or even an IPv6 host itself.

6.3.1.  DNS64 Servers

   When collaborating with NAT64 devices, a DNS64 server can be
   solicited by an IPv6-only client to initiate communications to an
   IPv4-only server identified by a FQDN.

   Let us assume there is an IPv6-only client connected to an IPv6
   network which attempts to communicate to an IPv4-only server.  For
   the purpose of load balancing, the DNS64 server needs to select a
   Prefix64 based on one of the prefix selection policies defined in
   Section 6.2 and use it when synthesizing AAAA RRs.  Using the
   synthesized IPv6 address, the IPv6-only client will take advantage of
   the NAT64 associated with the Prefix64 to communicate with the IPv4-



Zhang, et al.            Expires August 5, 2011                [Page 11]


Internet-Draft            NAT64 Load Balancing             February 2011


   only server.

   When DNS64 is used as a means to load balance the hosts among a group
   of NAT, DNS64 SHOULD be able to assign the same NAT64 to the same
   hosts.  Means to identify the host SHOULD be supported.  This is not
   natively supported by DNS servers.

   A drawback of this mode is that for traffic which does not require a
   DNS resolution, the packets may flow using a distinct NAT device, and
   therefore use a distinct external IP address.

6.3.2.  Prefix64 Assigners

   [I-D.korhonen-behave-nat64-learn-analysis] analyses various solutions
   for a host in an IPv6-only network to obtain the Prefix64 of a NAT64
   device.  With the Prefix64, the hosts can synthesize an appropriate
   IPv6 address which can route packets to the translator.  In the
   designing of load balancers for NAT64 devices, these approaches are
   worthwhile to consider.

6.3.2.1.  DNS64 Servers

   In [I-D.korhonen-behave-nat64-learn-analysis], a NAPTR RR to
   represent NAT64's Prefix64 is analysed as part of the candidate
   solutions.  When using DNS servers to act as load balancers for NAT64
   devices, multiple NAPTR RRs need to be added the zone file.  Every
   NAPT RR consists of a Prefix64.  Upon receiving a NAPTR query, the
   DNS server replies the requester with a NAPTR RR according to a pre-
   specified selection policy.  Note that the destination-based prefix
   selection policy is not applicable in this case because the DNS
   server may lack the knowledge of the IP address of the queried IPv4
   host.

6.3.2.2.  DHCPv6 Servers

   It is mentioned in [I-D.korhonen-behave-nat64-learn-analysis] that a
   DHCPv6 server can be used to allocate Prefix64s for hosts, and so a
   DHCP server has a potential to act as a load balancer for NAT64
   devices.  Similar with the solution proposed in Section 6.3.2.1, it
   is difficult for a DHCP server to identify the IP addresses of the
   IPv4 hosts which its clients intend to communicate with.  Therefore,
   only the source-based policy, the round-robin policy, or the dynamic
   policy can be used in this approach.

   Also, a DHCPv6 server can be adopted to allocate different DNS64
   servers for its users in various standard DHCPv6 host configuration
   processes according to certain selection polices.  Unlike the DNS64
   servers discussed in Section 6.3.1, in this case a DNS64 server needs



Zhang, et al.            Expires August 5, 2011                [Page 12]


Internet-Draft            NAT64 Load Balancing             February 2011


   to only synthesize AAAA records using a single Prefix64.

   The load of NAT devices may be provided to DHCP servers to assist the
   selection of the DNS64 to be used for new connecting hosts.

6.3.2.3.  Default Gateways

   [I-D.korhonen-behave-nat64-learn-analysis] also discusses the
   possibility of using Router Advertisement (RA) messages to transfer
   Prefix64s for IPv6 users.  If the edge router is attached to only one
   multicast link, no prefix selection policy defined in Section 6.2 can
   be used.  If the edge router is attached to multiple multicast links,
   the source-based policy, the round-robin policy or the dynamic policy
   can be used.  Because at this phase it is difficult for an edge
   router to identify the IP addresses of the IPv4 hosts which the IPv6
   hosts will communicate with, the destination-based prefix selection
   policy is unfeasible.

6.3.2.4.  IPv6 Clients

   It is possible for an IPv6 host to learn multiple Prefix64s through
   the approaches defined in [I-D.korhonen-behave-nat64-learn-analysis]
   and then select one based on a certain prefix selection policy.  Such
   a policy can be the destination-based policy, the source-based policy
   (only one prefix64 is used), the round-robin policy or the dynamic
   policy.

   This solution is not deterministic and can lead to congesting a given
   NAT64 device.


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   As mentioned previously, all the traffic between an IPv6 host and an
   IPv4 host should be intercepted and processed by a same NAT64 device.
   However, when using certain policies (e.g., the destination-based
   prefix selection policy and the Round-Robin prefix selection policy),
   this requirement cannot be fulfilled.  The traffic of a user will be
   distributed to different NAT64 devices.  Under such a circumstance,
   it may be difficult for network management systems to collect



Zhang, et al.            Expires August 5, 2011                [Page 13]


Internet-Draft            NAT64 Load Balancing             February 2011


   information from different NAT64 devices in order to monitor users'
   behavior in a real in time fashion.  In addition, it can be difficult
   for intrusion detection/prevision systems to combine the operations
   of a user so as to reason whether she is trying to perform a multi-
   step attack.

   Another security concern is load balancers.  Because load balancers
   play an important role in distributing traffic to different NAT64
   devices, the communication between users and load balancers should be
   secured.  Otherwise, attackers may disturb load balancing and carry
   out DDOS attacks by modifying the packets sent from load balancers.


9.  References

9.1.  Normative References

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to IPv4 Servers",
              draft-ietf-behave-dns64-11 (work in progress),
              October 2010.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

9.2.  Informative References

   [I-D.ietf-pcp-base]
              Wing, D., "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-03 (work in progress), January 2011.

   [I-D.korhonen-behave-nat64-learn-analysis]
              Korhonen, J. and T. Savolainen, "Analysis of solution
              proposals for hosts to learn NAT64 prefix",
              draft-korhonen-behave-nat64-learn-analysis-01 (work in



Zhang, et al.            Expires August 5, 2011                [Page 14]


Internet-Draft            NAT64 Load Balancing             February 2011


              progress), January 2011.

   [I-D.xu-behave-stateful-nat-standby]
              Xu, X., Boucadair, M., Lee, Y., and G. Chen, "Redundancy
              Requirements and Framework for Stateful Network Address
              Translators (NAT)",
              draft-xu-behave-stateful-nat-standby-06 (work in
              progress), October 2010.


Authors' Addresses

   Dacheng Zhang (editor)
   Huawei Technologies Co.,Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing  100085
   P.R. China

   Email: zhangdacheng@huawei.com


   Xiaohu Xu (editor)
   Huawei Technologies Co.,Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing  100085
   P.R. China

   Email: xuxh@huawei.com


   Mohamed Boucadair (editor)
   France Telecom
   Rennes
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Xuewei Wang
   Huawei Technologies Co.,Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District, Beijing  100085
   P.R. China

   Email: wangxuewei@huawei.com






Zhang, et al.            Expires August 5, 2011                [Page 15]


Internet-Draft            NAT64 Load Balancing             February 2011


   Yan Wang
   CNNIC
   No.4 South 4th Street,
   Beijing, Zhongguancun  100190
   P. R. China

   Email: wangyan-lab@cnnic.cn


   Cameron Byrne
   T-Mobile USA
   3617 131st Ave SE
   Bellevue,   WA 98006
   US

   Email: cameron.byrne@t-mobile.com


   Dong Zhang
   Huawei Symantec
   KuiKe Building, No.9 Xinxi Rd.,
   Beijing, Hai-Dian District  100085
   P. R. China

   Email: zhangdong_rh@huaweisymantec.com


























Zhang, et al.            Expires August 5, 2011                [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/