[arin-ppml] New IPv4 Transfer policy

Mon May 9 16:04:37 EDT 2011

I may have missed something here, but why is it not possible to dump LSRA
and have all transfers..whether LSRA, RSA. or  neither...become a mandatory
RSA signing on transfer ? with a note to the effect: "Note that ARIN will
not reclaim unutilized  v4 address space from legacy holders.

RD

>
> Date: Mon, 9 May 2011 15:15:06 -0400
> From: "Mike Burns" <mike at nationwideinc.com>
>
> Hello,
>
> Upon feedback to my first draft proposal whose intent is to lift needs
> requirements for all IPv4 transfers, I have made some changes to my draft
> proposal.
>
> One of the issues was the idea that if I made no changes to section 12,
> that ARIN could do a resource review of the transferree and if they
> determined the addresses were not being used, could request them to be
> returned.
>
> I have read section 12 of the NRPM, and could find no language that gives
> ARIN that right. Basically section 12 is about fraud and about compliance
> with existing policy, but there is no existing policy that I could find
> requiring anything like efficient utilization of allocations, except in
> reference to a new or subsequent allocation. But once an allocation is made,
> I could find no policy requiring efficient utilization of that block if no
> further allocation request is made.
>
> On the other hand, the current RSA has clear language in section 8 that
> allows ARIN to review previous allocations and allows ARIN to determine if
> their use is consistent with the intended purpose as presented on the
> application at the time of the allocation request:
>
> 8. REVIEW OF APPLICANT'S NUMBER RESOURCES
> ARIN may review, at any time, Applicant's use of previously allocated or
> assigned number resources or Services received from ARIN to determine if
> Applicant is complying with this Agreement and the Policies and is using the
> Services for their intended purposes. Without limiting the foregoing, if
> Applicant is a holder of a direct allocation or assignment from ARIN,
> Applicant agrees that it will use the number resources solely for uses
> consistent with its application and this Agreement, including, for example,
> its internal infrastructure or to provide Internet access to its customer
> base. If ARIN determines that the number resources or any other Services are
> not being used in compliance with this Agreement, the Policies, or the
> purposes for which they are intended, ARIN may: (i) revoke the number
> resources; (ii) cease providing the Services to Applicant; and/or (iii)
> terminate this Agreement.
>
> (To my reading, if you got an allocation in 2001 for web hosting purposes,
> and now you are using the addresses to provide DSL service, ARIN could
> revoke them for not being used for purposes consistent with the Applicant's
> application unless you notify them and get approval. But let's leave that
> aside.)
>
> Since my overarching purpose is to bring as much supply into the market as
> possible, I don't want any old allocations to stay unused on the shelf
> because the holder is afraid of a recovery action.
>
> But if section 12 does not allow ARIN to make a resource finding requesting
> return of addresses merely for underutilization, and if we remove the
> language in the RSA allowing ARIN to recover based on compliance with
> intended use, then an entity could totally fake a justification and get a
> new allocation today, and turn around tomorrow and list the addreses for
> sale, and ARIN wouldn't have any teeth with which to revoke the addresses.
> (Unless of course they could show the justification part of the application
> was fraudulent.)
>
> In order to preclude that, I have added a new source requirement to the
> source entity for transfers, that they may not have received an ARIN
> allocation for at least 12  months prior to the transfer.
>
> In addition, in my new draft proposal I retained the 8.2 transfer
> mechanism, which can still be used for ASN and IPv6 transfers via mergers
> and acquisitions.
>
> I also added language forcing no downgrading of current agreement status
> which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or
> RSA, no agreement to no agreement or LRSA.
>
> In my rationale, I have limited myself to the benefits of whois accuracy
> which will inure from the greater likelihood that all past and future
> transfers will be registered.
>
> >From the discussion, you know that I believe that stewardship demands that
> we make policy to ensure whois reliablity in the face of a new paradigm for
> IPv4 distribution. IPv4 addresses will change hands in a variety of
> transaction types. If those who engage in these transactions do not choose
> to have ARIN update whois to reflect them, we run the risk of whois
> irrelevance and provide the vacuum in to which competitive registries will
> step, with or without global community authority.  If transactors find
> little cost in having ARIN update whois to reflect the transfer, they are
> more likely to request that ARIN make the update. If the transaction cost is
> high, fewer will make that request, leading to a less and less reliable
> whois, which could degrade to the point where network operators choose a
> more reliable registry. This kind of chaos in the core of the Internet would
> be an indictment of ARIN stewardship.
>
> We will run out of free pool addresses shortly. At that point we will not
> be stewards of those addresses anymore. We will, however, retain our
> stewardship role towards maintaining whois as an authoritative source for
> routing authority. Prior to exhaust, it was possible to ignore whois, as
> conflicts over address control were unlikely when "free" addresses were
> available. In the post-exahaust world, where address control conflict is
> likely to increase, it is all the more important that whois be a trusted and
> accurate information source.
>
> Now it could be that I have misread section 12, I know I heard from more
> than one person that ARIN could revoke for underutilization. If you can
> point me to what I am missing, then maybe I will have to monkey with section
> 12. My hope is that by simply changing 8.3 and the RSA I can avoid that.
>
> I agree with John Curran's posting this week about simplifying transfer
> requirements, and have retained the /24 minimum for the reasons he
> mentioned.
>
> Regards,
>
> Mike Burns
>
> 1. Policy Proposal Name: New IPv4 Transfer policy
>
> 2. Proposal Originator:
>      a. Name: Mike Burns
>      b. Email: mike at sum.net
>      c. Phone: 1-863-494-7692 x105
>      d. Organization: Nationwide Computer Systems
>
> 3. Proposal Version: 1
>
> 4. Date: May 9th, 2011
>
> 5. Proposal type: modify
>
> 6. Policy term: permanent
>
> 7. Policy statement:
>
> Replace Section 8.3 with
>
> 8.3 ARIN will process and record IPv4 address transfer requests.
>
> 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 ARIN
>
> Conditions on source of the transfer:
>
>    - The source entity must be the current rights 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 ARIN for a period of 12
>      months after the transfer, or until the exhaustion of ARIN's
>      IPv4 space, whichever occurs first.
>
>       - The source entity must not have received an allocation from ARIN
> for the 12 months prior to the transfer.
>
>
>  Conditions on recipient of the transfer:
>
>    - The recipient entity must be a current ARIN account holder.
>      If the addresses being transferred are under RSA, the recipient must
> sign an RSA with ARIN.
>      If the addresses being transferred are under LRSA, the recipient must
> sign an LRSA or an RSA with ARIN.
>      If the addresses being transferred are legacy addresses under no form
> of RSA, recipient may choose to sign an LRSA, but will not be required to do
> so.
>
>    - The recipient entity of the transferred resources will be subject
>      to current ARIN policies. In particular, in any subsequent ARIN
>      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.
>
>
> and modify section 12.8 of the current RSA to remove references to
> "intended purposes."
>
> Replace
> ARIN may review, at any time, Applicant's use of previously allocated or
> assigned number resources or Services received from ARIN to determine if
> Applicant is complying with this Agreement and the Policies and is using the
> Services for their intended purposes.  Without limiting the foregoing, if
> Applicant is a holder of a direct allocation or assignment from ARIN,
> Applicant agrees that it will use the number resources solely for uses
> consistent with its application and this Agreement, including, for example,
> its internal infrastructure or to provide Internet access to its customer
> base. If ARIN determines that the number resources or any other Services are
> not being used in compliance with this Agreement, the Policies, or the
> purposes for which they are intended, ARIN may: (i) revoke the number
> resources; (ii) cease providing the Services to Applicant; and/or (iii)
> terminate this Agreement.
>
> with
>
> ARIN may review, at any time, any Applicant's use of previously allocated
> or assigned number resources or Services received from ARIN to determine if
> Applicant is complying with this Agreement and the Policies.  Without
> limiting the foregoing, if Applicant is a holder of a direct allocation or
> direct assignment from ARIN, Applicant agrees that it will use the number
> resources solely for uses consistent with this Agreement, including, for
> example, its internal infrastructure or to provide Internet access to its
> customer base. If ARIN determines that the number resources or any other
> Services are not being used in compliance with this Agreement or the
> Policies, ARIN may: (i) revoke the number resources; (ii) cease providing
> the Services to Applicant; and/or (iii) terminate this Agreement.
>
>
>
>
>
> 8. Rationale:
>
> Current ARIN 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, or to those who agree to
> sign either an RSA or LRSA with ARIN and subject the buyer
> to needs analysis and the seller to a potential ARIN review under RSA
> section 8.
>
> It is currently anticipated that the IPv4 unallocated address pool
> will be exhausted within a couple of years at ARIN, and earlier
> than that in other regions, and the  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 ARIN 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 ARIN address
> registry by allowing the registry to record transactions where IPv4
> addresses are transfered between ARIN account holders.
>
> It proposes that ARIN will recognise and register a transfer of
> addresses where the parties to the transfer are 'known' to ARIN and
> that the address block being transferred is part of ARIN's current 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.
>
> 9. Timetable for implementation: immediate.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 71, Issue 99
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110509/d5d5d738/attachment.htm>