<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><span class="Apple-style-span" style="font-family: monospace; ">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></blockquote><br><div>This is my formal request to initiate a discussion petition of proposal 116.</div><div><br></div><div>If you would like to sign this petition, please do the following:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Send a message stating "I support the petition for discussion of proposal 116"</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>to <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Either include your contact information and organizational affiliation in</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>the original message to ppml or send it in a separate message to</div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:petition@arin.net">petition@arin.net</a> (use this address if you do not want your contact</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>information disclosed to PPML).</div><div><br></div><div>Thank you.</div><div><br></div><div>I believe that the AC should not have abandoned this proposal for the following</div><div>reasons:</div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>I believe that there is community support for clarifying valid uses and</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>preventing abuses of space reserved for transitional technologies under</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>section 4.10.</div><div><br></div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>The language of 116 states examples of valid uses of space under 4.10</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>but does not specify or dictate specific architecture or methods. It attempts</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>to prevent space reserved for transition from being used in a business-as-</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>usual method that is not in direct support of a transition to IPv6 because</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>the author believes that is contrary to the community intent of 4.10.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I refer specifically to 4.12(1)(a-e) which list a multitude of possible valid</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>technologies and includes specifically (e) etc. to cover any possible</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>valid technologies not yet contemplated.</div><div><br></div><div>3.<span class="Apple-tab-span" style="white-space:pre"> </span>The language in the existing 4.10 is not sufficiently specific to prevent</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>a multitude of possible abuses of the reserved space that do not actually</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>benefit a transition process.</div><div><br></div><div>For these reasons, I encourage anyone who feels that section 4.10 reflects the</div><div>good intent of the community to sign this discussion petition to get this policy</div><div>in front of the community in Atlanta. Even if you disagree with the specifics, those</div><div>can be addressed in the development of the policy. If you have comments on</div><div>those specifics, please direct them to ppml or to me.</div><div><br></div><div><br></div><div>Author contact information as required in the petition process:</div><div><br></div><div>Owen DeLong</div><div><a href="mailto:owen@delong.com">owen@delong.com</a></div><div>+1.408.890.7992</div><div><br></div><div>Here is the text of the proposal in question as required in the petition</div><div>process:</div><div><br></div><div><span class="Apple-style-span" style="font-family: sans-serif; font-size: 12px; line-height: 18px; "><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Proposal Originator: Owen DeLong</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Proposal Version: 1</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Date: 18 June 2010</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Proposal type: modify</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Policy term: permanent</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Policy statement:</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Add the following to section 4.10 of the NRPM</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">6. No organization may receive more than 16 /24 equivalents under this<br>section.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Add the following to section 4 of the NRPM</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">4.11 Required utilization for subsequent allocation under section 4.10</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">4.12 Permitted uses of allocations or assignments under section 4.10</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">No organization shall use space received under section 4.10 for any<br>purpose other than as specified in this section</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Rationale:</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">Timetable for implementation: immediate</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">For reference, here is the current text of 4.10</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">4.10 Dedicated IPv4 block to facilitate IPv6 Deployment</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div><div style="margin-top: 0.4em; margin-right: 0px; margin-bottom: 0.5em; margin-left: 0px; line-height: 1.5em; ">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.</div></span></div></body></html>