Policy Proposal 106: Simplified IPv6 policy

[Member Services]

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found 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

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 106: Simplified IPv6 policy

Proposal Originator: Scott Leibrand

Proposal Version: 1.0

Date: 29 December 2009

Proposal type: new

Policy term: permanent

Policy statement:

Delete "6.1 Introduction"
This is all historical.

Delete "6.2 Definitions"
The definitions we need are all defined in section 2.

Leave 6.3 as is (renumber to 6.1)
I think these still accurately reflect the Goals we want our policy to
follow.

Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered
property" and update text per below. This is a principle more general
than just IPv6, and needs to be updated to be ARIN-specific and refer to
the RSA.

Delete 6.4.2 - 6.4.4
These principles don't seem worthy of elevation to special status.

Replace 6.5 Policies for allocations and assignments with text below
(renumber to 6.2) This seems to be where most of the changes and
simplification are needed.

Delete 6.6 References
This is all historical, and doesn't need to be part of the NRPM.

Delete 6.7 Appendix A: HD-Ratio
We can let the HD-Ratio guide policy without making people like David's
grandma do the math.

Delete 6.8. Appendix B: Background information
This is all historical

Move 6.9 and 6.10 into 6.2.3.2 below

Replacement text:

1.1. Number resources not to be considered property

The policies in this document are based upon the understanding that
globally-unique number resources are licensed for use rather than owned.
Specifically, IP addresses and ASNs will be allocated and assigned as
defined in the ARIN Registration Services Agreement.

2.8. Critical Infrastructure Providers

Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.

4.4. Micro-allocation

ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.

4.4.1. Allocation and assignment from specific blocks

Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.

4.4.2. Exchange point requirements

Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
two total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.

6.2. Policies for IPv6 allocations and assignments

6.2.1. Allocations and assignments

To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.

6.2.2. Assignments from LIRs/ISPs

End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.

The following guidelines may be useful (but they are only guidelines):

* /64 when it is known that one and only one subnet is needed
* /56 for small sites, those expected to need only a few subnets over
the next 5 years.
* /48 for larger sites

For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.

6.2.3. Allocations and assignments from ARIN

6.2.3.1 Goals

To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, or /24 or larger. Each
organization or discrete network may qualify for one allocation or
assignment of each size, and must pay fees according to ARIN's fee
schedule [https://www.arin.net/fees/fee_schedule.html] for each size issued.

6.2.3.1.1 Allocation and assignment from specific blocks

Each allocation/assignment size will be made out of separate blocks
reserved for that purpose.  Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes.  ARIN will make a list of these blocks
publicly available.

6.2.3.2 X-Small (/48)

To qualify for a /48 allocation or assignment, an organization must:

* Be Multihomed per section 2.7, and qualify for an ASN per section 5; or
* Serve at least 1000 hosts; or
* Demonstrate efficient utilization of all direct IPv4 assignments and
allocations, each of which must be covered by any current ARIN RSA; or
* Require a non-routed block for internal infrastructure; or
* Be a Critical Infrastructure Provider per section 2.8.

6.2.3.3 Small (/40)

To qualify for a /40 allocation or assignment, an organization must:

* Have two or more Multihomed sites, each of which would qualify for a
/48; or
* Serve at least 2000 hosts; or
* Be an LIR.

6.2.3.4 Medium (/32)

To qualify for a /32 allocation or assignment, an organization must:

* Have 100 or more sites, each of which would qualify for a /48; or
* Be an existing, known LIR; or
* Have a plan to provide IPv6 connectivity to other organizations and
assign at least 100 end-site assignments to those organizations within 5
years.

6.2.3.5 Large (/28)

To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s.

6.2.3.6 X-Large (/24)

To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s.

6.2.3.7 XX-Large (larger than /24)

Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s.  If
approved, the allocation prefix length will be based on the number of
/24s justified (at 4,500,000 /48s each).

6.3. Registration ''(Copied from NRPM 6.5.5)''

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.

6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)''

To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.

6.3.2. Reverse lookup ''(Copied from NRPM 6.5.6)''

When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.


Rationale:

This policy proposal attempts to simplify IPv6 policy in a number of ways.

   For example, it:

* Deletes a number of historical sections and items that duplicate text
elsewhere in the NRPM.
* Removes the HD-ratio, instead incorporating values calculated from it
as the basis for qualification criteria.

It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely.  This rewrite:

* Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users.  The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
whois policy).
* Creates a size-class-based system for allocating IPv6 address blocks.
This has a number of advantages over the existing policy:
** Allows for safe filtering of traffic-engineering (TE) more-specific
route announcements.
** In exchange (since PA more-specifics are expected to be filterable),
allows any multihomed organization to get an assignment from ARIN.  The
smaller number of such PI assignments (compared to TE more-specifics)
should mean that such assignments will largely be accepted across the DFZ.
** Expands the use of discrete blocks from which all allocations will be
of identical prefix length and categorization.  This will enable safer
and easier TE filtering, as mentioned above.
** Expands the availability of non-routed blocks for internal
infrastructure.  Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.
** Makes allocations available to any LIR.

Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes.  OTOH,
if they request a larger block and still hold two or more smaller
blocks, they would be required to return the smaller block as a
condition for receiving the larger one.

Timetable for implementation: Immediate (as soon as practical).