[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] [Sig-policy][Draft announcement]prop-050: IPv4 addresstransfers
Hi, I have two clarification question about this proposal.
1. Is it correct in assuming historical resouces currently under APNIC
is also *included* in the scope for the transfer?
Was a little confused by the phrase "(non-historical)"below:
----
It proposes that APNIC will recognise and register a transfer of
addresses where the parties to the transfer are 'known' to APNIC and
that the address block being transferred is part of APNIC's current
(non-historical) address set
-----
2. Does this proposal seek to allow inter-RIR transfers if it reaches
consensus in other RIRs as well?
Looking forward to confirm the answers.
thanks,
izumi
zhangjian wrote:
>
>
> Dear SIG members
>
>
>
> An updated version of the proposal 'IPv4 address transfers' has been sent to
> the Policy SIG for review. It will be presented at the Policy SIG at APNIC
> 26 in Christchurch, New Zealand, 25-29 August 2008.
>
>
>
> The proposal's history can be found at:
>
>
>
> http://www.apnic.net/policy/proposals/prop-050-v003.html
>
>
>
>
>
> This new version of the proposal has expanded commentaries in sections 2 and
> 5. Section 3 now includes a reference to the transfer proposal under
> discussion in the ARIN region.
>
>
>
> 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
> express your views on the proposal:
>
>
>
> - Do you support or oppose this proposal?
>
>
>
> - Does this proposal solve a problem you are experiencing? If so,
>
> tell the community about your situation.
>
>
>
> - Do you see any disadvantages in this proposal?
>
>
>
> - Is there anything in the proposal that is not clear?
>
>
>
> - What changes could be made to this proposal to make it more
>
> effective?
>
>
>
> randy and jian
>
>
>
> ________________________________________________________________________
>
>
>
> prop-050-v003: IPv4 address transfers
>
> ________________________________________________________________________
>
>
>
>
>
>
>
> Author: Geoff Huston
>
> gih@apnic.net
>
>
>
> Version: 3
>
>
>
> Date: 22 July 2008
>
>
>
>
>
> 1. Introduction
>
> ----------------
>
>
>
> This is a proposal to amend 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.
>
>
>
> The underlying assumptions behind this policy proposal are:
>
>
>
> - There will continue to be need for additional IPv4 address
>
> resources in the AP region after the exhaustion of the APNIC
>
> IPv4 unallocated address pool
>
>
>
> - The amount of returned address space to APNIC will not meet
>
> those needs
>
>
>
> - Some IPv4 address holders will be in a position to release
>
> address space and convert to NAT or similar solutions if they
>
> are given some level of incentive
>
>
>
> - Some amount of transfer of address space will occur in the
>
> APNIC region following the exhaustion of the unallocated IPv4
>
> address pool
>
>
>
> - The registry of IPv4 addresses operated by APNIC is of general
>
> utility and value only while it accurately describes the current
>
> state of address distribution. If a class of address movement
>
> transactions are excluded from being entered in the registry,
>
> then the registry will have decreasing value to the broader
>
> community.
>
>
>
> This proposal's central aim is to ensure the continuing utility and value of
> the APNIC address registry by allowing the registry to record transactions
> where IPv4 addresses are transfered between APNIC account holders.
>
>
>
>
>
>
> The proposal does not:
>
>
>
> - Prescribe how such transfers may occur, nor
>
>
>
> - Impose any further constraints on the transfer or on the parties
>
> involved.
>
>
>
>
>
>
>
> 3. Situation in other RIRs
>
> ----------------------------
>
>
>
> Proposals for address transfers similar to this proposal are being discussed
> at the following RIRs:
>
>
>
> RIPE
>
>
>
> 2007-08: Enabling Methods for Reallocation of IPv4 Resources
>
> http://www.ripe.net/ripe/policies/proposals/2007-08.html
>
>
>
>
>
> ARIN
>
>
>
> Policy Proposal 2008-2: IPv4 Transfer Policy Proposal
>
> http://www.arin.net/policy/proposals/2008_2.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,
>
> and subject to availablility of an alternate address block from
>
> APNIC
>
>
>
> 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
>
> -------------------------------------------------
>
>
>
> 5.1 Advantages
>
>
>
> 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. In particular, it
> 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 in particular, associated with the
>
> unregistered transfers of IPv4 addresses.
>
>
>
> - 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.
>
>
>
>
>
> 5.2 Disadvantages (and responses)
>
>
>
>
>
> 5.2.1 Altering the traditional concepts of IP addresses
>
>
>
> This proposal has the potential to alter a number of traditional
>
> preconceptions relating to addresses and their value, including
>
> challenging the concept that addresses are not in and of
>
> themselves assets and addresses do no in and of themselves have
>
> monetary value outside of the narrow constraints of use in
>
> networks for routing and end point identification. Changing these
>
> common percpetions about addresses and their use opens up the
>
> potential for a number of responses, including:
>
>
>
> - The loss of strong aggregation capability in the address space,
>
> with the consequent load being imposed on the routing system.
>
>
>
> - The significant shift away from a universal need-based address
>
> allocation model in the underlying policy framework.
>
>
>
> - The treatment of addresses as property with the associated legal
>
> ramifications in terms of corporate and contract law.
>
>
>
> - The imposition of taxes on addresses and their movement.
>
>
>
> - The potential for unfairness and inequities to be realized in
>
> terms of access to addresses for use by network service
>
> providers.
>
>
>
> Response:
>
>
>
> A number of factors mitigate the risks above:
>
>
>
> - As the transition to IPv6 gathers pace, any residual value
>
> of IPv4 addresses would fall in line with the decreasing
>
> value proposition of IPv4-based services in an increasing
>
> IPv6 network.
>
>
>
> - If this policy were to be adopted while IPv4 addresses are
>
> still available from APNIC, APNIC's established IPv4 address
>
> allocation process would continue to provide an alternative
>
> source of supply of IPv4 addresses to the industry.
>
>
>
>
>
> 5.2.2 Proposal diverts attention from address reclamation and resuse
>
>
>
> It has been argued that the proposal diverts attention from policy
>
> development that encourages IP address reclamation and reuse.
>
>
>
> Response:
>
>
>
> To date the level of return and reclamation of addresses has
>
> been minimal. Aside from price-based mechanisms it is unclear
>
> that further policy refinement would alter this situation.
>
>
>
> Even if policy development encouraged address reclamation and
>
> reuse, there is the distinct possibility that the amount
>
> reclaimed addresses would be smaller than the amount needed
>
> for APNIC to continue to allocate addresses on a needs-basis
>
> after the unallocated address pool has been exhausted.
>
>
>
> An open and significant issue is how APNIC could fairly ration
>
> limited addresses when faced with a much larger set of
>
> demands. In other words, concentrating on relamation and reuse
>
> policies rather than transfer policies also contains
>
> significant issues that may prove challenging to resolve as a
>
> policy matter.
>
>
>
>
>
> 5.2.3 Potential for APNIC to be cast as a regulator
>
>
>
> If APNIC adopted this policy, APNIC may be cast as a regulator
>
> of a secondary market in addresses. Concerns have been expressed
>
> that APNIC has no experience, expertise nor the authority to
>
> enforce regulatory actions. Such a role may also expose APNIC to
>
> additional litigation.
>
>
>
> Response:
>
>
>
> This proposal does not advocate such a role for APNIC. The
>
> scope of this policy is explicitly limited to the conditions
>
> that would allow APNIC to recognise and record a transfer of
>
> addresses in its registry.
>
>
>
> There is a general belief that adoption of this policy would
>
> act as an incentive for a market in addresses. However, that
>
> does not imply that markets would act outside existing
>
> regulatory structures. Nor does it mean that market
>
> participants would be immune from existing regulatory measures
>
> within their respective regimes.
>
>
>
> The potential for additional liabilities associated with this
>
> policy should be the subject of legal review by an
>
> appropriately qualified party.
>
>
>
>
>
> 5.3 Summary of comments on transfer proposals
>
>
>
> There are a number of views of this that have been noted in the various
> policy discussions on this topic in the various RIR policy forums. The APNIC
> policy proposal is broadly similar to a policy proposal under consideration
> in RIPE, which is referred to here as a "minimal' policy for address
> transfers. The address transfer proposal currently under consideration in
> ARIN has a larger set of constraints to be applied to determine if a
> transfer would be recognised by the registry. A summary of the discussion of
> the differences in these policy proposals follows.
>
>
>
>
>
> 5.3.1 In favor of a 'minimal' policy
>
>
>
> - The policy places APNIC in the role of a 'title office' for
>
> addresses, and ensures that APNIC, as a registry operator, is
>
> neutral in terms of the means used by APNIC members to determine
>
> that they wish to proceed with a transfer of addresses. As long
>
> as the criteria for a valid transfer are met, by whatever means
>
> agreed to by the parties involved, then the registry should
>
> allow the transaction to be duly recorded.
>
>
>
> - APNIC has no practical operational experience in the area of
>
> enforcing various constraints on parties as to how and why
>
> addresses may be transferred, and does not currently have any
>
> recognized authority to do so. Making policy in the absence of
>
> a well understood and commonly accepted authority model calls
>
> into question the legitimacy and authority of outcome.
>
>
>
> - Regulation is a well understood and familiar concept in many, if
>
> not all, regimes. If there is a general desire to place
>
> constraint and regulate the actions of parties who wish to
>
> undertake a transfer of addresses, then it may be preferred to
>
> do so in the context of a broader framework that involves other
>
> bodies and authorities that have a greater level of experience
>
> and authority in this area of activity, and leverage from
>
> existing regulatory structures and enforcement mechanisms. In
>
> this manner the policy proposal does not attempt to create a
>
> novel, and potentially superfluous additional regulatory
>
> framework.
>
>
>
> - APNIC has no experience in determining what actions by potential
>
> parties to a transfer may need to be constrained in some
>
> fashion. Attempting to create policy in anticipation of the need
>
> for such constraints is going to be a guessing game that has
>
> accompanying flaws, Irrespective of what constraints are
>
> initially specified in policy, it will be the case that as the
>
> levels of experience in this form of activity increases some
>
> iterations over the policy of constraints will be necessary in
>
> any case. This approach argues to start from a position that is
>
> relatively open and unrestricted, and recommend that APNIC
>
> impose additional constraints only when all other forms of
>
> constraint are inapplicable and there is a clear need and common
>
> desire for such constraints to be enforced by APNIC as distinct
>
> from using another party for such a role.
>
>
>
>
>
> 5.3.2 In favour of applying a greater level on constraint in the policy
>
>
>
> - APNIC has no practical operational experience in address
>
> transfers, so we should take incremental steps form the current
>
> position rather than a complete relaxation of the entire set of
>
> constraints associated with the existing allocation
>
> framework. Recipients of a transfer should be qualified by the
>
> registry on the basis of demonstrated need in the same fashion
>
> as recipient of address allocations today. Address blocks should
>
> not be arbitrarily fragmented. Timing constraints should be
>
> applied to stop transfers of addresses occurring that are
>
> primarily motivated by reasons other than immediate need for use
>
> in deployed networks.
>
>
>
> - Constraints that are generally considered to be onerous and
>
> unnecessary can always be removed at a later date, while
>
> applying and enforcing additional constraints at a later date
>
> will prove to be a far harder task.
>
>
>
> - There are a number of technical risks associated with address
>
> trading. Unconstrained deaggregation will lead to a fracture of
>
> the routing system due to unconstrained and large scale
>
> expansion of the inter-domain routing table. This is an
>
> irreversible state.
>
>
>
> 5.3.3 Discussions of the emergence of a market
>
>
>
> The various comments made on this and the related address
>
> transfer policy proposals provides grounds for the observation
>
> that there is a general perception that the recognition of
>
> address transfers leads to a de facto recognition of the
>
> emergence of a market or markets for IPv4 addresses. A related
>
> topic of discussion about the merits or otherwise of these
>
> proposals has been the consideration of the relative merits and
>
> risks of market behaviours when applied to this situation.
>
>
>
> The comments opposed to the emergence of markets include the
>
> following:
>
>
>
> - Markets in addresses are an inevitable consequence of a
>
> transfer policy, and unconstrained markets are prone to a
>
> number of risks of distortion. These risks include deceptive
>
> trading, margin trading, trading in market derivatives and
>
> futures, hoarding, and speculation. The utility of an address
>
> as a token for addressing a packet is devalued in a market
>
> situation.
>
>
>
> - Operation of a market will lock out all but the largest of
>
> players in the network from access to further addresses, as the
>
> value of the address will be set by the bidder with the highest
>
> price and the ability to exploit the address to its maximal
>
> extent.
>
>
>
> - The operation of a market in IPv4 addresses will lead to the
>
> erosion of the effectiveness of self-imposed policies in IPv6,
>
> and may lead to the emergence of a market in IPv6 addresses.
>
>
>
> - Markets are unfair in terms of the implicit bias of a market in
>
> favour of those parties who are in a position to set the market
>
> price, and inherently discriminating against those parties who
>
> do not have the capacity to pay. In an international context
>
> this is counter to the general objective of a generally
>
> available, neutral and non-discriminatory communications
>
> infrastructure.
>
>
>
>
>
> Comments in favour of the emergence of a market in IPv4 addresses
>
> include:
>
>
>
> - Address exhaustion poses an insoluble problem to the address
>
> registries in that for as long as there is a continuing demand
>
> for addresses the registries have no means to meet that demand.
>
> Markets create a means for addresses to be recycled, and create
>
> a means for the various levels of demand and supply of
>
> addresses in IPv4 to reach a balance through a market-based
>
> pricing mechanism.
>
>
>
> - At every stage there is always an alternative to bidding for
>
> IPv4 addresses in the context of a market transaction: namely
>
> the use of IPv6 within the network, and the use of an upstream
>
> protocol translation service to provide legacy access to other
>
> IPv4 networks. Given that substitutes exist, the potential
>
> price of IPv4 addresses in a market is capped by the cost of
>
> deployment of IPv6 and IPv4 transitional mechanisms.
>
>
>
> - This is a temporary measure during the dual stack phase of
>
> IPv6
>
> transition. The higher the market price for IPv4 addresses the
>
> greater the cost pressure placed on the industry to undertake
>
> the IPv6 transition, which in turn limits the lifetime of the
>
> market and the speculative potential of any such market.
>
> Players will have an incentive to act quickly in terms of
>
> releasing address resources into such a market given that
>
> withholding for too long will result in no return as the market
>
> will naturally terminate once IPv6 transition has reached a
>
> critical deployment mass.
>
>
>
>
>
> It should be noted that this address transfer policy proposal is
>
> mute on the topic of a market for address transfers, and neither
>
> advocates nor specifically opposes the emergence of any such
>
> market or markets. The policy constrains itself to enumeration of
>
> the set of constraints that would apply for APNIC to recognise
>
> and register a transfer of addresses between APNIC members. How
>
> those parties arrived at the decision to undertake the transfer,
>
> and the related issues concerning property, financial and legal
>
> frameworks and the emergence of markets, the need to regulate
>
> such markets and identification of the market regulator are
>
> specifically not encompassed by this policy proposal, nor does
>
> this proposal advocate that such a role be undertaken by APNIC.
>
>
>
>
>
> 6. Effect on APNIC members
>
> ----------------------------
>
>
>
> APNIC members will have the ability to register the transfer of IPv4 address
> resources between APNIC members.
>
>
>
>
>
> 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.
>
>
>
> _______________________________________________
>
> Sig-policy-chair mailing list
>
> Sig-policy-chair@apnic.net
>
> http://mailman.apnic.net/mailman/listinfo/sig-policy-chair
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> * 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
