<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="font-size: 13px; ">ULA - Unique Local Addresses</div><div style="font-size: 13px; ">GUA - Globally Unique Addresses</div><div style="font-size: 13px; ">NCN - Non-Connected Networks</div><div style="font-size: 13px; "><br></div><span class="Apple-style-span" style="font-size: 13px; ">I'm seeing a lot of confusion and consternation about policy for these different</span><div style="font-size: 13px; ">things.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">Part of this comes from the fact that there are several perspectives on the issue</div><div style="font-size: 13px; ">which are not entirely compatible. There are people who legitimately want</div><div style="font-size: 13px; ">addresses for non-connected networks. In some of these cases, assigning</div><div style="font-size: 13px; ">global unicast space is a fine solution, but, in some cases, there is actually</div><div style="font-size: 13px; ">a (political/administrative/policy/human factors) reason to want space which</div><div style="font-size: 13px; ">is actually well-known to be "non-routable" on the global internet.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">Some of the people who feel the need for globally unique addresses for</div><div style="font-size: 13px; ">their NCN would like to get them from ARIN, but, see the current policies</div><div style="font-size: 13px; ">as a significant barrier.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">Part of it comes from the (erroneous) perspective that receiving a prefix from</div><div style="font-size: 13px; ">ARIN entitles you to a slot in the "Global Routing Table". This perspective</div><div style="font-size: 13px; ">creates a certain amount of fear about over-allocation/over-assignment</div><div style="font-size: 13px; ">leading to an unsustainable level of growth in the routing table.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">I think a unified solution is possible. The following steps would be required:</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">1.<span class="Apple-tab-span" style="white-space:pre"> </span>Reduce the criteria for getting Global IPv6 Unicast space to the</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>minimum set of justified need and remove the artificial barriers</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>created to prevent routing table growth from address assignment</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>policy.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">2.<span class="Apple-tab-span" style="white-space:pre"> </span>Create a pool of Global IPv6 Unicast space that can be issued to</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>applicants that believe they need space which is regarded as</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>"non-routable" by community convention.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">3.<span class="Apple-tab-span" style="white-space:pre"> </span>Maintain the same qualification and assignment criteria for both</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>groups of IPv6 unicast addresses. Do not differentiate them at</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>the fee structure, either.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">4.<span class="Apple-tab-span" style="white-space:pre"> </span>Leave the determination of what actually makes it into a routing</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>table up to those who run routers and remove it entirely from</div><div style="font-size: 13px; "><span class="Apple-tab-span" style="white-space:pre"> </span>ARIN policy.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">By doing this, we can meet the needs of non-connected networks that</div><div style="font-size: 13px; ">require globally unique addresses and the needs of networks that</div><div style="font-size: 13px; ">require globally unique addresses which are known by convention</div><div style="font-size: 13px; ">to be "unroutable" as well as the more generic needs of networks</div><div style="font-size: 13px; ">that are attached to the internet. It prevents abuse of "unroutable"</div><div style="font-size: 13px; ">addresses in the routing system because there is no advantage</div><div style="font-size: 13px; ">to this form of abuse if the policies and fee structures remain</div><div style="font-size: 13px; ">identical. Growth of the routing table is limited to legitimate</div><div style="font-size: 13px; ">demand and ISPs remain free to reject routes which do not meet</div><div style="font-size: 13px; ">their criteria.</div><div style="font-size: 13px; "><br></div><div style="font-size: 13px; ">Owen</div><div style="font-size: 13px; ">(Speaking only for himself)</div><div style="font-size: 13px; "><br></div><div style="font-size: 17px; "><br></div></body></html>