<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Below is an updated copy of my Simplified IPv6 Policy proposal,
which takes into account suggestions made on the list so far.<br>
</p>
<p>Thoughts?<br>
</p>
<p>-Scott<br>
</p>
<p><br>
</p>
<p>Delete "6.1 Introduction"<br>
<i>This is all historical.</i> </p>
<p>Delete "6.2 Definitions"<br>
<i>The definitions we need are all defined in section 2.</i> </p>
<p>Leave 6.3 as is (renumber to 6.1)<br>
<i>I think these still accurately reflect the Goals we want our policy
to follow.</i> </p>
<p>Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered
property" and update text per below.<br>
<i>This is a principle more general than just IPv6, and needs to be
updated to be ARIN-specific and refer to the RSA.</i> </p>
<p>Delete 6.4.2 - 6.4.4<br>
<i>These principles don't seem worthy of elevation to special status.</i>
</p>
<p>Replace 6.5 Policies for allocations and assignments with text below
(renumber to 6.2)<br>
<i>This seems to be where most of the changes and simplification are
needed.</i> </p>
<p>Delete 6.6 References<br>
<i>This is all historical, and doesn't need to be part of the NRPM.</i>
</p>
<p>Delete 6.7 Appendix A: HD-Ratio<br>
<i>We can let the HD-Ratio guide policy without making people like
David's grandma do the math.</i> </p>
<p>Delete 6.8. Appendix B: Background information<br>
<i>This is all historical</i> </p>
<p>Move 6.9 and 6.10 into 6.2.3.2 below </p>
<p>Replacement text: </p>
<p>1.1. Number resources not to be considered property </p>
<p>It is contrary to the goals of this document and is not in the
interests of the Internet community as a whole for address space to be
considered freehold property. </p>
<p>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. </p>
<p><br>
6.2. Policies for IPv6 allocations and assignments </p>
<p>6.2.1. Allocations and assignments </p>
<p>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. </p>
<p>6.2.2. Assignments from LIRs/ISPs </p>
<p>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. </p>
<p>The following guidelines may be useful (but they are only
guidelines): </p>
<ul>
<li> /64 when it is known that one and only one subnet is needed </li>
<li> /56 for small sites, those expected to need only a few subnets
over the next 5 years. </li>
<li> /48 for larger sites<br>
</li>
</ul>
<p>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. </p>
<p>6.2.3. Allocations and assignments from ARIN </p>
<p>6.2.3.1 Goals </p>
<p>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 <a href="https://www.arin.net/fees/fee_schedule.html"
class="external autonumber"
title="https://www.arin.net/fees/fee_schedule.html" rel="nofollow">[1]</a>
for each size issued. </p>
<p>6.2.3.2 X-Small (/48) </p>
<p>To qualify for a /48 allocation or assignment, an organization must:
</p>
<ul>
<li> Be multihomed, per section 2.7, and qualify for an ASN per
section 5; or </li>
<li> Serve at least 1000 hosts; or </li>
<li> Demonstrate efficient utilization of all direct IPv4
assignments and allocations, each of which must be covered by any
current ARIN RSA; or </li>
<li> Qualify for a Micro-allocations for Internal Infrastructure per
6.2.3.2.1.
</li>
</ul>
<p>6.2.3.2.1 Micro-allocations for Internal Infrastructure <i>(Copied
from NRPM 6.10.2)</i> </p>
<p>Organizations that currently hold IPv6 allocations may apply for
a /48 micro-allocation for internal infrastructure. Applicant must
provide technical justification indicating why a separate non-routed
block is required. Justification must include why a sub-allocation of
currently held IP space cannot be utilized. Internal infrastructure
allocations must be allocated from specific blocks reserved only for
this purpose. </p>
<p>6.2.3.3 Small (/40) </p>
<p>To qualify for a /40 allocation or assignment, an organization must
qualify for two or more /48s. </p>
<p>6.2.3.4 Medium (/32) </p>
<p>To qualify for a /32 allocation or assignment, an organization must:
</p>
<ul>
<li> Qualify for 100 or more /48s; or
</li>
<li> Be an existing, known LIR; or </li>
<li> Have a plan to provide IPv6 connectivity to other
organizations and assign at least 100 end-site assignments to those
organizations within 5 years.
</li>
</ul>
<p>6.2.3.5 Large (/28) </p>
<p>To qualify for a /28, an organization must demonstrate the need
to make assignments and/or reallocations equal to at least 20,000 /48s.
</p>
<p>6.2.3.6 X-Large (/24 or larger) </p>
<p>Allocations or assignments of /24 or larger may be made only in
exceptional cases, to organizations that require more than a /28, and
have submitted documentation that reasonably justifies the request. If
approved, the allocation size will be based on the number of existing
users and the extent of the organization's infrastructure. </p>
<p>6.3. Registration <i>(Copied from NRPM 6.5.5)</i> </p>
<p>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. </p>
<p>6.3.1. Residential Customer Privacy <i>(Copied from NRPM 6.5.5.1)</i>
</p>
<p>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. </p>
<p>6.3.2. Reverse lookup <i>(Copied from NRPM 6.5.6)</i> </p>
<p>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.
</p>
</body>
</html>