<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:NewCenturySchlbk;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
h1
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:14.0pt;
font-family:NewCenturySchlbk;
font-weight:bold;}
h2
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
page-break-after:avoid;
font-size:12.0pt;
font-family:NewCenturySchlbk;
font-weight:normal;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
p.SPCI-503Report, li.SPCI-503Report, div.SPCI-503Report
{margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.0pt;
margin-left:0in;
text-indent:0in;
page-break-after:avoid;
mso-list:l0 level1 lfo1;
font-size:14.0pt;
font-family:NewCenturySchlbk;
font-weight:bold;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:888152470;
mso-list-type:hybrid;
mso-list-template-ids:1337115686 -1630604664 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-style-link:"SPCI-503 Report";
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Scott<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>This is definitely along the right track!
I’ll think more about it over the weekend.<o:p></o:p></span></font></p>
<div>
<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>Take care</span></font><font color=navy><span
style='color:navy'> <br>
</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;
font-family:Arial;color:navy'>Terry</span></font><font color=navy><span
style='color:navy'> </span></font><o:p></o:p></p>
</div>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net] <b><span
style='font-weight:bold'>On Behalf Of </span></b><st1:PersonName w:st="on">Scott
Leibrand</st1:PersonName><br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, December 23, 2009
1:06 AM<br>
<b><span style='font-weight:bold'>To:</span></b> ARIN-PPML List<br>
<b><span style='font-weight:bold'>Subject:</span></b> [arin-ppml] Simplified
IPv6 policy</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Here's an attempt at how we might simplify IPv6 policy, incorporating
many of the ideas we've discussed recently. It's much simpler than
current policy, but is still quite long. It's also late, so I reserve the
right to make mistakes, and to disagree with myself later. :-)<br>
<br>
Delete "6.1 Introduction"<br>
This is all historical.<br>
<br>
Delete "6.2 Definitions"<br>
The definitions we need are all defined in section 2.<br>
<br>
Leave 6.3 as is (renumber to 6.1)<br>
I think these still accurately reflect the Goals we want our policy to follow.<br>
<br>
Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered
property" and update text per below.<br>
This is a principle more general than just IPv6, and needs to be updated to be
ARIN-specific and refer to the RSA.<br>
<br>
Delete 6.4.2 - 6.4.4<br>
These principles don't seem worthy of elevation to special status.<br>
<br>
Replace 6.5 Policies for allocations and assignments with text below (renumber
to 6.2)<br>
This seems to be where most of the changes and simplification are needed.<br>
<br>
Delete 6.6 References<br>
This is all historical, and doesn't need to be part of the NRPM.<br>
<br>
Delete 6.7 Appendix A: HD-Ratio<br>
As above, we can let the HD-Ratio guide policy without making people do the
math.<br>
<br>
Delete 6.8. Appendix B: Background information<br>
This is all historical<br>
<br>
Move 6.9 and 6.10 into 6.2.3.2 below<br>
<br>
<br>
<br>
<br>
Replacement text:<br>
<br>
1.1. Number resources not to be considered property<br>
<br>
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.<br>
<br>
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 on a license
basis, with licenses subject to renewal on a periodic basis. The granting of a
license is subject to specific conditions applied at the start or renewal of
the license, as definied in the ARIN Registration Services Agreement.<br>
<br>
Note that when a license is renewed, the new license will be evaluated under
and governed by the applicable number resource policies in place at the time of
renewal, which may differ from the policy in place at the time of the original
allocation or assignment.<br>
<br>
<br>
<br>
6.2. Policies for IPv6 allocations and assignments<br>
<br>
6.2.1. Allocations and assignments<br>
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.<br>
<br>
6.2.2. Assignments from LIRs/ISPs<br>
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.<br>
<br>
The following guidelines may be useful (but they are only guidelines):<br>
<br>
* /64 when it is known that one and only one subnet is needed<br>
* /56 for small sites, those expected to need only a few subnets
over the next 5 years.<br>
* /48 for larger sites<br>
<br>
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.<br>
<br>
ARIN is not concerned about which address size an LIR/ISP actually assigns.
Accordingly, ARIN will not request the detailed information on IPv6 user
networks as in IPv4, except for the purpose of measuring utilization as defined
in this document.<br>
<br>
6.2.3. Allocations and assignments from ARIN<br>
<br>
6.2.3.1 Goals<br>
To balance the goals of Aggregation, Conservation, Fairness, and Minimized
Overhead, ARIN normally makes allocations 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 <a href="<a
href="https://www.arin.net/fees/fee_schedule.html">https://www.arin.net/fees/fee_schedule.html</a>">fee
schedule</a><br>
for each size assigned.<br>
<br>
6.2.3.2 X-Small (/48)<br>
To qualify for a /48 allocation or assignment, an organization must:<br>
* Serve at least 500 hosts, if multihomed; or<br>
* Serve at least 1000 hosts; or<br>
* Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or<br>
* Be a critical infrastructure provider of the Internet, including
public exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA; or<br>
* Qualify for a Micro-allocations for Internal Infrastructure per
6.3.3.2.2.<br>
<br>
6.2.3.2.1 Critical Infrastructure<br>
Organizations qualified as critical infrastructure providers may be granted
multiple /48 allocations in certain situations. 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. 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.<br>
<br>
6.2.3.2.2 Micro-allocations for Internal Infrastructure<br>
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.<br>
<br>
6.2.3.3 Small (/40)<br>
To qualify for a /40 allocation or assignment, an organization must qualify for
two or more /48s.<br>
<br>
6.2.3.4 Medium (/32)<br>
To qualify for a /32 allocation or assignment, an organization must:<br>
* Qualify for 100 or more /48s; or<br>
* Be an existing, known LIR; or <br>
* Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations within 5
years.<br>
<br>
6.2.3.5 Large (/28)<br>
To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 20,000 /48s.<br>
<br>
6.2.3.6 X-Large (/24 or larger)<br>
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.<br>
<br>
6.3. Registration<br>
<br>
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.<br>
<br>
IRs shall maintain systems and practices that protect the security of personal
and commercial information that is used in request evaluation, but which is not
required for public registration.<br>
<br>
6.3.1. Residential Customer Privacy (2003-3)<br>
<br>
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.<br>
<br>
6.3.2. Reverse lookup<br>
<br>
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.<br>
<br>
Thoughts?<br>
Scott<o:p></o:p></span></font></p>
</div>
</div>
</body>
</html>