[arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted

[Randy Carpenter]

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 ?

thanks,
-Randy


----- Original Message -----
> On 11 January 2011 the ARIN Board of Trustees adopted the following
> policy:
>
>    Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria
>    https://www.arin.net/policy/proposals/2010_8.html
>
> This policy will be be implemented no later than 30 April 2011.
>
> Board of Trustees Meeting Minutes are available at:
> https://www.arin.net/about_us/bot/index.html
>
> Draft Policy and Policy Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> 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
>
> 6.5.8.1 Initial Assignment Criteria
>
> Organizations may justify an initial assignment for addressing
> devices
> directly attached to their own network infrastructure, with an intent
> for the addresses to begin operational use within 12 months, by
> meeting
> one of the following criteria:
>
> a. Having a previously justified IPv4 end-user assignment from ARIN
> or
> 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
> IPv6
> 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
> IPv6
> 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
> safety
> 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
> or
> energy distribution, water or waste treatment, traffic management and
> control, etc…
> • Regardless of the number of hosts directly involved, an
> organization
> can justify the need for an assignment if renumbering would affect
> 2000
> 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
> guaranteed
> uniqueness, beyond the statistical uniqueness provided by ULA (see
> RFC
> 4193).
> • An organization with a network not connected to the Internet, such
> as
> a VPN overlay network, can justify the need for an assignment if they
> require authoritative delegation of reverse DNS.
>
> 6.5.8.2 Initial assignment size
>
> Organizations that meet at least one of the initial assignment
> criteria
> above are eligible to receive an initial assignment of /48. Requests
> for
> 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
> any
> 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
> next
> larger nibble boundary when their sites exceed 75% of the /48s
> available
> in a prefix. For example:
>
> More than 1 but less than or equal to 12 sites justified, receives a
> /44
> assignment;
> More than 12 but less than or equal to 192 sites justified, receives
> a
> /40 assignment;
> More than 192 but less than or equal to 3,072 sites justified,
> receives
> a /36 assignment;
> More than 3,072 but less than or equal to 49,152 sites justified,
> receives a /32 assignment;
> etc...
>
> 6.5.8.2.1 Standard sites
>
> A site is a discrete location that is part of an organization’s
> network.
> A campus with multiple buildings may be considered as one or multiple
> sites, based on the implementation of its network infrastructure. For
> a
> 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
> sites.
>
> An organization may request up to a /48 for each site in its network,
> and any sites that will be operational within 12 months.
>
> 6.5.8.2.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
> a
> case, a detailed subnet plan must be submitted for each extra-large
> site
> in an organization’s network. An extra-large site qualifies for the
> next
> larger prefix when the total subnet utilization exceeds 25%. Each
> extra-large site will be counted as an equivalent number of /48
> standard
> sites.
>
> 6.5.8.3 Subsequent assignments
>
> Requests for subsequent assignments with supporting documentation
> will
> be evaluated based on the same criteria as an initial assignment
> under
> 6.5.8.2 with the following modifications:
>
> a. A subsequent assignment is justified when the total utilization
> based
> on the number of sites justified exceeds 75% across all of an
> organization’s assignments. If the organization received an
> assignment
> per section 6.11 IPv6 Multiple Discrete Networks, such assignments
> will
> be evaluated as if they were to a separate organization.
>
> b. When possible subsequent assignments will result it the expansion
> of
> an existing assignment by one or more nibble boundaries as justified.
>
> c. If it is not possible to expand an existing assignment, or to
> expand
> it adequately to meet the justified need, then a separate new
> assignment
> will be made of the size justified.
>
> 6.5.8.4 Consolidation and return of separate assignments
>
> Organizations with multiple separate assignments should consolidate
> into
> a single aggregate, if feasible. If an organization stops using one
> or
> more of its separate assignments, any unused assignments must be
> returned to ARIN.
>
> Rationale:
>
> This proposal provides a complete rework of the IPv6 end-user
> assignment
> 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
> is
> somewhat more restrictive for larger assignments, while slightly less
> restrictive for the smaller /44 assignments, than the HD-Ratio.
> However,
> in both cases it is much easier for an end-user to understand the
> policy
> 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
> end-user
> 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,
> IPv4
> policy
> • 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
> needs
> • Reservations are no longer necessary as ARIN has committed to
> sparse
> assignment for IPv6
> • Providing sufficiently large initial assignments based on nibble
> boundaries along with sparse assignments will reduce route table
> growth
> 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
> one
> 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,
> each
> 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
> usage
> would make it almost impossible for an extra-large site to maintain
> any
> kind of organized subnet plan. Furthermore, even at 25% utilization,
> more than 16,384 subnets are required to justify more than a /48 for
> a
> 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 6.5.8.3.c or through Mergers
> and
> Acquisitions in section 8.2. These multiple separate assignments must
> be
> considered in total when making subsequent assignments, unless they
> are
> 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 6.5.8.4 of this policy.
>
> Timetable for implementation: Immediate