[ppml] Policy Proposal: IPv4 Transfer Policy Proposal
Bill Darte
BillD at cait.wustl.edu
Tue Feb 12 08:23:35 EST 2008
The intent of the modified transfer policy is to provide order in the
interim between now, through IPv4 exhaustion and toward a pervasive IPv6
adoption.
As has been stated before, the AC was not in favor of this policy as a
singular effort. It was in context of a number of suggestions that
would provide stability and promote migration and the acceptance that
transfers will take place in the future to meet needs. The AC chose to
make this proposal to begin a concrete dialog about this issue in the
ARIN region and to prescribe a means to mitigate an uncoordinated and
unjustified transfer system...one that is likely to exhibit most of the
bad characteristics of unregulated exchanges of limited resources.
It is easy to misuse the term 'buying' of resources when discussing this
policy. It is not a policy that accepts that IP addresses will become
property, nor that acquisition of number resources will take place
outside of justification by whichever source (free pool or transfer).
Bill Darte
ARIN AC
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
> Behalf Of Ted Mittelstaedt
> Sent: Monday, February 11, 2008 6:37 PM
> To: Member Services; ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>
>
> I have some concerns with this proposal.
>
> This policy seems to undermine the idea that IP addressing is
> assigned on the basis of proving need. It lends credibility
> to the idea that IP addressing is property, and could open
> the door to any number of lawsuits based on this. For
> example if an organization "purchases" IPv4 they could then
> file a lawsuit against a large provider which decided to
> block access from that purchased block, claiming
> discriminatory behavior.
>
> Is there any reason that extending the lifetime of IPv4 will
> be of any benefit to the Internet community? It seems that
> the projected runout date is now well after all network
> operating systems, both router and host-based, will be IPv6 compliant.
>
> By contrast, it has been said repeatedly that the uptake of
> new addressing is so fast that any schemes to "mine" IPv4
> from legacy holders who aren't using it, or any other
> sources, would be nothing more than a drop in the bucket, and
> thus, not worth pursuing. Furthermore, every day that passes
> increases the number of hosts on the Internet, thus the
> sooner that IPv4 is abandonded the fewer hosts will need to
> be renumbered and the less work will be required to switch to it.
>
> This is also at odds with the ARIN board's statement that
> organizations need to switch to IPv6 at
> http://www.arin.net/v6/v6-resolution.html
> rather than try extending IPv4. Specifically:
>
> "...Board of Trustees hereby requests the ARIN Advisory
> Council to consider Internet Numbering Resource Policy
> changes advisable to encourage migration to IPv6 numbering
> resources where possible...."
>
> is in direct contrast to:
>
> "...We (the AC) are proposing some changes to existing ARIN
> policy regarding the transfer of IP address block
> registrations between subscribers, which will allow for the
> emergence of trade in IPv4 address space, with ARIN to
> provide a listing service for address blocks available for
> transfer under the liberalized policy...."
>
> I will grant the AC's contention that the emergence of a
> trade in IPv4 is inevitable. I think though that ARIN needs
> to take the high road and stay out of the grimy, gross, and
> messy mechanisms that such a trade may entail. If an
> organization comes to ARIN demanding as a result of a "buy"
> that they "deserve" such and such a block of IP numbers is
> "theirs" then I see no benefit to the Internet community for
> deviating from the standard mechanism of requiring the
> "buyer" to submit the SAME justification for new IP
> addressing that any other submitter would have to provide,
> and issuing IPv4 using the same criteria. If that results in
> a denial or some or all of the IP allocation the "buyer" is
> requesting, then that is the gamble that the "buyer" has to
> take. As for a mechanism to get the same numbers as the
> "buyer" claims they "bought", that sort of thing is what we
> pay ARIN to do for us - there is no reason that the details
> of any internal resevation system ARIN might have for this
> needs to be brought out into policy. I would prefer to give
> the ARIN staff free-hand as to how to solve these on a
> case-by-case basis - as they have now, as they used when
> Cable & Wireless abandonded their North American IP holdings,
> etc. etc. etc.
>
>
> Ted
>
> >-----Original Message-----
> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On
> Behalf Of
> >Member Services
> >Sent: Monday, February 11, 2008 8:35 AM
> >To: ppml at arin.net
> >Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> >
> >
> >Resending with a typo that has been corrected in 8.4.2 below. The
> >original text is supposed to have "24 months" twice in that section.
> >
> >Member Services
> >American Registry for Internet Numbers (ARIN)
> >
> >
> >
> >
> >ARIN received the following policy proposal. In accordance with the
> >ARIN Internet Resource Policy Evaluation Process, the
> proposal is being
> >posted to the ARIN Public Policy Mailing List (PPML) and
> being placed
> >on ARIN's website.
> >
> >The ARIN Advisory Council (AC) will review this proposal at
> their next
> >regularly scheduled meeting. The AC may decide to:
> >
> > 1. Accept the proposal as written. If the AC accepts the
> proposal,
> >it will be posted as a formal policy proposal to PPML and it will be
> >presented at a Public Policy Meeting.
> >
> > 2. Not accept the proposal. If the AC does not accept the
> proposal,
> >the AC will explain their decision via the PPML. If a
> proposal is not
> >accepted, then the author may elect to use the petition process to
> >advance their proposal. If the author elects not to petition or the
> >petition fails, then the proposal will be closed.
> >
> >The AC shepherds for this proposal are Scott Leibrand and
> Stacy Taylor.
> >
> >The AC invites everyone to comment on this proposal on the PPML,
> >particularly their support or non-support and the reasoning behind
> >their opinion. Such participation contributes to a thorough
> vetting and
> >provides important guidance to the AC in their deliberations.
> >
> >The ARIN Internet Resource Policy Evaluation Process can be found at:
> >http://www.arin.net/policy/irpep.html
> >
> >Mailing list subscription information can be found at:
> >http://www.arin.net/mailing_lists/
> >
> >Regards,
> >
> >Member Services
> >American Registry for Internet Numbers (ARIN)
> >
> >
> >## * ##
> >
> >
> >Policy Proposal Name: IPv4 Transfer Policy Proposal
> >
> >Author: ARIN Advisory Council
> >
> >Proposal Version: 1.0
> >
> >Submission Date: 02/07/2008
> >
> >Proposal type: modify
> >
> >Policy term: permanent
> >
> >Policy statement:
> >
> >Replace the current NRPM section 8 with the following --
> >
> >8. Transfers
> >
> >[8.1. Transfers - retain as is:
> >
> >Number resources are non-transferable and are not assignable to any
> >other organization unless ARIN has expressly and in writing
> approved a
> >request for transfer. ARIN is tasked with making prudent
> decisions on
> >whether to approve the transfer of number resources.
> >
> >It should be understood that number resources are not "sold"
> under ARIN
> >administration. Rather, number resources are assigned to an
> >organization for its exclusive use for the purpose stated in the
> >request, provided the terms of the Registration Services Agreement
> >continue to be met and the stated purpose for the number resources
> >remains the same. Number resources are administered and assigned
> >according to ARIN's published policies.
> >
> >Number resources are issued, based on justified need, to
> organizations,
> >not to individuals representing those organizations. Thus,
> if a company
> >goes out of business, regardless of the reason, the point of contact
> >(POC) listed for the number resource does not have the authority to
> >sell, transfer, assign, or give the number resource to any
> other person
> >or organization. The POC must notify ARIN if a business fails so the
> >assigned number resources can be returned to the available pool of
> >number resources if a transfer is not requested and justified.]
> >
> >
> >[8.2 - remove the word "only", and retitle to "M&A Transfer
> Requirements":
> >
> >8.2. M&A Transfer Requirements
> >
> >ARIN will consider requests for the transfer of number
> resources upon
> >receipt of evidence that the new entity has acquired the
> assets which
> >had, as of the date of the acquisition or proposed reorganization,
> >justified the current entity's use of the number resource.
> Examples of
> >assets that justify use of the number resource include, but are not
> >limited to:
> >
> > * Existing customer base
> > * Qualified hardware inventory
> > * Specific software requirements.]
> >
> >
> >[8.3 - retitle to "M&A Transfer Documentation Requirements":
> >
> >8.3. M&A Transfer Documentation Requirements
> >
> >In evaluating a request for transfer, ARIN may require the
> requesting
> >organization to provide any of the following documents, as
> applicable,
> >plus any other documents deemed appropriate:
> >
> > * An authenticated copy of the instrument(s) effecting
> the transfer
> > of assets, e.g., bill of sale, certificate of merger,
> contract,
> > deed, or court decree
> > * A detailed inventory of all assets utilized by the requesting
> > party in maintaining and using the number resource
> > * A list of the requesting party's customers using the number
> >resource.
> >
> >If further justification is required, the requesting party
> may be asked
> >to provide any of the following, or other supporting
> documentation, as
> >applicable:
> >
> > * A general listing of the assets or components acquired
> > * A specific description of acquisitions, including:
> > o Type and quantity of equipment
> > o Customer base
> > * A description of how number resources are being utilized
> > * Network engineering plans, including:
> > o Host counts
> > o Subnet masking
> > o Network diagrams
> > o Reassignments to customers]
> >
> >8.4. Requirements for Simple Transfer of IPv4 Addresses
> >
> >After the exhaustion of the IANA IPv4 free pool, ARIN will
> also process
> >IPv4 address transfer requests subject to the following conditions.
> >
> >8.4.1 Conditions on the transferor:
> >
> > * The transferor resides in the ARIN service area.
> > * The transferor has signed an RSA and/or a legacy RSA
> covering the
> > IPv4 addresses transferred.
> > * The transferor has no outstanding balances with ARIN.
> > * The transferor has not received any IPv4 allocations or
> > assignments from ARIN (through ordinary allocations or
> > assignments, or through this Simple Transfer policy)
> within the
> > preceding 24 months.
> > * The transferor may not request any IPv4 allocations
> or assignments
> > from ARIN (through ordinary allocations or
> assignments, or through
> > this Simple Transfer policy) within the subsequent 24 months.
> >
> >8.4.2 Conditions on the transferee:
> >
> > * The transferee resides in the ARIN service area and
> intends to use
> > the transferred IPv4 addresses within the ARIN service area.
> > * The transferee has no outstanding balances with ARIN.
> > * The transferee's need is confirmed by ARIN, according
> to current
> > ARIN policies, including but not limited to confirmation of
> > utilization rate of any prior IPv4 allocations,
> assignments, or
> > previously transferred IPv4 addresses held by the transferee.
> > * The transferee signs (or has previously signed) an
> RSA covering
> > the IPv4 addresses transferred.
> > * The transferee has not provided any IPv4 addresses
> for transfer
> > through this Simple Transfer process within the preceding 24
> > months.
> > * The transferee may not provide any IPv4 addresses for transfer
> > through this Simple Transfer process within the subsequent 24
> > months, except in the case of business failure.
> > * The transferee may only receive one IPv4 address
> transfer every 6
> > months.
> >
> >
> >
> >8.4.3 Conditions on the IPv4 address block to be transferred:
> >
> > * The IPv4 block must comply with applicable ARIN requirements,
> > including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4.,
> > 4.3.2., 4.3.6.). However, an IPv4 allocation or
> assignment of /24
> > or larger, but smaller than the current minimum
> allocation size,
> > may be transferred as a whole resource, but may not
> be subdivided.
> > * The IPv4 block must currently be registered for use within the
> > ARIN service area, either as part of an address block
> assigned by
> > IANA to ARIN, or as part of a legacy address block allocated
> > within the ARIN service area.
> > * There must exist no dispute as to the status of the
> IPv4 block or
> > regarding the allocation or assignment of such block to the
> > transferor.
> > * The transferor may retain one contiguous address range out of
> > their original allocation or assignment for their own use, and
> > transfer the other contiguous address range. If the
> address range
> > to be transferred consists of multiple non-aggregatable CIDR
> > blocks, each may be transferred to a different
> transferee. The
> > retained address range may not be further subdivided or
> > transferred for a period of 12 months.
> >
> >8.4.4 Fees
> >
> > * Completion of a transfer requires payment of a transfer fee
> > according to ARIN's schedule of fees.
> > * The transferee will be subject to all future ARIN
> membership and
> > service fees according to the transferee's total
> address holdings.
> >
> >8.4.5 Pre-qualification
> >
> > * An interested transferee must seek pre-qualification
> from ARIN to
> > confirm its eligibility to receive a transfer (including
> > satisfaction of need according to current ARIN
> policies) before
> > making any solicitation for transfer. Upon pre-qualification,
> > ARIN will provide the transferee with documentation of the
> > pre-qualification, including the size (CIDR prefix
> length) of the
> > largest IPv4 address block the transferee is eligible
> to receive,
> > and the expiration date of the pre-qualification.
> > * An interested transferor must seek pre-qualification
> from ARIN to
> > confirm its eligibility to offer a transfer (including lack of
> > outstanding balances and having signed an RSA) before offering
> > IPv4 address resources for transfer. Upon
> pre-qualification, ARIN
> > will provide the transferor with documentation of the
> > pre-qualification, including the exact network
> address and size
> > (CIDR prefix length) the transferor is eligible to
> provide, and
> > the expiration date of the pre-qualification.
> >
> >8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer
> >Process
> >
> >IPv4 address resources being made available for transfer shall be
> >exempt from ARIN audit until expiration of the transfer
> >pre-qualification or completion of the transfer. In the
> event that a
> >transfer pre-qualification expires, ARIN shall have up to 90 days to
> >initiate an audit prior to this exemption being reinstated through
> >subsequent transfer pre-qualification. This will not extend
> the end of the exemption.
> >
> >8.6. Simple IPv4 Transfers to or from Organizations Under Common
> >Ownership or Control
> >
> >If an IPv4 transferor or transferee is under common ownership or
> >control with any other organization that holds one or more
> IPv4 blocks,
> >the IPv4 transfer request must report all such organizations under
> >common ownership or control.
> >
> >When evaluating compliance with IPv4 Simple Transfer
> conditions, ARIN
> >may consider a transferor's transfer request in light of
> requests from
> >other organizations under common ownership or control with the
> >transferor. Similarly, ARIN may consider a transferee's request in
> >light of requests from other organizations under common ownership or
> >control with the transferee. In evaluating requests from other
> >organizations under common ownership or control, ARIN staff will
> >consider the relationship between the organizations, the degree of
> >coordination between the organizations, and the bona fide use of the
> >addresses at issue to determine whether all appropriate
> conditions are met.
> >
> >8.7. Record-keeping and Publication of Simple Transfers of IPv4
> >Addresses
> >
> >ARIN will develop and operate a listing service to assist interested
> >transferors and transferees by providing them a centralized
> location to
> >post information about IPv4 blocks available from prequalified
> >transferors and IPv4 blocks needed by prequalified transferees.
> >
> >After completion of the transfer, ARIN will update the registration
> >records pertaining to the IPv4 block at issue. ARIN will adjust its
> >records as to the holdings of the transferor and transferee.
> >
> >After the transfer, ARIN will publish WHOIS data that reflects the
> >current allocation or assignment of the transferred block.
> ARIN will
> >also make available information about any prior recipient(s) of such
> >block. ARIN will also publish a log of all transfers,
> including block,
> >transferor, transferee, and date.
> >
> >
> >Rationale:
> >
> >The ARIN Board of Trustees asked the Advisory Council to
> consider a set
> >of questions around the depletion of the free pool of IPv4
> addresses,
> >the transition to IPv6 for Internet address needs in the future, and
> >ARIN's possible role in easing the transition.
> >
> >Over the past few years the AC has spent a great deal of time
> >reflecting on these issues as a group, as individuals, and in
> >consultation with the community. One outcome of this process is this
> >policy proposal, which the AC is submitting for consideration at the
> >next meeting. We are proposing some changes to existing ARIN policy
> >regarding the transfer of IP address block registrations between
> >subscribers, which will allow for the emergence of trade in IPv4
> >address space, with ARIN to provide a listing service for address
> >blocks available for transfer under the liberalized policy. We are
> >aware that this proposal, if adopted, will mark a major
> change in ARIN's role in the community and the Internet.
> >
> >This policy proposal would create a transfer mechanism for
> IPv4 number
> >resources between those who have excess resources and those
> who have a
> >need, thereby allowing ARIN to continue to serve its mission
> after IANA
> >free pool exhaustion. This proposal would also set
> conditions on such
> >transfers intended to preserve as much as possible the
> existing policy
> >related to efficient, needs-based resource issuance, and
> would leverage
> >ARIN's extensive control systems, audit trails, and
> recognized position
> >as a trusted agent to avoid speculation and hoarding and
> diminish the
> >likelihood and extent of an uncontrolled 'black market'
> where the risk
> >and potential for fraud is immeasurably higher.
> >
> >Many of the transfer conditions are self-explanatory, but some worth
> >highlighting are that:
> >
> > * To discourage speculation, a waiting period (proposed at 24
> > months) is required before a transferee (or ordinary resource
> > recipient) can become a transferor, or vice versa.
> > * Transferees must qualify for IPv4 space (just as they do today
> > when getting it from ARIN) before they can receive
> address space
> > by transfer, or solicit space on a listing service.
> > * To discourage unnecessarily rapid growth of routing tables, an
> > allocation or assignment may not be arbitrarily
> deaggregated. To
> > allow a transferor to downsize within their existing
> space, they
> > may split off a contiguous address range, once every
> 12 months,
> > and transfer the resulting netblock(s), which are subject to
> > ARIN's minimum allocation size, to one or more transferee(s).
> > * A transferee may receive one transfer every 6 months,
> so they'll
> > be incented to transfer a block appropriately sized for their
> > needs, which will further discourage deaggregation and keep
> > smaller blocks available for smaller organizations.
> >
> >The proposal would also have ARIN develop and operate a
> listing service
> >to facilitate transfers and provide an authoritative central
> source of
> >information on space available and requested for transfer. It would
> >not prohibit private party transactions, but would require that
> >potential transferors and transferees be pre-qualified
> first, so that
> >neither party will encounter any unexpected surprises when they ask
> >ARIN to process the transfer.
> >
> >Timetable for implementation: Immediately, with most aspects
> of policy
> >taking effect upon IANA exhaustion, per the policy text.
> >
> >
> >
> >
> >_______________________________________________
> >PPML
> >You are receiving this message because you are subscribed to
> the ARIN
> >Public Policy Mailing List (PPML at arin.net).
> >Unsubscribe or manage your mailing list subscription at:
> >http://lists.arin.net/mailman/listinfo/ppml
> >Please contact the ARIN Member Services Help Desk at
> info at arin.net if
> >you experience any issues.
> >
> >
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at
> info at arin.net if you experience any issues.
>
More information about the ARIN-PPML
mailing list