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

Versions: 00

Network Working Group                                             C. Xie
Internet-Draft                                                    Q. Sun
Intended status: Informational                             China Telecom
Expires: April 24, 2014                                          C. Zhou
                                                     Huawei Technologies
                                                        October 21, 2013


                 Address Management for IPv6 Transition
           draft-sun-v6ops-openv6-address-pool-management-00

Abstract

   This document proposes a mechanism to manage the address pools
   centrally.  Different transition mechanisms can require the address
   pools on-demand.  Therefore, carriers does not need to configure the
   address pools one by one manually and it also help to use the address
   pools more efficiently.

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 April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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



Xie, et al.              Expires April 24, 2014                 [Page 1]


Internet-Draft       Openv6 Address Pool Management         October 2013


   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.  Overall Procedure . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Initial Address Pool Configuration  . . . . . . . . . . . . 4
     3.2.  Address Pool Status Report  . . . . . . . . . . . . . . . . 6
     3.3.  Address Pool Status Query . . . . . . . . . . . . . . . . . 7
     3.4.  Run Out of Address  . . . . . . . . . . . . . . . . . . . . 7
     3.5.  Address Pool Release  . . . . . . . . . . . . . . . . . . . 7
   4.  Deployment Consideration  . . . . . . . . . . . . . . . . . . . 9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Xie, et al.              Expires April 24, 2014                 [Page 2]


Internet-Draft       Openv6 Address Pool Management         October 2013


