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

Versions: 00

Individual Submission                                    S. Daniel Park
INTERNET-DRAFT                                      SAMSUNG Electronics
Expired: November 2003                                Senthil Sivakumar
Filename:                                            Cisco Systems, Inc
draft-park-scalable-multi-natpt-00.txt                   Pyda Srisuresh
                                                    Caymas Systems, Inc
                                                               May 2003




                       Scalable mNAT-PT Solution





Status of This Memo

  This document is an Internet-Draft and is subject to all provisions
  of Section 10 of RFC2026.

  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.





Abstract

  This document provides scalability extension to NAT-PT. The extension
  is based on the use of DNS-ALG and exchange of load metrics amongst a
  cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT.
  mNAT-PT is valuable in connecting large V6 domains to legacy V4
  domain.





Park, et, al.               Expires November 2003               [page 1]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


Table of Contents

  1.  Introduction ..................................................  2
  2.  Scaling Considerations ........................................  2
  3.  Terminology ...................................................  3
  4.  V4/v6 topology with a single NAT-PT device ....................  3
  5.  V4/v6 topology with multiple mNAT-PT devices ..................  4
  6.  Method of operation for mNAT-PT devices  ......................  5
  6.1 Load monitor & Communication amongst mNAT-PT cluster members...  5
  6.2 Redirection using DNS-ALG .....................................  7
  7.  Security Considerations .......................................  7
  8.  Intellectual Property .........................................  8
  9.  Copyright .....................................................  8
  10. Authors' Addresses ............................................  9
  11. References .................................................... 10



1.  Introduction

  In order to widely deploy IPv6 network, V4/V6 transition mechanisms
  are essential. NAT-PT and TRT transition solutions are proposed for
  enable connectivity between IPv6-only and IPv4 networks. However,
  both these solutions have limitations for large size V6 networks.
  This draft focuses on scaling extensions for traditional NAT-PT.
  Specifically, a method to permit outbound sessions for IPv6
  hosts in a large IPv6-only domain to the legacy IPv4 domain using
  multiple mNAT-PT translators.


2.  Scaling Considerations

  The NAT-PT solution defined in [NATPT] does not address scalability
  issue. Although TRT [TRT] considered scaling, it mandates
  reconfiguration of existing systems such as host and DNS-server by
  the network administrator. This may not be feasible or desirable in
  many circumstances, especially when the V6 domain is constituted
  of mobile nodes. In this document, we propose mNAT-PT as an
  efficient scalable solution to address such environments. Unlike
  TRT, mNAT-PT will not mandate changes to existing end-nodes.














Park, et, al.               Expires November 2003               [page 2]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


3.  Terminology

  The following terminology is used throughout the document.

        o  NAT-PT device        A device that implements traditional
                                NAT-PT function as described in [NATPT].

        o  mNAT-PT function     Stands for "Multiple NAT-PT". mNAT-PT
                                function makes use of NAT-PT, DNS-ALG
                                and real-time load monitoring functions
                                to scale NAT-PT function to multiple
                                NAT-PT devices.

        o  mNAT-PT device       A device that implements mNAT-PT function.

        o  Address Pool         IPv4 addresses to translate between IPv6
                                and IPv4 realms.

        o  Mapping Table        Mapping between IPv4 and IPv6 addresses
                                in the NAT-PT (or) mNAT-PT device.

        o  Load threshold       This is an upper ceiling of NAT BINDings
                                configured for a given mNAT-PT device.
                                When a mNAT-PT device reaches the
                                threshold, the mNAT-PT device attempts to
                                assign a different mNAT-PT device for new
                                sessions crossing the realms.

        o  ALG                  Application layer gateway.

        o  DNS-ALG              DNS Application layer gateway, as
                                described in [NATPT].


4.  V4/V6 topology with a single NAT-PT device


        +--------------------------------+           +-----------------+
        |                                |           |                 |
        | IPv6 domain                    |           |                 |
        |                                |           |                 |
        |  [IPv6-only host]----------[NAT-PT]--------|  IPv4 domain    |
        |           .          |         |           |                 |
        |           .          |         |           |                 |
        |                      |         |           |                 |
        |                [DNSv6 Server]  |           |                 |
        |                                |           |                 |
        +--------------------------------+           +-----------------+


                Figure 1 : single NAT-PT topology



Park, et, al.               Expires November 2003               [page 3]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


  As described in figure 1 above, IPv6-only hosts in the IPv6 domain
  are translated into IPv4 address by the NAT-PT device. NAT-PT is
  listed as the default router in IPv6 network. Also, there may be a
  DNSv6 Server within the IPv6 domain. The above solution cannot
  scale to support large no. of V6 hosts.


