Re: [sig-policy] prop-050: IPv4 address transfers
The potted summary I sent as an attachment to my reply to Professor
Hwang covers the discussions about the pros and cons of this very issue. :-)
philip
--
Yi Chu said the following on 16/8/09 12:02 :
> Geoff/Philip:
> Why would we require justification on the recipient while we still have some available IPv4 resources now, while totally give up when we are really out of resource?
>
> I prefer black and white, either we require justification or we do not. Tying to 'final /8' just muddles the water, IMHO.
>
> yi
>
>
>
> ----- Original Message ----
> From: Randy Bush <randy at psg dot com>
> To: Policy SIG <sig-policy at apnic dot net>
> Sent: Friday, July 24, 2009 8:28:36 AM
> Subject: [sig-policy] prop-050: IPv4 address transfers
>
> Dear SIG members,
>
> The proposal, 'IPv4 address transfers', has been sent to the Policy SIG
> for review. It will be presented at the Policy SIG at APNIC 28 in
> Beijing, China, 25-28 August 2009. The proposal's history can be found
> at:
>
> http://www.apnic.net/policy/proposals/prop-050
>
> 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, Jian, and Ching-Heng
>
>
>
> ________________________________________________________________________
>
> prop-050-v005: IPv4 address transfers
> ________________________________________________________________________
>
>
> Authors: Geoff Huston
> gih at apnic dot net
>
> Philip Smith
> pfs at cisco dot com
>
> Version: 5
>
> Date: 24 July 2009
>
>
> This proposal contains the transfer proposal features that reflect the
> points of general agreement demonstrated on the APNIC Policy SIG
> mailing list in the period May - July 2009.
>
>
> 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 does not propose to refine the existing APNIC historical
> resource transfer policy, as it is intended to apply 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 2011 and 2012. 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.
>
> The underlying proposition behind this policy proposal is that 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, and the integrity of the
> network itself is thereby compromised. 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.
>
> 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
>
> The proposal does not prescribe how such transfers may occur, nor
> impose any further constraints on the transfer or on the parties
> involved other than those described in this proposal.
>
>
> 3. Situation in other RIRs
> ----------------------------
>
> RIPE has implemented a transfer policy in its region. See section 5.5,
> "Transfers of Allocations", of:
>
> IPv4 Address Allocation and Assignment Policies for the RIPE NCC
> Service Region
> http://www.ripe.net/ripe/docs/ripe-449.html#55
>
>
> On 1 June 2009, ARIN implemented:
>
> 2009-1: Transfer Policy
> https://www.arin.net/policy/proposals/2009_1.html
>
>
> LACNIC is currently discussing a transfer proposal:
>
> LAC-2009-04 Transfer of IPv4 Blocks within the LACNIC Region
> http://www.lacnic.net/documentos/politicas/LAC-2009-04-propuesta-en.pdf
>
>
> AfriNIC currently has no similar policy or proposal under discussion.
>
>
> 4. Details of the proposal
> ----------------------------
>
> APNIC will process and record IPv4 address transfer requests between
> current APNIC account holders following the adoption of this proposed
> policy, subject to the following conditions. APNIC will maintain a
> public log of all transfers made under this policy.
>
>
> Conditions on the IPv4 address block:
>
> - The minimum transfer size is a /24
>
> - The address block must be in the range of addresses 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.
>
>
> 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 12
> months after the transfer, or until the exhaustion of APNIC's
> IPv4 space (i.e. until the commencement of the use of the "final
> /8" resources), whichever occurs first.
>
> - Under exceptional circumstances a member may submit an
> application for further assignments or allocations earlier than
> the expiration of this period. The APNIC Secretariat will monitor
> these exceptional requests carefully and publish comprehensive
> statistics on a regular basis. Without identifying any member
> organization, these statistics will record the numbers of
> requests and the outcome, the economy that the requests come
> from and clearly identify if any member has made more than one
> request under this provision.
>
>
> 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 the efficient utilization of all IPv4 address
> space held, including all transferred resources.
>
> - Prior to the exhaustion of APNIC's IPv4 space (i.e. prior to the
> use of the "final /8" allocation measures) recipients of
> transfers will be required to justify their need for address
> space. After this time there is no requirement for any form of
> evaluation of requirements for eligibility.
>
>
> Applicability to NIRs:
>
> - NIRs have the choice as to when to adopt this policy for their
> members (i.e. members of NIRs)
>
>
> Implementation:
>
> - This proposal is to take effect as soon as the APNIC Secretariat
> implement the mechanisms of the policy following the completion
> of all steps of the Policy Development Process.
>
>
> 5. Advantages and disadvantages of the proposal
> -------------------------------------------------
>
> 5.1 Advantages
>
> This proposal:
>
> - Ensures that the APNIC registry continues to reflect the current
> actual status of IPv4 resource holdings by APNIC account holders.
>
> - Mitigates the risks to the integrity of the network, and its
> routing and addressing infrastructure in particular, associated
> with the unregistered transfers of IPv4 addresses.
>
> - Provides 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 reuse
>
> 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 reclamation 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.
>
> 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 recognize 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
> -------------------
>
> As APNIC account holders, NIRs will have the ability to register
> transfers of addresses with other APNIC account holders upon adoption
> of this proposal.
>
> The proposal allows for NIRs to have the choice as to when to adopt
> this policy for their members. Members of NIRs will have the ability
> to register transfers of addresses when individual NIRs implement this
> transfer policy.
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>