[arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted
On Fri, Feb 11, 2011 at 5:27 PM, Randy Carpenter <rcarpen at network1.net> wrote:
> Does anyone know how the fees will work once this is in place?
> An example is that we have a /48 at our main site, and have 2 remote sites now, and possibly more in the future. Under this new policy, we would qualify for a /44. We are an end-user, so we paid the fee for the /48 upfront, and just pay the maintenance fee. The initial fee is the same for a /48 or /44. If the policy were in place before, we would have just gotten the /44 to begin with. Do we have to pay the fee again to expand the /48 into a /44 ?
> ----- Original Message -----
>> On 11 January 2011 the ARIN Board of Trustees adopted the following
>> Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria
>> This policy will be be implemented no later than 30 April 2011.
>> Board of Trustees Meeting Minutes are available at:
>> Draft Policy and Policy Proposal texts are available at:
>> The ARIN Policy Development Process can be found at:
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> ## * ##
>> Draft Policy ARIN-2010-8
>> Rework of IPv6 assignment criteria
>> Version/Date: 23 November 2010
>> Policy statement:
>> Replace section 6.5.8 as follows;
>> 6.5.8. Direct assignments from ARIN to end-user organizations
>> 184.108.40.206 Initial Assignment Criteria
>> Organizations may justify an initial assignment for addressing
>> directly attached to their own network infrastructure, with an intent
>> for the addresses to begin operational use within 12 months, by
>> one of the following criteria:
>> a. Having a previously justified IPv4 end-user assignment from ARIN
>> one of its predecessor registries, or;
>> b. Currently being IPv6 Multihomed or immediately becoming IPv6
>> Multihomed and using an assigned valid global AS number, or;
>> c. By having a network that makes active use of a minimum of 2000
>> addresses within 12 months, or;
>> d. By having a network that makes active use of a minimum of 200 /64
>> subnets within 12 months, or;
>> e. By providing a reasonable technical justification indicating why
>> addresses from an ISP or other LIR are unsuitable.
>> Examples of justifications for why addresses from an ISP or other LIR
>> may be unsuitable include, but are not limited to:
>> • An organization that operates infrastructure critical to life
>> or the functioning of society can justify the need for an assignment
>> based on the fact that renumbering would have a broader than expected
>> impact than simply the number of hosts directly involved. These would
>> include: hospitals, fire fighting, police, emergency response, power
>> energy distribution, water or waste treatment, traffic management and
>> control, etc…
>> • Regardless of the number of hosts directly involved, an
>> can justify the need for an assignment if renumbering would affect
>> or more individuals either internal or external to the organization.
>> • An organization with a network not connected to the Internet can
>> justify the need for an assignment by documenting a need for
>> uniqueness, beyond the statistical uniqueness provided by ULA (see
>> • An organization with a network not connected to the Internet, such
>> a VPN overlay network, can justify the need for an assignment if they
>> require authoritative delegation of reverse DNS.
>> 220.127.116.11 Initial assignment size
>> Organizations that meet at least one of the initial assignment
>> above are eligible to receive an initial assignment of /48. Requests
>> larger initial assignments, reasonably justified with supporting
>> documentation, will be evaluated based on the number of sites in an
>> organization’s network and the number of subnets needed to support
>> extra-large sites defined below.
>> The initial assignment size will be determined by the number of sites
>> justified below. An organization qualifies for an assignment on the
>> larger nibble boundary when their sites exceed 75% of the /48s
>> in a prefix. For example:
>> More than 1 but less than or equal to 12 sites justified, receives a
>> More than 12 but less than or equal to 192 sites justified, receives
>> /40 assignment;
>> More than 192 but less than or equal to 3,072 sites justified,
>> a /36 assignment;
>> More than 3,072 but less than or equal to 49,152 sites justified,
>> receives a /32 assignment;
>> 18.104.22.168.1 Standard sites
>> A site is a discrete location that is part of an organization’s
>> A campus with multiple buildings may be considered as one or multiple
>> sites, based on the implementation of its network infrastructure. For
>> campus to be considered as multiple sites, reasonable technical
>> documentation must be submitted describing how the network
>> infrastructure is implemented in a manner equivalent to multiple
>> An organization may request up to a /48 for each site in its network,
>> and any sites that will be operational within 12 months.
>> 22.214.171.124.2 Extra-large sites
>> In rare cases, an organization may request more than a /48 for an
>> extra-large site which requires more than 16,384 /64 subnets. In such
>> case, a detailed subnet plan must be submitted for each extra-large
>> in an organization’s network. An extra-large site qualifies for the
>> larger prefix when the total subnet utilization exceeds 25%. Each
>> extra-large site will be counted as an equivalent number of /48
>> 126.96.36.199 Subsequent assignments
>> Requests for subsequent assignments with supporting documentation
>> be evaluated based on the same criteria as an initial assignment
>> 188.8.131.52 with the following modifications:
>> a. A subsequent assignment is justified when the total utilization
>> on the number of sites justified exceeds 75% across all of an
>> organization’s assignments. If the organization received an
>> per section 6.11 IPv6 Multiple Discrete Networks, such assignments
>> be evaluated as if they were to a separate organization.
>> b. When possible subsequent assignments will result it the expansion
>> an existing assignment by one or more nibble boundaries as justified.
>> c. If it is not possible to expand an existing assignment, or to
>> it adequately to meet the justified need, then a separate new
>> will be made of the size justified.
>> 184.108.40.206 Consolidation and return of separate assignments
>> Organizations with multiple separate assignments should consolidate
>> a single aggregate, if feasible. If an organization stops using one
>> more of its separate assignments, any unused assignments must be
>> returned to ARIN.
>> This proposal provides a complete rework of the IPv6 end-user
>> criteria, removing the dependency on IPv4 policy, providing clear
>> guidance in requesting larger initial assignments, and eliminating
>> HD-Ratio as criteria for evaluating end-user assignments.
>> The HD-Ratio is replaced with a simplified 75% utilization threshold
>> based on nibble boundaries for end-user assignments. This threshold
>> somewhat more restrictive for larger assignments, while slightly less
>> restrictive for the smaller /44 assignments, than the HD-Ratio.
>> in both cases it is much easier for an end-user to understand the
>> criteria that applies to them.
>> The following general concepts are included:
>> • Previously justified IPv4 resources may be used to justify the need
>> for IPv6 resources
>> • Internet multihoming is sufficient justification for an IPv6
>> assignment in and of itself
>> • Networks with more than 2000 hosts have a justified need for IPv6
>> resources; as is the case in current policy, it is just more clearly
>> stated without relying on a reference to, and the consequences of,
>> • Networks with more than 200 subnets have a justified need for IPv6
>> resources, independent of the number of hosts they have
>> • Other end-users, not meeting one of the previous criteria, must
>> justify why an ISP or LIR assignment is not sufficient for their
>> • Reservations are no longer necessary as ARIN has committed to
>> assignment for IPv6
>> • Providing sufficiently large initial assignments based on nibble
>> boundaries along with sparse assignments will reduce route table
>> caused solely by subsequent assignments
>> Organizations with multiple sites may receive a /48 for each site in
>> their network. A campus with multiple buildings may be considered as
>> or multiple sites, based on the implementation of its network
>> infrastructure. When multiple separate organizations have networks in
>> the same building, such as in the case of a multi-tenant building,
>> organization justifies a separate /48 for its network at the site.
>> The 25% subnet utilization for an extra-large site is proposed as the
>> threshold for a larger prefix in order to allow an extra-large site
>> enough room to create an organized subnet plan. Requiring denser
>> would make it almost impossible for an extra-large site to maintain
>> kind of organized subnet plan. Furthermore, even at 25% utilization,
>> more than 16,384 subnets are required to justify more than a /48 for
>> site. Few, if any, sites can actually meet or exceed this threshold.
>> Organizations may have multiple separate assignments due to previous
>> subsequent assignments made per clause 220.127.116.11.c or through Mergers
>> Acquisitions in section 8.2. These multiple separate assignments must
>> considered in total when making subsequent assignments, unless they
>> part multiple discrete networks, per section 6.11.
>> The ARIN Board of Trusties should consider incentives that provide
>> additional motivation for end-users to consolidate into a single
>> aggregate per section 18.104.22.168 of this policy.
>> Timetable for implementation: Immediate
> 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:
> Please contact info at arin.net if you experience any issues.
ARIN will only charge you once annually for whatever size allocation
you have. There is no fee for requesting additional resources until
your membership comes up for renewal.
Jeffrey Lyon, Leadership Team
jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions