Internet DRAFT - draft-sun-openv6-address-pool-management
draft-sun-openv6-address-pool-management
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-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]