1.  Introduction

   Network address migration to IPv6 is ongoing or upcoming throughout
   the world due to the lack of IPv4 addresses.  When carriers are
   facing with address shortage problem, the remaining IPv4 address
   pools are usually quite scattered.  It is quite complicated for a
   carrier to manage scattered address pools in many transition devices.
   The situation will become even worse when multiple transition
   mechanisms in the same device need to be configured with different
   address pools.  Besides, since the occupation of the address pools
   may vary during different transition periods, (e.g. at the early
   stage of IPv6 transition, IPv4 traffic will normally occupy a great
   portion of the total traffic, while in the later stage of IPv6
   transition, IPv4 traffic will decrease and the amount of IPv4 address
   pools will decrease accordingly.

   In this document, we propose a mechanism to manage the address pools
   centrally.  Different transition mechanisms can require the address
   pools on-demand.  For example, when one transition mechanism is
   running out of the current address pools,it may request a additional
   address pool.  It can also release the address pools that it is not
   using anymore.  In this way, carriers does not need to configure the
   address pools one by one manually and it also help to use the address
   pools more efficiently.


2.  Terminology

   The following terms are used in this document:






3.  Overall Procedure

   This mechanism consists of two components: Address Management
   Server(AMS) and Transition Device (TD).  AMS is responsible for
   address pool management while the TD will do traditional transition
   mechanisms, e.g.  DS-Lite , NAT64, etc.  The overall procedure is as
   follows:

   o  Operators will configure remaining address pools centrally in the
      Address Management Server.  There are multiple address pools which
      can be configured centrally.  The AMS will then divide the address
      pools with addressing unit (AU) which will be allocated to
      transition device by default.



Xie, et al.              Expires April 24, 2014                 [Page 3]


Internet-Draft       Openv6 Address Pool Management         October 2013


   o  Transition Device will initiate AddressPool reqeust to the AMS.
      It can carry its desired size of address pool the request, or just
      use a default value.  The address pool size in the TD's request is
      only used as a hint.  The actual size of the address pool is
      totally determined by AMS.  It will also carry the TD's
      identification and the type of transition mechanism.

   o  AMS lookups the remaining address pool in its local database.  It
      will then allocate a set of address pools to the TD.  Each address
      pool has a related lifetime.

   o  TD receives the AddressPool reply and use them for the transition
      mechanisms.

   o  If the lifetime of the address pool is going to expire, the TD
      should issue an AddressPoolRenew request to extend the lifetime.

   o  The AddressPoolReport module keeps monitoring and reports the
      current usage of the current address pools for each transition
      mechanism. if one transition mechanism is running out of address
      pools, it can renew the AddressPoolRequest for a new one.  It can
      also release an existing address pool if the that address pool has
      not been used for a long time.

   o  When the status of AMS is lost or the AMS needs the status
      information of certain applications, the AMS may actively query
      the TD for the status information.

   The following sub-section describes the detailed procedures of the
   address pool management.

3.1.  Initial Address Pool Configuration



















Xie, et al.              Expires April 24, 2014                 [Page 4]


Internet-Draft       Openv6 Address Pool Management         October 2013


     +--------------+                             +----------------+
     | Transition   |                             | AddrManagmenet |
     |   Device     |                             |   Server       |
     +------+-------+                             +--------+-------+
            |                                              |
   +--------+-------+                                      |
   |1.TD start-up   |                                      |
   +---------+------+                                      |
            |            2.Address Pool Request            |
            |--------------------------------------------->|
            |                                              |
            |                                     +--------+-------+
            |                                     |  3. Check      |
            |                                     |   address pool |
            |                                     +--------+-------+
            |          4.Address Pool Reply                |
            |<---------------------------------------------|
            |                                              |
            |                                              |


               Figure 1: Initial Address Pool Configuration

   Figure 1 illustrates the initial address pool configuration
   procedure:

   1.  The TD checks whether there is already address pool configured in
       the local site when it starts up. if no, it means the initial
       start-up or the address pool has been released. if yes, the
       address pool could be used directly.

   2.  The TD will initiate Address Pool reqeust to the AMS.  It can
       carry its desired size of address pool in the request, or just
       use a default value.  The address pool size in the TD's request
       is only used as a hint.  The actual size of the address pool is
       totally determined by AMS.  It will also carry the TD's
       identification, the type of transition mechanism and the
       indication of port allocation support.

   3.  The AMS determines the address pool allocated for the TD based on
       the parameters received.

   4.  The AMS sends the Address Pool Reply to the TD.  It will also
       distribute the routing entry of the address pool automatically.
       In particular, if the newly received address pool can be
       aggregated to an existing one, the routing should be aggregated
       accordingly.




Xie, et al.              Expires April 24, 2014                 [Page 5]


Internet-Draft       Openv6 Address Pool Management         October 2013


3.2.  Address Pool Status Report



     +--------------+                             +----------------+
     | Transition   |                             | AddrManagmenet |
     |   Device     |                             |   Server       |
     +------+-------+                             +--------+-------+
            |                                              |
   +--------+-------+                                      |
   |1.Monitor and   |                                      |
   |count the status|                                      |
   +--------+-------+                                      |
            |        2.Address Pool Status Report          |
            |--------------------------------------------->|
            |                                     +--------+-------+
            |                                     |  3. Record     |
            |                                     |   address pool |
            |                                     +--------+-------+
            |       4.Address Pool Report Confirm          |
            |<---------------------------------------------|
            |                                              |
            |                                              |


                   Figure 2: Address Pool Status Report

   Figure 2 illustrates the active address pool status report procedure:

   1.  The TD will monitor and count the usage status of the local
       address pool.  The TD counts the address usage status in one
       month, one week and one day, which includes the local address,
       address usage ratio (peak and average values), and the port usage
       ratio (peak and average values).

   2.  The TD reports the address pool usage status to the AMS. for
       example, it will report the address usage status in one day,
       which contains the IP address, NAT44, address list:
       30.14.44.0/28, peak address value 14, average address usage ratio
       90%, TCP port usage ratio 20%, UDP port usage ratio 30% and etc.

   3.  The AMS records the status and compares with the existing address
       information to determine whether additional address pool is
       needed.

   4.  The AMS will confirm the address pool status report request to
       the TD.  It will keep sending the address pool status report
       request to the AMS if no confirm message is received.



Xie, et al.              Expires April 24, 2014                 [Page 6]


Internet-Draft       Openv6 Address Pool Management         October 2013


3.3.  Address Pool Status Query

   When the status of AMS is lost or the AMS needs the status
   information of the TDs, the AMS may actively query the TD for the
   status information, as shown in step 1 of Figure 3.  The following
   steps 2,3,4,5 are the same as the Address Pool Status Report
   procedure.



     +--------------+                             +----------------+
     | Transition   |                             | AddrManagmenet |
     |   Device     |                             |   Server       |
     +------+-------+                             +--------+-------+
            |                                              |
            |                                              |
            |         1.Address Pool Status Query          |
            |<---------------------------------------------|
            |                                              |
   +--------+-------+                                      |
   |2.Monitor and   |                                      |
   |count the status|                                      |
   +--------+-------+                                      |
            |        3.Address Pool Status Report          |
            |--------------------------------------------->|
            |                                     +--------+-------+
            |                                     |  4. Record     |
            |                                     |   address pool |
            |                                     +--------+-------+
            |       5.Address Pool Report Confirm          |
            |<---------------------------------------------|
            |                                              |
            |                                              |


                    Figure 3: Address Pool Status Query

3.4.  Run Out of Address

   When the TD used up the addresses allocated, it will renew the
   address pool request to the AMS for additional address pool.  The
   procedure is the same as the initial address pool request.

3.5.  Address Pool Release







Xie, et al.              Expires April 24, 2014                 [Page 7]


Internet-Draft       Openv6 Address Pool Management         October 2013


     +--------------+                             +----------------+
     | Transition   |                             | AddrManagmenet |
     |   Device     |                             |   Server       |
     +------+-------+                             +--------+-------+
            |                                              |
   +--------+-------+                                      |
   |1.Address pools |                                      |
   |  not used for a|                                      |
   |   long time    |                                      |
   +--------+-------+                                      |
            |        2.Address Pool Release Request        |
            |--------------------------------------------->|
            |                                     +--------+-------+
            |                                     |3. Update       |
            |                                     |   address pool |
            |                                     |   database     |
            |                                     +--------+-------+
            |       4.Address Pool Release Notification    |
            |<---------------------------------------------|
   +--------+-------+                                      |
   |5. Reduce       |                                      |
   |  address pool  |                                      |
   +--------+-------+                                      |
            |         6.Address Pool Release Confirm       |
            |--------------------------------------------->|
            |                                              |
            |                                              |


                      Figure 4: Address Pool Release

   Figure 4 illustrates the address pool release procedure:

   1.  The counting module in the TD checks that there are addresses not
       used for a long time;

   2.  The TD sends the address pool release request to the AMS to ask
       the release of those addresses;

   3.  The AMS updates the local address pool information to add the new
       addressed released.

   4.  The AMS notifies the TD that the addresses have been release
       successfully;

   5.  The TD will update the local address pool. if no Address Pool
       Release Notification is received, the TD will repeat step 2;




Xie, et al.              Expires April 24, 2014                 [Page 8]


Internet-Draft       Openv6 Address Pool Management         October 2013


   6.  The TD confirms with the AMS that the addres pool has been
       released successfully.


4.  Deployment Consideration

   In actual network, the AMS can be deployed centrally, e.g.
   centrallized in one province.  One AMS can take management on the TDs
   of the whole area.  The requests between ASM and TD would not be too
   frequent and the lifetime of the address pool can be relatively long.


5.  Security Considerations


6.  Acknowledgements

   N/A.


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [RFC6674]  Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
              "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
              July 2012.

   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Requirements for Carrier-Grade NATs
              (CGNs)", BCP 127, RFC 6888, April 2013.


Authors' Addresses

   Chongfeng Xie
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China

   Email: xiechf@ctbri.com.cn




Xie, et al.              Expires April 24, 2014                 [Page 9]


Internet-Draft       Openv6 Address Pool Management         October 2013


   Qiong Sun
   China Telecom
   No.118 Xizhimennei street, Xicheng District
   Beijing  100035
   P.R. China

   Email: sunqiong@ctbri.com.cn


   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com



































Xie, et al.              Expires April 24, 2014                [Page 10]


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