[sig-policy] prop-095-v003: Inter-RIR IPv4 address transfer proposal
Hash: SHA1
Dear SIG members
Below is an updated version of the proposal that includes elements
changed during the APNIC 31 Policy SIG meeting.
The following changes were made:
- The conditions on the source and recipient of the transfer in
section 5.2 were changed.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-095
This proposal reached consensus at the Policy SIG meeting during the
Policy SIG at APNIC 31 in Hong Kong SAR, China, 21-25 February 2011.
It will be presented to the Policy SIG mailing list soon for a formal
eight-week final call for comments.
Gaurab, Terence, and Andy
_______________________________________________________________________
prop-095-v003: Inter-RIR IPv4 address transfer proposal
_______________________________________________________________________
Author: Tomohiro Fujisaki
Co-authors: Fuminori Tanizaki
Masaru Akai
Toshio Tachibana
Akira Nakagawa
Version: 3
Date: 24 February 2011
1. Introduction
- ----------------
This is a proposal to allow and define a mechanism for the transfer of
IPv4 address space between APNIC account holders and organizations in
other RIR region(s), providing that the counterpart RIR has a policy
that allows transfers of address space with APNIC account holders.
2. Definitions
- --------------
2.1 Source
When the source is from the APNIC region, the definition of
"source" from the active APNIC transfer policy [1] is to be used.
That is, the source must be a current APNIC account holder.
When the source of the transfer is from another RIR region, then
the source must be that RIR's equivalent to the "source" defined in
the active APNIC transfer policy.
2.2 Recipient
When the recipient is from the APNIC region, the definition of
"recipient" from the active APNIC transfer policy is to be used.
That is, the recipient must be a current APNIC account holder.
When the recipient of the transfer is from another RIR region, then
the recipient must be that RIR's equivalent to the "recipient"
defined in the active APNIC transfer policy.
3. Summary of the current problem
- ----------------------------------
The goal of the APNIC transfer policy was to help distribute IPv4
addresses from those who no longer need the addresses to organizations
that need the addresses, but can no longer obtain them from their RIR.
However, the current APNIC transfer policy is restricted to IPv4
transfers within the APNIC region. It does not allow transfers between
APNIC account holders and organizations with IPv4 addresses registered
with other RIRs. This restriction limits the ability of APNIC's
transfer policy's goal of allowing IPv4 addresses to be transferred to
networks that need them by preventing surplus and need to be balanced
across regional boundaries as well as within the APNIC region.
4. Situation in other RIRs
- ---------------------------
ARIN:
The ARIN has draft policy ARIN-2011-1, "Globally Coordinated
Transfer Policy".
https://www.arin.net/policy/proposals/2011_1.html
There are no similar proposals in the AfriNIC, LACNIC or RIPE regions.
5. Details
- -----------
It is proposed that:
5.1 Inter-RIR transfers be permitted when the other RIR involved in the
transfer has a policy in place that permits transfers of IPv4
address space between APNIC and their own region.
5.2 APNIC acknowledge and process the transfer of IPv4 space between
APNIC account holders and an equivalent of account holders in other
RIRs, according to the following processes and conditions:
5.2.1 Conditions on the space to be transferred
- The IPv4 address space should be under the management of
the RIR which the transfer source holds an account
- The authentic holder of the space should match with the
source without any disputes.
5.2.2 Conditions on the source of the transfer
The conditions of the transfer defined by RIR where the
source organization holds an account, will apply to the
source of the transfer:
- For transfers from an APNIC account holder to an
account holder of the counterpart RIR(*), the
conditions defined in APNIC transfer policy at the
time of the transfer will apply
- For transfers from an account holder of the counterpart
RIR(*) to an APNIC account holder, the conditions
defined in the counterpart RIR's transfer policy at the
time of the transfer will apply
(*) Counterpart RIR is the RIR that APNIC transfers the IPv4
address space from/to
5.2.3 Conditions on the recipient of the transfer
The conditions of the transfer defined by RIR where the
recipient organization holds an account, will apply to the
recipient of the transfer:
- For transfers from an account holder of the counterpart
RIR(*) to APNIC account holder, the conditions defined
in APNIC transfer policy at the time of the transfer
will apply
- For transfers from APNIC account holder an account
holder of to the counterpart RIR(*), the conditions
defined in the counterpart RIR's transfer policy at the
time of the transfer will apply
(*) Counterpart RIR is the RIR that APNIC transfers the IPv4
address space from/to
5.2.4 Approval of the transfer
The transfer must have the approval of both the counterpart
RIR and APNIC to proceed with the transfer, with confirmation
that both the source and recipient have agreed to the
transfer.
6. Pros/Cons
- -------------
Advantages:
- This proposal will expand the scope of transferable IPv4 address
space outside of the APNIC region, and therefore better meet the
goals of the APNIC transfer policy.
Disadvantages:
- None.
7. Effect on APNIC
- -------------------
When APNIC account holders are the recipient of a transfer, and the
source is located in another RIR, the account holder must be aware of
the transfer policy in place at that other RIR.
8. Effect on NIRs
- ------------------
NIRs are given a choice on whether to adopt this policy. If NIRs choose
to adopt this policy, the transfer procedure will be processed via
APNIC.
9. References
- --------------
[1] Section 3, "Transfers of IPv4 addresses," in "APNIC transfer,
merger, acquisition, and takeover policy"
http://www.apnic.net/policy/transfer-policy
- --
http://www.gaurab.org.np/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1scOYACgkQSo7fU26F3X1vtACeKdd3CDu4BmoXFk6DaBTkCr3O
KAkAn3Ho9GyPuOIvB+DJKHLfMVbpYcs0
=A2xP
-----END PGP SIGNATURE-----