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

[Ted Mittelstaedt]

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.
> 

Dylan,

   For starters your mixing section 4.2 and 4.3 together.  Section 4.2
only applies to ISP's who are reassigning IP numbers they get to 
downstream customers.   Section 4.3 applies to corporations and
businesses that don't reassign and use the numbers for their own
purposes.  That's an extremely important distinction to keep
in mind.

   Secondly, if you can only justify a /23 then your actually better
off "getting another ISP to advertise a competing ISP's space" than
in attempting to get your own /23 or /24, even if this policy is
approved.  The reason why is that while your /23 or /24 would be
a part of the DFZ, it would be so small in comparison to most of
the blocks advertised on the Internet that there's a lot of networks
(particularly running on routers with low ram in them) that will
filter your /23 or /24 out entirely, and just default-route to
one of their upstreams to cover the advertisements smaller than their
filter break.  It is a mistake to assume a /24 is globally visible
in all routers on the Internet, if you spend some time working with
different Looking Glasses (you can find a list on traceroute.org) you
will quickly see that the smaller the advertisement the fewer routers
it appears in.   You may get suboptimal routing if you use a
smaller block that is not part of a supernet, then if you use a
small block that IS part of a supernet.

   Also, your going to quickly find that it's just as difficult to
get a small portable block advertised from those "competing ISP's"
as a small block that's assigned from an ISP.

   The real reason you should want a portable /24 or /23 is
because you don't trust your upstream ISP's any further than you
could spit a rat, and your worried that at some point they may
pull them.  For example, back in 2004, MCI pulled out of North America
and all customers who had numbers assigned from them were forced to 
renumber - and they had quite a lot of ISP's as customers.  If this
is a concern then you should want your own numbers.  But, if your
just wanting them because you think it will be easier to get an
upstream to advertise them, your going to be disappointed.

Ted


> 
> 
> 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.