[ppml] Policy Proposal: PIv6 for legacy holders with RSA andefficient use
Scott Leibrand
sleibrand at internap.com
Mon Jul 30 16:30:34 EDT 2007
Leroy Ladyzhensky wrote:
>
> Having to move to IPv6 will encourage all Legacy holders to sign RSA's
> if they want IPv6 IP's. there is no way around this. And
> if they can meet the current standard requirements... to bad... or
> change the policy for all of us.
>
> But allowing them to bend the rules and get special treatment is
> another thing... why do they need incentive when eventually they will
> have no choice in the future?
Yes, they will need to sign an RSA to cover their new IPv6
allocation/assignment, but AFAIK they don't have to bring their IPv4
space under RSA, or demonstrate efficient use of their existing IPv4
space. Those are the activities that this policy proposal would incent.
>
> PLEASE NOTE: Before everyone get the idea that I am bashing Legacy
> holders.. and "lets get the big stick out and beat their butts red..."
> that is not the case.. its just this particular proposal that is a
> slap in the face for all others that would like ARIN ip's but cannot
> meet the usage requirements.
Where do you see the un-met demand for PI space, on the v4 or v6 side,
or evenly across both? Would it be useful, in your opinion, to make
IPv6 PI requirements less stringent than those for IPv4?
-Scott
>
>
> ----- Original Message ----- From: "Scott Leibrand"
> <sleibrand at internap.com>
> To: "Leroy Ladyzhensky" <leroy at emailsorting.com>
> Cc: <ppml at arin.net>
> Sent: Monday, July 30, 2007 3:10 PM
> Subject: Re: [ppml] Policy Proposal: PIv6 for legacy holders with RSA
> andefficient use
>
>
>> Leroy,
>>
>> For what it's worth, I don't personally have any legacy blocks, and
>> never have. I was in high school when ARIN was created, and my
>> current employer was a brand new startup still getting PA space at
>> the time.
>>
>> My own take is that it is in the community's interest to encourage
>> transition to IPv6, encourage legacy holders to formalize their ARIN
>> relationship with an RSA, and to encourage the reclamation of unused
>> IPv4 space. As stated in the Rationale, this policy was proposed for
>> those reasons.
>>
>> If you feel that this proposal violates the community's interest in
>> fairness, and that outweighs the other interests outlined above, I
>> respect your opinion and will agree to disagree on that point. I
>> just want to make sure you understand that this proposal was made
>> with those community interests in mind, not based on any self interest.
>>
>> -Scott
>>
>> P.S. I would also be in favor of a proposal to liberalize PI
>> requirements generally, provided it addresses previously voiced
>> concerns about assignments to non-legitimate organizations (like
>> "spammers") and to a lesser extent routing table explosion.
>>
>> Leroy Ladyzhensky wrote:
>>> My take on this, and I am really trying to be nice, is.....
>>>
>>> This policy is clearly motivated by self interests and not for the
>>> better of all....
>>>
>>> There are plenty of good honest people and businesses out there that
>>> would love to be provider independent..
>>> but since they cannot meet the requirement for IP usage they are not
>>> eligible for IP block from ARIN, and thus are locked into their
>>> ISP.
>>>
>>> So just because a Legacy holder got one way back in the beginning
>>> entitles them to do it again with IPv6, when they are unable to meet
>>> the current IPv6 requirements?
>>>
>>> If this were to pass my faith in the fairness of ARIN would be
>>> rocked to the core.
>>>
>>> Leroy L.
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Member Services" <info at arin.net>
>>> To: <ppml at arin.net>
>>> Sent: Monday, July 30, 2007 1:23 PM
>>> Subject: [ppml] Policy Proposal: PIv6 for legacy holders with RSA
>>> andefficient use
>>>
>>>
>>>
>>>> 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 a formal policy 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. Postpone their decision regarding the proposal until the next
>>>> regularly scheduled AC meeting in order to work with the author.
>>>> The AC
>>>> will work with the author to clarify, combine or divide the
>>>> proposal. At
>>>> their following meeting the AC will accept or not accept the proposal.
>>>>
>>>> 3. Not accept the proposal. If the AC does not accept the proposal,
>>>> the AC will explain their decision. 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 will assign shepherds in the near future. ARIN will provide the
>>>> names of the shepherds to the community via the PPML.
>>>>
>>>> In the meantime, 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: PIv6 for legacy holders with RSA and
>>>> efficient use
>>>>
>>>> Author: Scott Leibrand
>>>>
>>>> Proposal Version: 1.0
>>>>
>>>> Submission Date: 7/28/2007
>>>>
>>>> Proposal type: new
>>>>
>>>> Policy term: permanent
>>>>
>>>> Policy statement:
>>>>
>>>> Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user
>>>> organizations: Criteria), to read:
>>>>
>>>> To qualify for a direct assignment, an organization must:
>>>>
>>>> 1. not be an IPv6 LIR; and
>>>> 2. qualify for an IPv4 assignment or allocation from ARIN under the
>>>> IPv4 policy currently in effect, or demonstrate efficient
>>>> utilization of a direct IPv4 assignment or allocation covered
>>>> by a
>>>> current ARIN RSA.
>>>>
>>>> Rationale:
>>>>
>>>> Current policy allows direct IPv6 allocations and assignments to
>>>> nearly
>>>> all organizations with IPv4 allocations or assignments from ARIN.
>>>> As a
>>>> result, such organizations can get IPv6 space just as easily as
>>>> they can
>>>> get IPv4 space, making it easy for them to transition to IPv6 as
>>>> soon as
>>>> they're ready to do so. However, there are some organizations who
>>>> received IPv4 /23's and /24's prior to the formation of ARIN, and use
>>>> that space in a multihomed, provider-independent fashion. Under
>>>> current
>>>> policy, such organizations cannot get IPv6 PI space without
>>>> artificially
>>>> inflating host counts, and are therefore discouraged from adopting
>>>> IPv6.
>>>> This policy proposal aims to remove this disincentive, and allow such
>>>> organizations to easily adopt IPv6.
>>>>
>>>> In addition, pre-ARIN assignments were issued through an informal
>>>> process, and many legacy resource holders have not yet entered into a
>>>> formal agreement with ARIN, the manager of many such IP numbering
>>>> resources. This policy proposal would require that such
>>>> assignments be
>>>> brought under a current ARIN Registration Services Agreement, thereby
>>>> formalizing the relationship.
>>>>
>>>> Some pre-ARIN assignments may not be used efficiently. As unallocated
>>>> IPv4 numbering resources are approaching exhaustion, it is
>>>> important to
>>>> ensure efficient utilization of IPv4 assignments, and to arrange for
>>>> reclamation of unused space. Therefore, this policy would require
>>>> that
>>>> the organization wishing to receive IPv6 PI space demonstrate
>>>> efficient
>>>> utilization of their IPv4 assignment. (Efficient utilization is
>>>> already
>>>> defined elsewhere in policy, and the exact mechanism for achieving and
>>>> determining efficient use is a matter of procedure, not of policy, so
>>>> detailed procedures are not included in the policy statement
>>>> above. The
>>>> intent is that any organization with an assignment of /23 or larger
>>>> which is less than 50% utilized would renumber and return whole unused
>>>> CIDR blocks as necessary to bring the remaining CIDR block to 50%
>>>> utilization or higher. A /24 should be considered efficiently
>>>> utilized
>>>> as long as it is in use for multihoming, as /25's and smaller are not
>>>> routable for that purpose.)
>>>>
>>>> It has been suggested that this policy would be useful only until the
>>>> growth of IPv6 exceeds the growth of IPv4. I would agree with this,
>>>> and would further posit that the existing "qualify ... under the IPv4
>>>> policy currently in effect" language should also be modified at that
>>>> time. I have therefore proposed this policy with a policy term of
>>>> "permanent", with the expectation that this section of policy
>>>> (6.5.8.1)
>>>> will be rewritten at the appropriate time to entirely remove all IPv4
>>>> dependencies.
>>>>
>>>> Timetable for implementation: immediate
>>>>
>>>> _______________________________________________
>>>> This message sent to you through the ARIN Public Policy Mailing List
>>>> (PPML at arin.net).
>>>> Manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/ppml
>>>>
>>>>
>>>
>>> _______________________________________________
>>> This message sent to you through the ARIN Public Policy Mailing List
>>> (PPML at arin.net).
>>> Manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/ppml
>>>
>>
>
More information about the ARIN-PPML
mailing list