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]