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

[Dylan Ebner]

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