[arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title

Owen DeLong owen at delong.com
Thu Jan 21 16:43:43 EST 2010


On Jan 21, 2010, at 1:35 PM, Dylan Ebner wrote:

> Please correct me if I am interpreting this wrong. I am reading this as saying this policy will now allow multi-homed users to acquire a /24 or /23 from ARIN. Does this supersede the /22 minimum requirement for all end-users today or only apply to multi-homed end-users, i.e., non multi-homed will still need to apply for /22s? What if a user is already multi-homed, can they still apply for a /24 or /23? 
> If I could get a /23 or /24 I would be in heaven. We are multi-homed today behind 2 ISPs and we have to get our /24s from our ISP's ip space. That makes a lot of hoops to jump through to get another ISP to advertise a competing ISPs space.
> 
Today, non-multihomed still need to qualify for a /20 (NRPM 4.3.2.1).

This policy does not seek to change anything for non-multihomed end users.

So, in answer to your final question, you would be able to use this policy if it is
adopted to get the space you need.

Owen

> 
> 
> Dylan Ebner, Network Engineer
> Consulting Radiologists, Ltd.
> 1221 Nicollet Mall, Minneapolis, MN 55403
> ph. 612.573.2236     fax. 612.573.2250
> dylan.ebner at crlmed.com
> www.consultingradiologists.com
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Thursday, January 21, 2010 3:18 PM
> To: arin ppml
> Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum Assignment Unit - Correct Title
> 
> **Apologies - resending with correct title**
> 
> 
> Draft Policy 2010-2
> /24 End User Minimum Assignment Unit
> 
> On 15 January 2010 the ARIN Advisory Council (AC) selected "/24 End User
> Minimum Assignment Unit" as a draft policy for adoption discussion on
> the PPML and at the Public Policy Meeting in Toronto in April.
> 
> The draft was developed by the AC from Policy Proposal "99. /24 End User
> Minimum Assignment Unit". Per the Policy Development Process the AC
> submitted text to ARIN for a staff and legal assessment prior to its
> selection as a draft policy. The AC subsequently revised the text as
> follows:
> 
> "Summary of changes:
> 1. Removed last sentence of section 4.3.2.2, per staff recommendation.
> 
> 2. Added "4.3" to section 4.3.6.2 resulting in "...return all
> existing 4.3 assignments...", per staff recommendation.
> 
> 3. Change title for section 4.3.6.2, per staff recommendation."
> 
> Below the draft policy is the ARIN staff and legal assessment, including
> the original proposal text.
> 
> Draft Policy 2010-2 is below and can be found at:
> https://www.arin.net/policy/proposals/2010_2.html
> 
> You are encouraged to discuss Draft Policy 2010-2 on the PPML prior to
> the April Public Policy Meeting. Both the discussion on the list and
> at the meeting will be used by the ARIN Advisory Council to determine
> the community consensus for adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2010-2
> 24 End User Minimum Assignment Unit
> 
> Version/Date: 21 January 2010
> Policy statement:
> 
> Replace section 4.3.2.2 of the NRPM with the following:
> 
> 4.3.2.2 Multihomed Connection
> 
> For multi-homed end-users who demonstrate an intent to announce the
> requested space in a multihomed fashion to two or more distinct ASNs not
> owned or controlled by the end-user, the minimum block of IP address
> space assigned is a /24. If assignments smaller than a /24 are needed,
> multihomed end-users should contact their upstream providers. When
> prefixes are assigned which are longer than /20, they will be from a
> block reserved for that purpose so long as that is feasible.
> 
> Renumber the existing paragraph under the 4.3.6 to
> 
> 4.3.6.1 Utilization requirements for additional Assignment
> 
> Add the following paragraph 4.3.6.2
> 
> 4.3.6.2 Additional assignments for small multi-homers
> 
> Any end-user that possesses an assignment smaller than /22 under any
> part of section 4.3 shall not be able to get an additional assignment
> unless they agree to return all existing 4.3 assignments within 12
> months of receiving a new assignment. The new assignment shall be sized
> to accommodate their existing utilization in addition to their justified
> additional growth space under section 4.3.6.1. The common cases for this
> are expected to be a /24 returned after receipt of a /23, or a /23
> returned after receipt of a /22.
> 
> Rationale:
> 
> This policy attempts to incorporate the recent and historical
> discussions of policy for multi-home users on PPML. The intent is to
> provide as fair a process as possible for multi-homed organizations down
> to the smallest feasible size while still preserving some control over
> growth in the routing table.
> 
> It has been repeatedly noted that /24 multi-homers exist today with PA
> space and still occupy a routing table slot, so, it is unlikely that
> moving this boundary to /24 would significantly impact the routing table.
> 
> By requiring smaller assignments to renumber and return, rather than add
> more small blocks to their assignments, this policy seeks to further
> reduce the chances of unnecessary growth in the routing table and
> encourage good aggregation where possible.
> 
> Does this apply only to end users? Yes, this policy applies only to end
> users. This policy does not represent a good solution for organizations
> that are delegating space to other entities. If a case can be made that
> such a policy is needed for ISPs, then, the author is happy to work with
> interested parties to craft such a policy, but, this policy would be
> unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat
> onerous to their peers and/or upstream providers.
> 
> What about resources obtained from policies other than 4.3 or outside of
> ARIN? Such resources would not be counted for excluding an organization
> from this policy. The intent is to limit IPv4 micro-allocations for
> multi-homed end-user organizations under this policy to a single
> assignment unless each such assignment is /22 or larger. This is to
> prevent unnecessary routing table growth. This is a tradeoff, and, not
> the ideal solution for smaller end-user organizations, however, author
> believes that this is the best policy likely to gain consensus at this
> time and believes that it is incrementally far better for such
> organizations than current policy.
> 
> If I grow, I have to renumber? Not necessarily... If you have a /24
> under this policy, and you want to grow that, then, you will likely need
> to renumber. Depending on ARIN resource management and timing, ARIN may
> simply be able to give you the /23 that includes your /24. More likely,
> you will get a new /23, have 1 year to renumber into that and return
> your /24. At most, you would be subject to two such renumbering cycles
> under this policy (24->23 and 23->22) before you meet the criteria for
> other policies which do not require renumbering.
> 
> Other policies don't include renumbering provisions, why this one? The
> policy which allows multi-homed organizations to get a /22 was
> originally written at /24. That policy was shouted down and /22 was the
> compromise achieved to gain community consensus for anything smaller
> than /20. Author hopes that this compromise will allow many
> organizations to get resources they need with minimal impact while
> assuring the community that doing so will not cause an explosion in the
> routing table.
> 
> Timetable for implementation: Immediate
> 
> 
> #####
> 
> 
> STAFF ASSESSMENT
> 
> Proposal: /24 End User Minimum Assignment Unit
> 
> Proposal Version: Updated by AC and given to staff for assessment on 29
> Dec 2009
> 
> Date of Assessment: 12 January 2010
> 
> 1. Proposal Summary (Staff Understanding)
> 
> ARIN staff understands this policy would lower the minimum assignment
> size for a multi-homed end-user to a /24. End-users who have assignments
> of less than /22 from ARIN can only qualify for additional space under
> this policy if they agree to renumber out of their previous
> assignment(s) and return that space to ARIN within 12 months. The
> standard 25% immediate/50% one-year utilization requirements would
> continue to apply.
> 
> 2. Comments
> 
> A. ARIN Staff Comments
> 
> 1. The policy text uses inconsistent terminology when it refers to
> prefix sizes; it says "blocks smaller than /24" and "when prefixes are
> assigned which are longer than /20". The terminology should be adjusted
> so that it uses the same terminology for cidr prefixes consistently
> throughout the policy.
> 2. The criteria as stated in 4.3.6.2 are unclear, particularly in
> relation to end users who have previous address space from ARIN. Staff
> suggests that the author make the following changes for clarification
> purposes:
> * Remove the last sentence of 4.3.2.2 that starts with "End-users may not".
> * In section 4.3.6.2, insert the section number 4.3 so that it now
> reads, "unless they agree to return all existing 4.3 assignments within
> 12 months". This will make it clearer that only existing assignments
> from ARIN issued under the end user policy (NRPM 4.3) are to be returned.
> 3. The title of section 4.3.6.2 "Replacement Assignments for Small
> Multihomers" would be clearer if it were changed to "Additional
> Assignments for Small Multihomers". This section specifically deals
> with small multihomers who want additional space and agree to return
> existing space. The requirement to return space is already detailed
> within the policy text. This title would also be more consistent with
> the existing style and terminology used in NRPM.
> 
> 
> B. ARIN General Counsel
> 
> "This policy poses no significant legal issues that need to be
> considered".
> 
> 3. Resource Impact
> 
> This policy would have minimal resource impact. It is estimated that
> implementation would occur within 3 months after ratification by the
> ARIN Board of Trustees. The following would be needed in order to 
> implement:
> 
> * Changes to guidelines
> * Staff training
> 
> Proposal Text: /24 End User Minimum Assignment Unit
> 
> Replace section 4.3.2.2 of the NRPM with the following:
> 
> 4.3.2.2 Multihomed Connection
> For multi-homed end-users who demonstrate an intent to announce the
> requested space in a multihomed fashion to two or more distinct ASNs not
> owned or controlled by the end-user, the minimum block of IP address
> space assigned is a /24. If assignments smaller than a /24 are needed,
> multihomed end-users should contact their upstream providers. When
> prefixes are assigned which are longer than /20, they will be from a
> block reserved for that purpose so long as that is feasible. End-users
> may not receive a block smaller than /22 under this policy if they
> already have IPv4 resources from ARIN, except as specified in section
> 4.3.6.2.
> 
> Renumber the existing paragraph under the 4.3.6 to
> 4.3.6.1 Utilization requirements for additional Assignment
> 
> Add the following paragraph 4.3.6.2
> 
> 4.3.6.2 Replacement assignments for small multi-homers
> Any end-user that possesses an assignment smaller than /22 under any
> part of section 4.3 shall not be able to get an additional assignment
> unless they agree to return all existing assignments within 12 months of
> receiving a new assignment. The new assignment shall be sized to
> accommodate their existing utilization in addition to their justified
> additional growth space under section 4.3.6.1. The common cases for this
> are expected to be a /24 returned after receipt of a /23, or a /23
> returned after receipt of a /22.
> 
> Rationale:
> This policy attempts to incorporate the recent and historical
> discussions of policy for multi-home users on PPML. The intent is to
> provide as fair a process as possible for multi-homed organizations down
> to the smallest feasible size while still preserving some control over
> growth in the routing table.
> It has been repeatedly noted that /24 multi-homers exist today with PA
> space and still occupy a routing table slot, so, it is unlikely that
> moving this boundary to /24 would significantly impact the routing table.
> 
> By requiring smaller assignments to renumber and return, rather than add
> more small blocks to their assignments, this policy seeks to further
> reduce the chances of unnecessary growth in the routing table and
> encourage good aggregation where possible.
> Does this apply only to end users? Yes, this policy applies only to end
> users. This policy does not represent a good solution for organizations
> that are delegating space to other entities. If a case can be made that
> such a policy is needed for ISPs, then, the author is happy to work with
> interested parties to craft such a policy, but, this policy would be
> unnecessarily onerous on ISPs, and, as an ISP policy could be somewhat
> onerous to their peers and/or upstream providers.
> 
> What about resources obtained from policies other than 4.3 or outside of
> ARIN? Such resources would not be counted for excluding an organization
> from this policy. The intent is to limit IPv4 micro-allocations for
> multi-homed end-user organizations under this policy to a single
> assignment unless each such assignment is /22 or larger. This is to
> prevent unnecessary routing table growth. This is a tradeoff, and, not
> the ideal solution for smaller end-user organizations, however, author
> believes that this is the best policy likely to gain consensus at this
> time and believes that it is incrementally far better for such
> organizations than current policy.
> 
> If I grow, I have to renumber? Not necessarily... If you have a /24
> under this policy, and you want to grow that, then, you will likely need
> to renumber. Depending on ARIN resource management and timing, ARIN may
> simply be able to give you the /23 that includes your /24. More likely,
> you will get a new /23, have 1 year to renumber into that and return
> your /24. At most, you would be subject to two such renumbering cycles
> under this policy (24->23 and 23->22) before you meet the criteria for
> other policies which do not require renumbering.
> 
> Other policies don't include renumbering provisions, why this one? The
> policy which allows multi-homed organizations to get a /22 was
> originally written at /24. That policy was shouted down and /22 was the
> compromise achieved to gain community consensus for anything smaller
> than /20. Author hopes that this compromise will allow many
> organizations to get resources they need with minimal impact while
> assuring the community that doing so will not cause an explosion in the
> routing table.
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.




More information about the ARIN-PPML mailing list