Re: [sig-policy] [Sig-policy][Draft announcement]prop-050: IPv4 addresst
A few last minutes comment before the meeting...
### WARNING: it's long ###
We undertand this proposal restricts APNIC's role to updating DB
registrations. However, we believe implications and issues outside DB
update must be also considered before implementing this policy.
Our understanding of this proposal is that it implies to allow trading
of IP address between LIRs which is likely to involve monetary exchange.
We've listed possible issues below:
1. Change in the nature of IP address/IP address distribution
- IP adress may be considered an "asset" or "property" rather than
a resource
- This proposal implies that there are no longer needs to
demonstrate the needs in receiving address space. This
leads to inconsistency that those who receive the space via APNIC
must demonstrate the needs and those who receive it via transfer
don't need to do so. It may result in those who do not
necessarily need address space are eligible to receive it for
financial reasons
(We understand too strict a criteria would lead to black market,
but perhaps there should be checks in some form to prevent
hoarding)
2. Social implications as a result of allowing transfer
- IP address holdings may be subject to taxation for LIRs as well
as APNIC. Impact of such change is not properly analyzed
- APNIC may get caught in legal disputes over adress holdings and
transfers and restricting APNIC's role to DB update in the policy
may not be effective enough as a protection
We also had some discusssion in JP-OPM and major comments received were
as follows:
- Those who trade in black markets always chose the easiest way -
therefore, even if this policy is implemented, they will likely to
move address space between themselves without going through the
official procedure
- Some form of demonstration of needs should be required to prevent
address hoarding
- simply register them as assignments rather than treat it as
transfer of allocations. this will allow to achieve the goal
without fundamental changes in the policy
(issues on this methods were also discussed)
izumi
JPNNIC
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 at apnic dot 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.
>
>
>
> 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.
>
>
>
>
>
>
>
> 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 at apnic dot net
>
> http://mailman.apnic.net/mailman/listinfo/sig-policy-chair
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> * 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