Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear SIG members
Version two of the proposal 'IPv4 address transfers' has been sent to the Policy SIG for review. It will be presented during the Policy SIG sessions at APNIC 25 in Taipei, Taiwan, 25-29 February 2008.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-050-v002.html
We invite you to review and comment on the proposal on the mailing list before the meeting.
The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to:
- Ask the proposer questions if anything in the proposal is unclear - Point out advantages and disadvantages you see in the proposal - State whether you support or oppose the proposal
Mailing list discussions will be taken into account when the proposal is discussed at the upcoming APNIC meeting. So please make sure you have your say.
APNIC Policy SIG Chairs Toshiyuki Hosaka Randy Bush Jian Zhang
________________________________________________________________________
prop-050-v002: IPv4 address transfers ________________________________________________________________________
Author: Geoff Huston gih@apnic.net
Version: 2
Date: 22 January 2008
1. Introduction ----------------
This is a proposal to remove APNIC policy restrictions on the transfer of registration of IPv4 address allocations and IPv4 portable address assignments between current APNIC account holders. This proposal is a refinement of the historical resource transfer policy and applies to IPv4 resources held by current APNIC account holders.
2. Summary of current problem ------------------------------
Current APNIC policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network.
It is currently anticipated that the IPv4 unallocated address pool will be exhausted in a timeframe of between 2009 and 2011. There is a very considerable level of investment in IPv4-based services in the Asia Pacific region, and a transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks.
It is the objective of the APNIC IPv4 address registry to accurately record current address distribution information.
This proposal allows APNIC to recognise the transfer of IPv4 addresses between current APNIC account holders, and places some constraints on the parties to the transfer as a precondition for the registration of the IPv4 address transfer to be undertaken by APNIC.
3. Situation in other RIRs ----------------------------
It is the understanding of the proposer that no comparable IPv4 resource transfer policy between account holders has been adopted in any other RIR.
A proposal for address transfers similar to this proposal has been submitted to the RIPE community as a Policy Proposal:
2007-08: Enabling Methods for Reallocation of IPv4 Resources http://www.ripe.net/ripe/policies/proposals/2007-08.html
4. Details of the proposal ----------------------------
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.
- The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC.
- The address block must be allocated or assigned to a current APNIC account holder.
- The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical".
Conditions on source of the transfer:
- The source entity must be a current APNIC account holder.
- The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
- The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
- In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation.
Conditions on recipient of the transfer:
- The recipient entity must be a current APNIC account holder.
- The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources.
- APNIC fees payable by the recipient will be assessed on the basis of all resources held.
The address transfer process:
After APNIC is notified of the transfer by both the source and the recipient of the transfer:
1. APNIC will update the registration records relating to the transferred addresses.
2. APNIC will adjust the source's address holdings as of the date of transfer.
In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date.
3. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer.
In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date.
In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient.
4. The following transfer details will be published by APNIC in a public log of resource transfers:
- Source - Recipient - Address resources - Date of transfer
Transfer fees:
APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred.
The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges.
5. Advantages and disadvantages of the proposal -------------------------------------------------
Advantages:
This proposal would:
- Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders.
- Mitigate the risks to the integrity of the network and its routing and addressing infrastructure associated with the unregistered transfers of IPv4 addresses. This proposal, by acknowledging the existence of address transfers and registering the outcomes would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith.
- Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition.
Disadvantages:
- Concerns have been raised about a market-based system emerging as the only means to obtain IPv4 address space in future, and the potential for certain forms of market failures, including the possibility of hoarding, speculation and price manipulation.
A number of factors mitigate these risks. As the transition to IPv6 gathers pace, a market-based value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. An additional constraint would apply if this policy were to be adopted while IPv4 addresses are still available from APNIC, as APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry.
6. Effect on APNIC members ----------------------------
APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC account holders.
7. Effect on NIRs -------------------
This policy does not encompass IPv4 address holdings administered by NIRs, nor the transfer of resources where the source or recipient are NIR-serviced entities.
(end of document)
Hi Toshi,
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.
However, I feel the principle of the policy needs to go further:
- incorporate NIRs, as NIRs are *not* independent resource registries but are part of the APNIC family
- allow LIR members of other RIRs to participate too.
But one small step at a time; I feel this proposal is the correct first step forward...
philip --
Toshiyuki Hosaka said the following on 22/1/08 16:56:
Dear SIG members
Version two of the proposal 'IPv4 address transfers' has been sent to the Policy SIG for review. It will be presented during the Policy SIG sessions at APNIC 25 in Taipei, Taiwan, 25-29 February 2008.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-050-v002.htmlWe invite you to review and comment on the proposal on the mailing list before the meeting.
The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to:
- Ask the proposer questions if anything in the proposal is unclear - Point out advantages and disadvantages you see in the proposal - State whether you support or oppose the proposalMailing list discussions will be taken into account when the proposal is discussed at the upcoming APNIC meeting. So please make sure you have your say.
APNIC Policy SIG Chairs Toshiyuki Hosaka Randy Bush Jian Zhang
prop-050-v002: IPv4 address transfers ________________________________________________________________________
Author: Geoff Huston gih@apnic.net
Version: 2
Date: 22 January 2008
- Introduction
This is a proposal to remove APNIC policy restrictions on the transfer of registration of IPv4 address allocations and IPv4 portable address assignments between current APNIC account holders. This proposal is a refinement of the historical resource transfer policy and applies to IPv4 resources held by current APNIC account holders.
- Summary of current problem
Current APNIC policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network.
It is currently anticipated that the IPv4 unallocated address pool will be exhausted in a timeframe of between 2009 and 2011. There is a very considerable level of investment in IPv4-based services in the Asia Pacific region, and a transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks.
It is the objective of the APNIC IPv4 address registry to accurately record current address distribution information.
This proposal allows APNIC to recognise the transfer of IPv4 addresses between current APNIC account holders, and places some constraints on the parties to the transfer as a precondition for the registration of the IPv4 address transfer to be undertaken by APNIC.
- Situation in other RIRs
It is the understanding of the proposer that no comparable IPv4 resource transfer policy between account holders has been adopted in any other RIR.
A proposal for address transfers similar to this proposal has been submitted to the RIPE community as a Policy Proposal:
2007-08: Enabling Methods for Reallocation of IPv4 Resources http://www.ripe.net/ripe/policies/proposals/2007-08.html
- Details of the proposal
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical".Conditions on source of the transfer:
- The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation.Conditions on recipient of the transfer:
- The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held.The address transfer process:
After APNIC is notified of the transfer by both the source and the recipient of the transfer: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the source's address holdings as of the date of transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date. 3. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date. In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient. 4. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Recipient - Address resources - Date of transferTransfer fees:
APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges.
- Advantages and disadvantages of the proposal
Advantages:
This proposal would:
- Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders. - Mitigate the risks to the integrity of the network and its routing and addressing infrastructure associated with the unregistered transfers of IPv4 addresses. This proposal, by acknowledging the existence of address transfers and registering the outcomes would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith. - Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition.Disadvantages:
- Concerns have been raised about a market-based system emerging as the only means to obtain IPv4 address space in future, and the potential for certain forms of market failures, including the possibility of hoarding, speculation and price manipulation. A number of factors mitigate these risks. As the transition to IPv6 gathers pace, a market-based value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. An additional constraint would apply if this policy were to be adopted while IPv4 addresses are still available from APNIC, as APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry.
- Effect on APNIC members
APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC account holders.
- Effect on NIRs
This policy does not encompass IPv4 address holdings administered by NIRs, nor the transfer of resources where the source or recipient are NIR-serviced entities.
(end of document)
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Hi Philip,
Thanks for your comment.
Philip Smith wrote:
Hi Toshi,
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually
Are you reffering to the case of company merger of acquisition, or actual address trading?
legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.
Do you think if this policy was implemented those who traded unlegitimately would confess and register that transfer to DB? Similarly, will those who trade the address space really declare that under this policy?
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view, I would appreciate it, in order to understand this proposal's effectiveness.
thanks and best regards, toshi
However, I feel the principle of the policy needs to go further:
- incorporate NIRs, as NIRs are *not* independent resource registries
but are part of the APNIC family
- allow LIR members of other RIRs to participate too.
But one small step at a time; I feel this proposal is the correct first step forward...
philip
Toshiyuki Hosaka said the following on 22/1/08 16:56:
Dear SIG members
Version two of the proposal 'IPv4 address transfers' has been sent to the Policy SIG for review. It will be presented during the Policy SIG sessions at APNIC 25 in Taipei, Taiwan, 25-29 February 2008.
The proposal's history can be found at:
http://www.apnic.net/policy/proposals/prop-050-v002.htmlWe invite you to review and comment on the proposal on the mailing list before the meeting.
The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to:
- Ask the proposer questions if anything in the proposal is unclear - Point out advantages and disadvantages you see in the proposal - State whether you support or oppose the proposalMailing list discussions will be taken into account when the proposal is discussed at the upcoming APNIC meeting. So please make sure you have your say.
APNIC Policy SIG Chairs Toshiyuki Hosaka Randy Bush Jian Zhang
prop-050-v002: IPv4 address transfers ________________________________________________________________________
Author: Geoff Huston gih@apnic.net
Version: 2
Date: 22 January 2008
- Introduction
This is a proposal to remove APNIC policy restrictions on the transfer of registration of IPv4 address allocations and IPv4 portable address assignments between current APNIC account holders. This proposal is a refinement of the historical resource transfer policy and applies to IPv4 resources held by current APNIC account holders.
- Summary of current problem
Current APNIC policies relating to the registration of transfer of address holdings limit the eligibility of registration of transfers to those relating to mergers and acquisitions of entities that are administering an operational network.
It is currently anticipated that the IPv4 unallocated address pool will be exhausted in a timeframe of between 2009 and 2011. There is a very considerable level of investment in IPv4-based services in the Asia Pacific region, and a transition to IPv6-based service delivery is likely to take longer than the remaining period of unallocated address availability. Accordingly, it is likely that demand for IPv4 addresses will continue beyond the time of unallocated address pool exhaustion, leading to a period of movement of IPv4 address blocks between address holders to meet such continuing demand for IPv4 address blocks.
It is the objective of the APNIC IPv4 address registry to accurately record current address distribution information.
This proposal allows APNIC to recognise the transfer of IPv4 addresses between current APNIC account holders, and places some constraints on the parties to the transfer as a precondition for the registration of the IPv4 address transfer to be undertaken by APNIC.
- Situation in other RIRs
It is the understanding of the proposer that no comparable IPv4 resource transfer policy between account holders has been adopted in any other RIR.
A proposal for address transfers similar to this proposal has been submitted to the RIPE community as a Policy Proposal:
2007-08: Enabling Methods for Reallocation of IPv4 Resources http://www.ripe.net/ripe/policies/proposals/2007-08.html
- Details of the proposal
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical".Conditions on source of the transfer:
- The source entity must be a current APNIC account holder. - The source entity must be the currently registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer. - In making any future IPv4 address resource requests to APNIC, for as long as IPv4 address resources are available from APNIC, following the expiration of this 24 month ineligibility period, the source will be required to document the reasons for the IPv4 address resource allocation.Conditions on recipient of the transfer:
- The recipient entity must be a current APNIC account holder. - The recipient entity of the transferred resources will be subject to current APNIC policies. In particular, in any subsequent APNIC IPv4 address allocation request, the recipient will be required to account for all IPv4 address space held, including all transferred resources. - APNIC fees payable by the recipient will be assessed on the basis of all resources held.The address transfer process:
After APNIC is notified of the transfer by both the source and the recipient of the transfer: 1. APNIC will update the registration records relating to the transferred addresses. 2. APNIC will adjust the source's address holdings as of the date of transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as a return of address holdings to APNIC as of that date. 3. APNIC will adjust the recipient's address holdings to include the transferred addresses as of the date of the transfer. In terms of membership and/or service fee calculations this shall be processed in the same manner as an allocation or assignment of address holdings to the recipient as of that date. In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient. 4. The following transfer details will be published by APNIC in a public log of resource transfers: - Source - Recipient - Address resources - Date of transferTransfer fees:
APNIC may charge the recipient a service fee on the transfer transaction. The transfer service fee may vary according to the total size of the address block being transferred. The transfer fee schedule shall be set initially by the APNIC Executive Council upon adoption of this policy. The transfer fee schedule will be included as part of any future review of APNIC fees and charges.
- Advantages and disadvantages of the proposal
Advantages:
This proposal would:
- Ensure that the APNIC registry continues to reflect the current actual status of IPv4 resource holdings by APNIC account holders. - Mitigate the risks to the integrity of the network and its routing and addressing infrastructure associated with the unregistered transfers of IPv4 addresses. This proposal, by acknowledging the existence of address transfers and registering the outcomes would ensure that the APNIC address registry continues to maintain accurate data about resources and resource holders. The proposal also ensures that those parties who currently rely on the accuracy of this registration information can continue to rely on the currency and accuracy of this information in good faith. - Provide a stronger incentive for unused IPv4 address space to return to active use, helping to satisfy residual demand for IPv4 address space across the IPv6 transition.Disadvantages:
- Concerns have been raised about a market-based system emerging as the only means to obtain IPv4 address space in future, and the potential for certain forms of market failures, including the possibility of hoarding, speculation and price manipulation. A number of factors mitigate these risks. As the transition to IPv6 gathers pace, a market-based value of IPv4 addresses would fall in line with the decreasing value proposition of IPv4-based services in an increasing IPv6 network. An additional constraint would apply if this policy were to be adopted while IPv4 addresses are still available from APNIC, as APNIC's established IPv4 address allocation process would continue to provide an alternative source of supply of IPv4 addresses to the industry.
- Effect on APNIC members
APNIC members will have the ability to register the transfer of IPv4 address resources between APNIC account holders.
- Effect on NIRs
This policy does not encompass IPv4 address holdings administered by NIRs, nor the transfer of resources where the source or recipient are NIR-serviced entities.
(end of document)
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
sig-policy: APNIC SIG on resource management policy *
sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
hi toshi,
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view,
rpki
randy
Hi Toshi,
Toshiyuki Hosaka said the following on 23/1/08 10:48:
Are you reffering to the case of company merger of acquisition, or actual address trading?
The answer is "yes". Both. :-)
Do you think if this policy was implemented those who traded unlegitimately would confess and register that transfer to DB?
If they had a choice between this and not being able to have their prefix routed, I think they'd prefer this choice. At the moment, their prefix is routed purely by good luck.
Similarly, will those who trade the address space really declare that under this policy?
Yup. With a bigger routing system I suspect more and more ISPs will start wanting to validate what they are carrying. Especially when it costs them serious money to have infrastructure just to handle massive BGP tables and the updates caused by these. Which I feel are coming (maybe this is fear/uncertainty/doubt but going by history, I've reason to worry.)
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view, I would appreciate it, in order to understand this proposal's effectiveness.
Without this proposal, or preferably a much stronger one which incorporates the entire APNIC family, I feel the Internet Routing system in this region really will start getting into trouble... Registration of resource is one of the key reasons for the success and stability of the routing system so far. (Same as a car registration plate means that it gives us a better idea who a particular car owner is. ;-))
philip --
Philip Smith wrote:
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view, I would appreciate it, in order to understand this proposal's effectiveness.
Without this proposal, or preferably a much stronger one which incorporates the entire APNIC family, I feel the Internet Routing system in this region really will start getting into trouble... Registration of resource is one of the key reasons for the success and stability of the routing system so far. (Same as a car registration plate means that it gives us a better idea who a particular car owner is. ;-))
Randy's earlier response of referencing the resource public key infrastructure and the associated aspect of certification of right of use of addresses, and the above comment from Philip encompass what I would've said in response to your question.
thanks,
Geoff
Toshiyuki Hosaka wrote:
Hi Philip,
Thanks for your comment.
Philip Smith wrote:
Hi Toshi,
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually
Are you reffering to the case of company merger of acquisition, or actual address trading?
legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.
Do you think if this policy was implemented those who traded unlegitimately would confess and register that transfer to DB? Similarly, will those who trade the address space really declare that under this policy?
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view, I would appreciate it, in order to understand this proposal's effectiveness.
The incentive to register the transfer exists for both the source of the transfer and the recipient.
For the recipient, unless the transfer is registered by the registry the recipient has no way of demonstrating to anyone that the address space is now controlled by them. The registry details point to the previous party, the source of the transfer. This means that it would be challenging to prove to a potential upstream or peer that the address space that is announced is really theirs to announce, and to potential customers that the addresses that are being used are legitimate addresses. If the address space was listed in any spam black list the lack of any change of registry details would make the task of convincing the BL maintainers that the status of the address has changed with the transfer would also be harder. The recipient also has a strong motive to prevent the source from attempting to transfer the address a second time to a third party. If the registry details continue to point to the source as the current holder of the address then the source can attempt further transactions on the same address space, and noone is any wiser that the transfer is fraudulent. And if the recipient ever wanted to transfer the address at a later date, then without the registry details referring to them as the current address holder then subsequent transfers would be challenging. So as far as I can see the recipient has a strong motive to have the transfer registered.
From the source's point of view a recognised transfer is of higher value than an unrecognised transfer. Potential address purchasers can be sought openly and the value of the transfer can be realized more effectively - i.e. the source has the ability to realize the full current value of the transfer in an open situation.
regards,
Geoff
For the recipient, unless the transfer is registered by the registry the recipient has no way of demonstrating to anyone that the address space is now controlled by them.
black market goods which are not uniquely identifiable (think booze) sell at prices somewhat related to free market prices for the same items.
goods which are uniquely identifiable (think famous art), sell at a fraction of free market price because the buyer can not openly admit to having bought them. and further resale is quite difficult.
randy
On Jan 23, 2008, at 12:43 PM, Geoff Huston wrote:
Toshiyuki Hosaka wrote:
Hi Philip,
Thanks for your comment.
Philip Smith wrote:
Hi Toshi,
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually
Are you reffering to the case of company merger of acquisition, or actual address trading?
legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.
Do you think if this policy was implemented those who traded unlegitimately would confess and register that transfer to DB? Similarly, will those who trade the address space really declare that under this policy?
I do not know. If you (or proposal author) have any thought on the incentive to register it to DB from source/recipient point of view, I would appreciate it, in order to understand this proposal's effectiveness.
The incentive to register the transfer exists for both the source of the transfer and the recipient.
Hi Geoff,
One might observe that this is true for ANY and EVERY transferable good, unique or otherwise, that might be subject to abuse or unauthorized use at any time. However, I don't know of any case where those self-interests alone are enough to sustain the actual practice of consistent, complete, and timely registration. Self-interest certainly doesn't sustain this practice in the case of automobiles (an analogy used in another posting) -- police enforcement, transparent signaling (i.e., various outwardly visible identifiers), and the risk of legal consequences do that. And self interests didn't sustain consistent, complete, and timely registration of re-RIR legacy resources either.
No doubt some people will conclude that their interests are advanced by registration, just as others will conclude that bilateral, transaction-specific information sharing better serves their private interests. Given the fact that the viability of the public registration database could hinge on the answer, do we have any reason for assuming ex ante why (or which) one set of incentives will dominate the other?
For the recipient, unless the transfer is registered by the registry the recipient has no way of demonstrating to anyone that the address space is now controlled by them. The registry details point to the previous party, the source of the transfer.
Since the old registry details, where they exist at all, demonstrate uniqueness -- albeit just not the correct unique association with the current owner, what motivation does the new recipient have to correct the record? If the previous address resource holder was not afflicted by uniqueness-related concerns, is there some reason to assume that new recipients interests favoring full, accurate, and timely registration will always be greater than their countervailing interests, as well as the normal human tendency to procrastinate and/ or avoid "bureaucratic" obligations whenever possible?
This means that it would be challenging to prove to a potential upstream or peer that the address space that is announced is really theirs to announce, and to potential customers that the addresses that are being used are legitimate addresses.
I think it would be interesting to assay the contents of current routing tables based on the duration since each entry's most recent whois update. It's an empirical question, but I'm willing to bet up front that a large quantity of address space continues to be routed with no obvious, recent, *public* affirmation of current ownership.
If the address space was listed in any spam black list the lack of any change of registry details would make the task of convincing the BL maintainers that the status of the address has changed with the transfer would also be harder.
What share of address space currently routed is on somebody's spam list? Doesn't the continued presence of address space on such lists suggest that, for some operators, it doesn't matter -- or at least is not operationally relevant enough to inspire whatever action required to get off such lists? Anyway, one might imagine that spammers and other willful miscreants will be buying and selling address space too, so spam lists are unlikely to be going away.
The recipient also has a strong motive to prevent the source from attempting to transfer the address a second time to a third party.
That might incentivize the recipient to seek some change in the registration data at the time of acquisition, but that change need not be one that results in accurate or useful whois.
If the registry details continue to point to the source as the current holder of the address then the source can attempt further transactions on the same address space, and noone is any wiser that the transfer is fraudulent. And if the recipient ever wanted to transfer the address at a later date, then without the registry details referring to them as the current address holder then subsequent transfers would be challenging.
Assuming semi-permanent, real estate-like IPv4 market, that might incentivize the recipient to introduce some accurate information into the registration data at the point when a sale is contemplated, but that incentive could still result in a whois that is only reliable for aspiring near-tern address dealer, and s.
So as far as I can see the recipient has a strong motive to have the transfer registered.
From the source's point of view a recognised transfer is of higher value than an unrecognised transfer. Potential address purchasers can be sought openly and the value of the transfer can be realized more effectively - i.e. the source has the ability to realize the full current value of the transfer in an open situation.
Does this positive effect depend on accurate registration and transaction data, or is it produced by any change in registration that signals that the source is a potential address dealer with at least one satisfied (but possible unknown) customer? If this signaling is so beneficial to IPv4 address dealers, is there anything to deter them from manufacturing artificial transactions to enhance their standing, like some eBay sellers do now?
Many of my concerns about the transfer proposals are related to their likely impact on the registration database, so I'd be very grateful for help think through these questions.
Thanks,
Tom
regards,
Geoff
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
- incorporate NIRs, as NIRs are *not* independent resource registries but are part of the APNIC family
- allow LIR members of other RIRs to participate too.
and why /24 given the coming nat (or i would hope nat-pt) wave?
randy
Philip Smith wrote:
I certainly believe that this policy proposal needs to be implemented if APNIC is to remain in its position of registering the use of IPv4 address resources. As we all know, IPv4 address space is already "bought" and "sold" commercially, so this is a first step at actually legitimising these transfers. Transfers without records of these transfers makes it harder for ISPs to trust prefix announcements.
However, I feel the principle of the policy needs to go further:
- incorporate NIRs, as NIRs are *not* independent resource registries
but are part of the APNIC family
- allow LIR members of other RIRs to participate too.
But one small step at a time; I feel this proposal is the correct first step forward...
One aspect of the amended policy which may make it easier to incorporate a wider community of participation in such a framework of recognition of address transfers is the following text:
In order to preserve aggregation capabilities the transfer recipient may notify APNIC that the transferred address may be returned to the unallocated APNIC address pool, and a different address of the same size may be registered to the recipient of the transfer. This option would be available to the recipient of the transferred address, at the discretion of the recipient.
This would allow, for example, an address prefix to be returned to one registry point and an equivalent prefix assigned from another registry point without having to make a series of 'upstream' changes to move the actual address across registry points, whether they may be NIRs, LIRs or other RIRs.
It assumes, however, that there is a certain amount of residual 'liquidity' in the registry pools to achieve this, which is not something which can be assured right now.
regards,
Geoff
Geoff,
A small point on wording and a couple of questions.
[...]
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.
I think it would be clearer to refer to prefix length or block size but not both.
- The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder.
In a message about version 1 of this proposal you stated that you worked "on the principle that what is written in the proposal would be adopted if the policy was to be adopted and what is not written in the proposal would not change if the policy was not to be adopted".
I'd like to clarify what I think the proposal states as I am not sure if I understand the meaning correctly. As I understand it, APNIC membership is open globally without conditions and members have full access to all services[1]. Am I right in reading your proposal to mean that any organisation anywhere in the world could take advantage of this policy and become the recipient of a transfer (if adopted) as long as they take up APNIC membership?
[...]
- The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Regards,
Leo
Leo Vegoda wrote:
Geoff,
A small point on wording and a couple of questions.
[...]
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.I think it would be clearer to refer to prefix length or block size but not both.
could you please suggest some alternative wording here? I must admit that I use these terms interchangeably, so I know what I'm talking about (! :-)) but I can see the potential for confusion here. Is there a way that you can suggest to make this clearer?
- The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder.In a message about version 1 of this proposal you stated that you worked "on the principle that what is written in the proposal would be adopted if the policy was to be adopted and what is not written in the proposal would not change if the policy was not to be adopted".
I'd like to clarify what I think the proposal states as I am not sure if I understand the meaning correctly. As I understand it, APNIC membership is open globally without conditions and members have full access to all services[1].
The reference you cite asserts that, and I'm in no position to contradic tthe referenced NRO document.
Am I right in reading your proposal to mean
that any organisation anywhere in the world could take advantage of this policy and become the recipient of a transfer (if adopted) as long as they take up APNIC membership?
This would be a logical inference of the combination of this policy proposal and the APNIC member conditions you have referenced from the NRO web site.
[...]
- The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Hmmm - I know what I meant to say, but it appears that I have not said it clearly. Let me try to rephrase this, and see if the rephrasing makes the policy proposal clear, or whether you see a need to reword this to make the intent clearer.
Today, a member can make a case for the assignement or allocation of address space from APNIC on the basis of demonstrated need. If a member is the source of an address transfer under the terms of this policy, then APNIC will not undertake any allocations or assignments to this member for a period of 24 months after the transfer.
Now all transfers in the terms of this policy are in effect transfers from a member to a member (or "current APNIC acoucnt holder" under the terms of this policy). The policy is a proposal for APNIC to 'recognise" this transfer and make the appropriate changes to its registry data to reflect this change of right-of-use holder.
So I do not see a distinction betweem address transfers that go directly from member to member or go via APNIC - all transfer that are to be recognised by APNIC under the terms of this policy are in effect transfers from member to member and are recognised by APNIC in its registry.
Regards,
Leo
regards,
Geoff
Hi Geoff,
On 23 Jan 2008, at 10:21, Geoff Huston wrote:
[...]
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.
I think it would be clearer to refer to prefix length or block size but not both.
could you please suggest some alternative wording here? I must admit that I use these terms interchangeably, so I know what I'm talking about (! :-)) but I can see the potential for confusion here. Is there a way that you can suggest to make this clearer?
How about:
- Only IPv4 prefixes of /24 or shorter may be transferred.
[...]
- The source entity will be ineligible to receive any further
IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Hmmm - I know what I meant to say, but it appears that I have not said it clearly. Let me try to rephrase this, and see if the rephrasing makes the policy proposal clear, or whether you see a need to reword this to make the intent clearer.
I think I would phrase it like this.
- An APNIC member that has been the source of a resource transfer may not receive IPv4 resources direct from APNIC or from an APNIC member for 24 months after the completion of the transfer.
Does my phrasing capture your intended meaning?
Can you please explain why you chose 24 months as the length of time a member may not receive IPv4 resources once they have transferred resources away? Why is it more suitable than a shorter or longer period? Also, is it still appropriate if APNIC's stock of unallocated IPv4 address space is emptied within the 24 month period?
Many thanks,
Leo
Leo Vegoda wrote:
Hi Geoff,
On 23 Jan 2008, at 10:21, Geoff Huston wrote:
[...]
APNIC will process IPv4 address transfer requests following the adoption of this proposed policy, subject to the following conditions:
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.
I think it would be clearer to refer to prefix length or block size but not both.
could you please suggest some alternative wording here? I must admit that I use these terms interchangeably, so I know what I'm talking about (! :-)) but I can see the potential for confusion here. Is there a way that you can suggest to make this clearer?
How about:
- Only IPv4 prefixes of /24 or shorter may be transferred.
you know that phrasing is more confusing for me! :-)
[...]
- The source entity will be ineligible to receive any further IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Hmmm - I know what I meant to say, but it appears that I have not said it clearly. Let me try to rephrase this, and see if the rephrasing makes the policy proposal clear, or whether you see a need to reword this to make the intent clearer.
I think I would phrase it like this.
- An APNIC member that has been the source of a resource transfer may not receive IPv4 resources direct from APNIC or from an APNIC member for 24 months after the completion of the transfer.
Does my phrasing capture your intended meaning?
no - the "or from an APNIC member" is something I cannot parse - I'm unclear what you are referring to here.
Can you please explain why you chose 24 months as the length of time a member may not receive IPv4 resources once they have transferred resources away? Why is it more suitable than a shorter or longer period?
What about the situation of a member who receives address space from APNIC, transfers it elsewhere then reapplies to APNIC for for addresses based on the size of their deployed network, transfers them elsewhere, reapplies to APNIC for more addresses... ?
Also, is it still appropriate if APNIC's stock of unallocated IPv4 address space is emptied within the 24 month period?
yes, entirely so!
Geoff
On 23 Jan 2008, at 19:18, Geoff Huston wrote:
[...]
- Only IPv4 address blocks equal to, or larger than, a /24
prefix may be transferred.
I think it would be clearer to refer to prefix length or block size but not both.
could you please suggest some alternative wording here? I must admit that I use these terms interchangeably, so I know what I'm talking about (! :-)) but I can see the potential for confusion here. Is there a way that you can suggest to make this clearer?
How about:
- Only IPv4 prefixes of /24 or shorter may be transferred.
you know that phrasing is more confusing for me! :-)
I'm sure that says something about us but I am not sure what :-)
[...]
- The source entity will be ineligible to receive any further
IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Hmmm - I know what I meant to say, but it appears that I have not said it clearly. Let me try to rephrase this, and see if the rephrasing makes the policy proposal clear, or whether you see a need to reword this to make the intent clearer.
I think I would phrase it like this.
- An APNIC member that has been the source of a resource transfer may not receive IPv4 resources direct from APNIC or from an APNIC member for 24 months after the completion of the transfer.
Does my phrasing capture your intended meaning?
no - the "or from an APNIC member" is something I cannot parse - I'm unclear what you are referring to here.
Maybe this makes more sense?
- An APNIC member that has transferred resources to another APNIC member may not receive IPv4 resources from APNIC or its members for the next 24 months.
I suppose this APNIC member is free to join other RIRs and receive resources from them and their members, though?
Can you please explain why you chose 24 months as the length of time a member may not receive IPv4 resources once they have transferred resources away? Why is it more suitable than a shorter or longer period?
What about the situation of a member who receives address space from APNIC, transfers it elsewhere then reapplies to APNIC for for addresses based on the size of their deployed network, transfers them elsewhere, reapplies to APNIC for more addresses... ?
I understand the problem. I just wonder why 24 months makes more sense that 18 months or 36 months. Does it tie in with something else?
Regards,
Leo
Leo Vegoda wrote:
On 23 Jan 2008, at 19:18, Geoff Huston wrote:
[...]
- Only IPv4 address blocks equal to, or larger than, a /24
prefix may be transferred.
I think it would be clearer to refer to prefix length or block size but not both.
could you please suggest some alternative wording here? I must admit that I use these terms interchangeably, so I know what I'm talking about (! :-)) but I can see the potential for confusion here. Is there a way that you can suggest to make this clearer?
How about:
- Only IPv4 prefixes of /24 or shorter may be transferred.
you know that phrasing is more confusing for me! :-)
I'm sure that says something about us but I am not sure what :-)
I'm going to leave it there! :-)
[...]
- The source entity will be ineligible to receive any further
IPv4 address allocations or assignments from APNIC for a period of 24 months after the transfer.
The meaning of this paragraph depends on whether address transfers go directly from member to member or go via APNIC. I am not sure which is the case but if transfers are direct and do not go via APNIC it would seem that an APNIC member that transferred resources away could go on to receive additional resources from another member but not from APNIC within 24 months. Could you please clarify whether transfers need to go via APNIC?
Hmmm - I know what I meant to say, but it appears that I have not said it clearly. Let me try to rephrase this, and see if the rephrasing makes the policy proposal clear, or whether you see a need to reword this to make the intent clearer.
I think I would phrase it like this.
- An APNIC member that has been the source of a resource transfer may not receive IPv4 resources direct from APNIC or from an APNIC member for 24 months after the completion of the transfer.
Does my phrasing capture your intended meaning?
no - the "or from an APNIC member" is something I cannot parse - I'm unclear what you are referring to here.
Maybe this makes more sense?
- An APNIC member that has transferred resources to another APNIC member may not receive IPv4 resources from APNIC or its members for the next 24 months.
I suppose this APNIC member is free to join other RIRs and receive resources from them and their members, though?
I'm not clear how an APNIC policy can constrain others in such a way. If, for example I have an address allocation from APNIC and I transfer it to you, then I sign up as a customer of Big Provider Inc, an APNIC member, and receive a /28 address block as part of the customer contract then I see no problem here. Are you saying that the policy should constrain Big Provider Inc from making this customer allocation to me?
Can you please explain why you chose 24 months as the length of time a member may not receive IPv4 resources once they have transferred resources away? Why is it more suitable than a shorter or longer period?
What about the situation of a member who receives address space from APNIC, transfers it elsewhere then reapplies to APNIC for for addresses based on the size of their deployed network, transfers them elsewhere, reapplies to APNIC for more addresses... ?
I understand the problem. I just wonder why 24 months makes more sense that 18 months or 36 months. Does it tie in with something else?
It seemed like a suitably long enough time to circumvent the situation described above. It also may well extend to around the point of IPv4 unallocated address pool exhaustion.
regards,
Geoff
Dear Geoff,
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical".
I believe this proposal will play an important role in next few years.
I think these conditions are not clear that transfer part of address block is allowed.
For example, an entity that have /16 can transfer /17 to another entity or entity should transfer whole of /16.
regards, Shin
--- "No caffeine, No work. " Shin Shirahata null@null.nu / true@sfc.wide.ad.jp http://www.sfc.wide.ad.jp/~true/
Shin SHIRAHATA wrote:
Dear Geoff,
Conditions on the IPv4 address block:
- Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred. - The address block must be in the range of addresses administered by APNIC, either as part of a /8 address block assigned by the IANA to APNIC, or as part of a historically-assigned address block now administered by APNIC. - The address block must be allocated or assigned to a current APNIC account holder. - The address block will be subject to all current APNIC policies from the time of transfer. This includes address blocks previously considered to be "historical".I believe this proposal will play an important role in next few years.
I think these conditions are not clear that transfer part of address block is allowed.
For example, an entity that have /16 can transfer /17 to another entity or entity should transfer whole of /16.
It is the intent of this policy proposal that transfer of part of an address is allowed, to a limit of a /24.
Geoff
Hello Shin,
On 29/01/2008, at 7:41 PM, Shin SHIRAHATA wrote:
I think these conditions are not clear that transfer part of address block is allowed.
For example, an entity that have /16 can transfer /17 to another entity or entity should transfer whole of /16.
The proposal speaks of the transfer of address blocks. It makes no mention of allocations. Isn't it reasonably clear that a block being transfered can be a subnet of an allocation that has been made to the transferring entity? There is no wording in the proposal restricting transfers to address blocks aligned with complete APNC allocations.
Thanks
David ...
Hello David,
I think these conditions are not clear that transfer part of address block is allowed.
For example, an entity that have /16 can transfer /17 to another entity or entity should transfer whole of /16.
The proposal speaks of the transfer of address blocks. It makes no mention of allocations. Isn't it reasonably clear that a block being transfered can be a subnet of an allocation that has been made to the transferring entity? There is no wording in the proposal restricting transfers to address blocks aligned with complete APNC allocations.
I'm completely understood.
I think there is discrepancy in interpretation from culturally different background. Because many japanese entitiy thinks "no wording for restricting something" does not means "we can do something".
Thank you for your explanation!
--- "No caffeine, No work." Shin Shirahata null@null.nu / true@sfc.wide.ad.jp http://www.sfc.wide.ad.jp/~true/
Activity Summary
- 5517 days inactive
- 5517 days old
- sig-policy@lists.apnic.net
- 8 participants
- 20 comments