5. V4/v6 topology with multiple mNAT-PT devices

  With growing deployment of IPv6-only networks, a single NAT-PT
  will not be able to scale. Support for large number of mobile
  users is a requirement in a 3GPP mobile network. We propose
  deploying multiple mNAT-PT devices on the border of the IPv6
  domain as described below in figure 2. Each mNAT-PT device
  will perform NAT-PT function, host one or more unique IPv6
  prefixes and advertise the prefixes within the IPv6 domain.




        +------------------------------+            +----------------+
        |                              |            |                |
        | IPv6 domain                  |            |                |
        |                              |            |                |
        |  [IPv6-only host]--------[mNAT-PT]--------|                |
        |       .            |         |            |                |
        |       .            |         |            |                |
        |                    |         |            |                |
        |              [DNSv6 Server]  |            |                |
        |                    |         |            |  IPv4 domain   |
        |  [IPv6-only host]--------[mNAT-PT]--------|                |
        |       .            |         |            |                |
        |       .            |         |            |                |
        |  [IPv6-only host]--------[mNAT-PT]--------|                |
        |       .                      .            |                |
        |       .                      .            |                |
        |       .                      |            |                |
        +------------------------------+            +----------------+


                Figure 2 : mNAT-PT topology













Park, et, al.               Expires November 2003               [page 4]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


6. Method of operation for mNAT-PT devices

  The following layout describes how mNAT-PT function may be
  accomplished with the aid of DNS-ALG and Cluster Load-Monitor
  as an extension to NAT-PT function.

              +----------------+
              |    DNS-ALG     |
              |                |
        +-----+--------+-------+-----+---------+
        |              | Traditional |Interface|
        | Cluster-wide | NAT-PT      |   to    |   ______[IPv4 Domain]
        | Load Monitor | function    | IPv4    |___\
        |              |             |network  |
        +----------------------------+--------+
        | Interface to IPv6-network  |
        +----------------------------+
                       |
                       |/|
                         |
                         |
                    [IPv6 domain]

                Figure 3 : mNAT-PT functional framework


  A cluster of mNAT-PT devices may be configured to provide a scalable
  mNAT-PT solution to large V6 networks. All member nodes within a
  mNAT-PT cluster carry the same Cluster Identifier (ClusterId). The
  Load-Monitor entity within each mNAT-PT is responsible for relaying
  the real-time load on the hosting mNAT-PT periodically and in turn,
  collecting the load from member nodes within the cluster. The
  Load-monitor supplies real-time up-uo-date load data of member
  nodes to the DNS-ALG.

  The NAT-PT entity is required to invoke DNS-ALG for all DNS queries
  and responses traversing the domains. While processing the DNS
  response, the DNS-ALG will use load on member nodes as the basis to
  assign a IPv6 prefix in the AAAA response to the V6-node that
  originated the DNS query. The IPv6 prefix assignment will be based
  on the load on the mNAT-PT node associated with the prefix.


6.1. Load-monitor and Communication amongst mNAT-PT cluster members

  The following assumptions are made throughout the document. A few
  of these assumptions may be changed to suit specific deployment
  scenarios.

      * Communication amongst the cluster members may take place
        within the IPv6 domain.



Park, et, al.               Expires November 2003               [page 5]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


      * It is assumed that each of the mNAT-PT member nodes have
        non-conflicting address maps and host a IP-v6 prefix that
        is also non-conflicting.

      * This document uses NAT-BINDing load on member nodes as the
        criteria for determining which of the mNAT-PT devices is
        assigned to carry out a NAT-PT translation. However, load
        need not be the criteria or the only criteria to make the
        device selection. There may be other criteria or policies
        that decide the right mNAT-PT device.

      * The document assumes that all mNAT-PT devices equal access
        to all V4 routes in the V4 domain. This need not be the
        case. In such a case, the mNAT-PT devices must either
        setup V4-over-V6 VPNs between themselves so this is
        ensured (or) exchange the V4 route reachability between
        themselves so the right prefix is assigned based on route
        reachability. The former is the preffered and recommended
        choice.

      * The document assumes that the Cluster-ID,
        Cluster-controller and member nodes within a cluster are
        preconfigured on the mNAT-PT device. Dynamic discovery of
        Cluster members is out of the scope of this document.
        Election of initial or subsequent cluster controller is
        also outside the scope of this document. Cluster
        controller is assumed to be the first node of the cluster
        to come up. A cluster controller is required to be alive
        throughout the duration of the cluster.

      * The document assumes there exists a V6 path for any of
        the V6-only hosts to reach any of the mNAT-PT devices.

      * Lastly, [NIQ] does not seem like the right choice for
        cluster communication. Cluster communication requires
        reliable point-to-point data communication (say, TCP
        based sessions to a well-knwon port) and reliable
        point-to-multipoint communication. The document does
        not address the transport or message formats used for
        cluster communication at this time.

      * The communication amongst mNAT-PT cluster memebers
        devices should be properly authenticated to avoid any
        malicious devices trying to add a IPv6 prefix in the
        active list and thereby causing the traffic to be
        directed to the malicious device.








