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

Versions: 00 01 02 draft-zhang-behave-nat64-load-balancing

 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]


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