<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The primary reason for applying as an ISP organization rather than an end-user<div>organization is to be able to reassign blocks to your customers in a manner which</div><div>can be recorded via SWIP. The minimum amount of space subject to SWIP is</div><div>a /28, which there are only 16 in a /24 and 32 in a /23. That makes no allowance</div><div>for the ISP's internal infrastructure.</div><div><br></div><div>I'm not opposed to extending this ability to ISPs if there is a need, but, at present,</div><div>I think that when you are talking about reassignable space, a /21 is already a</div><div>pretty small chunk. If I'm wrong about this, I welcome people to set me straight.</div><div>(It won't be the first time).</div><div><br></div><div><div><blockquote type="cite"><div>4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations<br><br>4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4<br>address blocks to end users and ISPs where the requesting organization<br>is multihomed with multiple Internet vendors but does not meet the<br>minimum usage criteria for address allocation or assignment under<br>Sections 4.2 and 4.3.<br><br>4.4.2 Except as specified in section 4.4, the requesting organization<br>must also meet all criteria for receiving addresses specified in<br>section 4.2 if an ISP or section 4.3 if an end user.<br><br>4.4.3 Criteria for allocation or assignment<br><br>4.4.3.1 The requesting organization must hold exactly one AS number<br>and must already announce IPv4 addresses to the Internet via BGP using<br>its AS number.<br><br></div></blockquote>I'm not sure I understand the need to exclude the following classes of</div><div>organizations from this policy:</div><div><br></div><div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>Organizations which are obtaining their AS number and IPv4 resources</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>at the same time as part of a start-up process.</div><div><br></div><div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Organizations which may wish to utilize their ability to qualify under</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>IPv4 policy for obtaining IPv6 space, but, which have no desire to</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>obtain or implement IPv4.</div><div><br></div><div>Noteworthy, it also excludes organizations holding more than one AS number,</div><div>but, that is presumably to discourage fragmentation of the allocation/assignment.</div><div><br></div><div><blockquote type="cite"><div>4.4.3.2. The requesting organization must announce IPv4 addresses to<br>the Internet via at least two distinct Internet vendors.<br><br>4.4.3.3. The requesting organization must spend at least $8000/year on<br>the Internet services in 4.4.3.2.<br><br></div></blockquote>I think this requirement is absurd. First of all, as the price of transit continues</div><div>to fall (currently transit is available for as little as $2/mbps on 95th</div><div>%ile billing) requiring some arbitrary price per year </div><div>(here $333/provider/month) could easily become anachronistic.</div><div>Second, in general ARIN policy tries to avoid dictating business</div><div>models or practices, and, requiring paid transit at all (vs. settlement</div><div>free peering as a viable counter-example) seems odd.</div><div><br></div><div>[snip]<br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>4.4.3.5. The requesting organization must agree to withdraw any other<br>BGP routes it announces from the BGP table within 6 months of<br>receiving an allocation or assignment under section 4.4. If the<br>organization continues to receive IP addresses from its ISPs, those IP<br>addresses will be single-homed within the ISP's larger aggregate<br>announcement.<br><br></div></blockquote>6 months might be a bit hasty here. I think current ARIN address</div><div>replacement policies allow a longer timeframe and I think this</div><div>should be consistent.</div><div><br><blockquote type="cite"><div>4.4.3.6. If the requesting organization fails to announce the<br>allocation or assignment received under section 4.4 to the Internet<br>using its AS number for at least 4 months total within a service year,<br>the allocation or assignment is revoked and returned to ARIN.<br><br></div></blockquote>Does this mean that ARIN is expected to monitor such announcements?</div><div>Is there a defined test point which is considered valid from which the</div><div>routes must be visible? By what objective mechanism and criteria</div><div>can this actually be measured?</div><div><br><blockquote type="cite"><div>4.4.3.7. If the requesting organization already holds IPv4 addresses<br>directly from ARIN, from any other RIR or legacy addresses, the<br>organization must agree to renumber out of those addresses and<br>surrender them to the appropriate RIR within 6 months of receiving an<br>allocation or assignment under section 4.4.<br><br></div></blockquote>See above comment on 4.4.3.5</div><div><br><blockquote type="cite"><div>4.4.3.8. The requesting organization agrees to return the allocation<br>or assignment received under section 4.4 to ARIN within 6 months of<br>receiving another allocation or assignment from any RIR.<br><br></div></blockquote>See above comment on 4.4.3.5</div><div><br></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Q. $8000? What's that all about?<br><br>A. The best available estimate of the systemic cost of carrying a<br>route in the Internet backbone table is around $8000/year. See<br><a href="http://bill.herrin.us/network/bgpcost.html">http://bill.herrin.us/network/bgpcost.html</a> for the cost estimate.<br>If you're going to play in the backbone, you should really be putting<br>more money into the system than you're taking out. If you have two<br>$600 T1's then you're spending nearly twice that anyway. This limits<br>the folks who want to multihome their $50 DSL and cable modems.<br><br></div></blockquote>Depending on where you measure this $8,000/year, it also could</div><div>eliminate folks who connect via exchange points or live in carrier</div><div>hotels and get inexpensive transit by other perfectly legitimate</div><div>means. I understand the theory here, but, in my opinion, it is not</div><div>the role of ARIN policy to dictate economics or business practices.</div><div><br></div><div>[snip]</div><div><br></div><div><br></div><div><blockquote type="cite"><div>Besides, the $8k rule will probably turn out to be a non-operative<br>part of the policy. Companies providing $50 DSL service are<br>disinclined to set up BGP sessions with their customers anyway. I<br>include it in the name of caution so that we're proof against a deluge<br>of multihomed cable-modem users but I expect that with some experience<br>under our belts we'll find that we can safely submit a follow-on<br>policy proposal that removes the $8k requirement.<br><br></div></blockquote>This is the best reason of all to strike the requirement. It's unnecessary</div><div>and any place it would have effect is probably unintended.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div><font class="Apple-style-span" color="#000000"><br></font>Q. Does this proposal affect IPv6 allocations and assignments?<br><br>A. It does not appear to impact ISP allocations whose criteria is<br>spelled out in NRPM section 6.5.1.1. It does impact end user<br>assignments under NRPM section 6.5.8.1. End users who qualify for<br>addresses under this policy will also be qualified for an IPv6 /48.<br><br></div></blockquote>However, it also precludes a network from qualifying under this</div><div>policy and deploying IPv6 without IPv4 resources deployed.</div><div><br></div><div>While this may not be a significant issue today, it does shorten</div><div>the potential valid lifespan of this policy.</div><div><br></div><div>Owen</div><div><br></div></div></body></html>