Park, et, al.               Expires November 2003               [page 6]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


    An mNAT-PT node joins the cluster by sending a message with
    the following mNAT-PT configuration data to Cluster controller.
    The cluster controller, in turn, accepts the node into cluster
    by sending the existing cluster membership info, Load-data
    polling duration and mNAT-PT configuration for each of the
    member nodes. The periodic load-data update will also be used
    to validate the liveness of a memeber node. Alternately,
    member nodes may terminate their memebership by explicitly
    sendign a termination message to the cluster controller.

                - The Cluster ID
                - Hosted IP-V6 Prefix
                - NAT-PT address map configuration
                - BINDings threshold limit

  Further to joining the cluster, the mNAT-PT nodes report their
  load-data to the cluster controller periodically. The load-data is
  essentially the count of active NAT-PT BINDings at the time of
  reporting.


6.2. Redirection using DNS-ALG

  Each mNAT-PT must be configured with a threshold of NAT BINDings
  and one or more IP-v6 prefixes (as desccribed in the previous
  section) in advance. The DNS-ALG is supplied with this information
  from the Load-Monitor.

  Typically, all the communications between a IPv4 device and IPv6
  device starts with a DNS request. DNS-ALG receives the DNS request and
  converts the A query to a AAAA query and vice versa. When the DNS-ALG
  receives the reply then it will decide which IPv6 prefix to use to
  translate the IPv4 address. If the load on the hosting mNAT-PT is
  within threshold configured for the node, then the prefix assigned
  to the host mNAT-PT is included in the DNS response. Otherwise,
  DNS-ALG will select a member node with the least percentage of load
  utilization vis-a-vis the threshold setting.


7.  Security Considerations

  Cluster communication between cooperatign mNAT-PT devices must be
  authenticated so that sessions are not hijacked by a rogue node
  that pretends to be a member mNAT-PT device.










Park, et, al.               Expires November 2003               [page 7]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


8.  Intellectual Property

  The following notice is copied from RFC 2026 [Bradner, 1996],
  Section 10.4, and describes the position of the IETF concerning
  intellectual property claims made against this document.

  The IETF takes no position regarding the validity or scope of any
  intellectual property or other rights that might be claimed to
  pertain to the implementation or use other technology described in
  this document or the extent to which any license under such rights
  might or might not be available; neither does it represent that it
  has made any effort to identify any such rights.  Information on the
  IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in BCP-11.  Copies of
  claims of rights made available for publication 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 Secretariat.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF Executive
  Director.

9.  Copyright

  The following copyright notice is copied from RFC 2026 [Bradner,
  1996], Section 10.4, and describes the applicable copyright for this
  document.

  Copyright (C) The Internet Society July 12, 2001. All Rights
  Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph
  are included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.






Park, et, al.               Expires November 2003               [page 8]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assignees.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS 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.



10.  Authors' Addresses

  Soohong Daniel Park
  Mobile Platform Laboratory
  SAMSUNG Electronics, KOREA
  Email:soohong.park@samsung.com


  Senthil Sivakumar
  Cisco Systems, Inc.
  170 West Tasman Dr.
  San Jose  CA 95134, US
  Email: ssenthil@cisco.com


  Pyda Srisuresh
  Caymas Systems, Inc
  1179-A North McDowell Blvd.
  petaluma, CA 94954
  USA
  Email: srisuresh@yahoo.com





















Park, et, al.               Expires November 2003               [page 9]


INTERNET-DRAFT            Scalable mNAT-PT Solution             May 2003


11.  References


  [Trans]       Gilligan, R. and  E. Nordmark, "Transition Mechanisms
                for IPv6 Hosts and Routers", RFC 1933, April 1996.

  [NATPT]       Tsirtsis G. and P. Srisuresh "Network Address
                Translation-Protocol Translation(NAT-PT)", RFC 2766,
                February 2000.

  [DSTM]        Bound, J, et al. "Dual Stack Transition Mechanism
                (DSTM)" draft-ietf-ngtrans-dstm-08.txt.

  [TRT]         J.Hagino, K.Yamamoto, "An IPv6-to-IPv4 Transport Relay
                Translator", RFC 3142, June 2001.

  [DNSALG]      Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
                Heffernan, "DNS extensions to Network Address
                Translators(DNS_ALG)", RFC 2694, September 1999.

  [NDP]         Narten, T, Nordmark, E, Simpson, W "Neighbor Discovery
                for IP Version 6 (IPv6)", RFC 2461, December 1998.

  [ISSUE]       Durand, A., "Issues with NAT-PT DNS ALG in RFC2766"
                Internet-Draft, January 2003, work in progress.

  [NIQ]         Crawford, M, "IPv6 Node Information Queries", Internet-
                Draft, May 2002, work in progress.

  [IPV6]        Deering, S, Hinden, R, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December, 1998.

  [LINK]        Hinden, R, et. al. "An IPv6 Aggregatable Global Unicast
                Address Format", RFC 2374, July 1998.




















Park, et, al.               Expires November 2003              [page 10]


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