<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><title>Re: [arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10)</title>
</head>
<body>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
<br>
Hi Owen,<br>
<br>
I don’t support this petition. The work the ideas are good, but they were germane twelve months ago, not now. There is sentiment to set aside an entire /8 and be use it for <i>only</i> transition purposes and to help defray post exhaustion costs. This doesn’t go far or wide enough IMHO and I don’t see what you could compromise to make it acceptable. <br>
<br>
Best Regards,<br>
<br>
Martin Hannigan<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 7/21/10 2:19 AM, "Owen DeLong" <<a href="owen@delong.com">owen@delong.com</a>> wrote:<br>
<br>
</span></font><blockquote><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">The AC abandoned the following proposal:<br>
<br>
116. Permitted Uses of space reserved under NRPM 4.10<br>
<br>
The AC voted to abandon this proposal because of a lack of sufficient<br>
support to accept it as draft policy. Several AC members felt it not<br>
appropriate that ARIN policy dictate any specific architecture or method<br>
a network should use to transition from v4 to v6.<br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
This is my formal request to initiate a discussion petition of proposal 116.<br>
<br>
If you would like to sign this petition, please do the following:<br>
<br>
1. Send a message stating "I support the petition for discussion of proposal 116"<br>
to <a href="arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
2. Either include your contact information and organizational affiliation in<br>
the original message to ppml or send it in a separate message to<br>
<a href="petition@arin.net">petition@arin.net</a> (use this address if you do not want your contact<br>
information disclosed to PPML).<br>
<br>
Thank you.<br>
<br>
I believe that the AC should not have abandoned this proposal for the following<br>
reasons:<br>
<br>
1. I believe that there is community support for clarifying valid uses and<br>
preventing abuses of space reserved for transitional technologies under<br>
section 4.10.<br>
<br>
2. The language of 116 states examples of valid uses of space under 4.10<br>
but does not specify or dictate specific architecture or methods. It attempts<br>
to prevent space reserved for transition from being used in a business-as-<br>
usual method that is not in direct support of a transition to IPv6 because<br>
the author believes that is contrary to the community intent of 4.10.<br>
<br>
I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid<br>
technologies and includes specifically (e) etc. to cover any possible<br>
valid technologies not yet contemplated.<br>
<br>
3. The language in the existing 4.10 is not sufficiently specific to prevent<br>
a multitude of possible abuses of the reserved space that do not actually<br>
benefit a transition process.<br>
<br>
For these reasons, I encourage anyone who feels that section 4.10 reflects the<br>
good intent of the community to sign this discussion petition to get this policy<br>
in front of the community in Atlanta. Even if you disagree with the specifics, those<br>
can be addressed in the development of the policy. If you have comments on<br>
those specifics, please direct them to ppml or to me.<br>
<br>
<br>
Author contact information as required in the petition process:<br>
<br>
Owen DeLong<br>
<a href="owen@delong.com">owen@delong.com</a><br>
+1.408.890.7992<br>
<br>
Here is the text of the proposal in question as required in the petition<br>
process:<br>
<br>
</span><font size="1"><span style="font-size:9pt">Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10<br>
Proposal Originator: Owen DeLong<br>
Proposal Version: 1<br>
Date: 18 June 2010<br>
Proposal type: modify<br>
Policy term: permanent<br>
Policy statement:<br>
Add the following to section 4.10 of the NRPM<br>
6. No organization may receive more than 16 /24 equivalents under this<br>
section.<br>
Add the following to section 4 of the NRPM<br>
4.11 Required utilization for subsequent allocation under section 4.10<br>
No organization shall receive more than one allocation or assignment<br>
under section 4.10 unless all prior space issued under 4.10 meets the<br>
utilization requirements of this section.<br>
1. The most recent 4.10 allocation/assignment must be at least 80% utilized.<br>
2. All utilization must be permitted under section 4.12<br>
3. All prior 4.10 allocation/assignments must be at least 90% utilized.<br>
4.12 Permitted uses of allocations or assignments under section 4.10<br>
No organization shall use space received under section 4.10 for any<br>
purpose other than as specified in this section<br>
1. To provide the required public IPv4 address(es) for transitional<br>
technologies operated by the recipient organization.<br>
a. Large scale or "Carrier Grade" NAT<br>
b. NAT-PT<br>
c. DS-LITE/AFTeR<br>
d. DNS64 or other transitional DNS enablers<br>
e. etc.<br>
2. For other transitional technologies not envisioned at the time of<br>
this proposal, but, in no case for general IPv4 addressing provided to<br>
customers.<br>
Rationale:<br>
The current terminology in section 4.10 is vague and could allow a<br>
variety of interpretations which could lead to allocations or<br>
assignments being made to ISPs intending to misuse the space for general<br>
deployment by using IPv6 overlay technologies as a "IPv6 deployments"<br>
requiring IPv4 space for transition. For example, the current policy<br>
could be interpreted to enable an ISP to require IPv4 addresses for all<br>
IPv6 customers to roll IPv6 out as 6rd to customers who would be<br>
otherwise unable to get IPv4 space. This is clearly outside of the<br>
original intent of the proposal which created 4.10 (6rd was not yet<br>
envisioned at the time that was written). This proposal seeks to clarify<br>
that intent and tighten up the requirements for organizations seeking to<br>
get space from this limited final resource so that it truly is available<br>
to facilitate transitional technologies.<br>
Timetable for implementation: immediate<br>
For reference, here is the current text of 4.10<br>
4.10 Dedicated IPv4 block to facilitate IPv6 Deployment<br>
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous<br>
/10 IPv4 block will be set aside and dedicated to facilitate IPv6<br>
deployment. Allocations and assignments from this block must be<br>
justified by immediate IPv6 deployment requirements. Examples of such<br>
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT<br>
or NAT464 translators. ARIN staff will use their discretion when<br>
evaluating justifications.<br>
This block will be subject to a minimum size allocation of /28 and a<br>
maximum size allocation of /24. ARIN should use sparse allocation when<br>
possible within that /10 block.<br>
In order to receive an allocation or assignment under this policy:<br>
1. the applicant may not have received resources under this policy in<br>
the preceding six months;<br>
2. previous allocations/assignments under this policy must continue to<br>
meet the justification requirements of this policy;<br>
3. previous allocations/assignments under this policy must meet the<br>
utilization requirements of end user assignments;<br>
4. the applicant must demonstrate that no other allocations or<br>
assignments will meet this need;<br>
5. on subsequent allocation under this policy, ARIN staff may require<br>
applicants to renumber out of previously allocated / assigned space<br>
under this policy in order to minimize non-contiguous allocations.<br>
</span></font><span style="font-size:11pt"><br>
</span></font></blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
</span></font>
</body>
</html>