<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 4, 2009, at 5:56 AM, William Herrin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Mon, Aug 3, 2009 at 11:43 PM, Owen DeLong<<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br><blockquote type="cite">I'm not opposed to extending this ability to ISPs if there is a need, but,<br></blockquote><blockquote type="cite">at present, I think that when you are talking about reassignable<br></blockquote><blockquote type="cite">space, a /21 is already a pretty small chunk. If I'm wrong about this,<br></blockquote><blockquote type="cite"> I welcome people to set me straight.<br></blockquote><br>Hi Owen,<br><br>Lots of comments. I'll try to take them one at a time.<br><br>The way I see it, there is no compelling reason to pre-suppose what<br>the ISP's needs are. If he needs a /21 and can document that need,<br>he'll surely ask for a /21. If he's a co-op serving a neighborhood,<br>maybe he only needs a /24.<br><br></div></blockquote>You again miss my point. A co-op serving a neighborhood who only</div><div>needs a /24 will not likely need to SWIP portions of said /24, so,</div><div>does not need to register with ARIN as an ISP and pay the (much</div><div>higher) ISP fee schedule instead of the end-user fee schedule</div><div>($100/year).</div><div><br></div><div>I tend to think that such a small ISP is thoroughly unlikely to pay</div><div>fees they don't need, and, as such, think that there are not likely </div><div>to be ISPs that would fall into this policy.</div><div><br></div><div><br></div><div><blockquote type="cite"><div><br><blockquote type="cite">4.4.3.1 The requesting organization must hold exactly one AS number<br></blockquote><blockquote type="cite">and must already announce IPv4 addresses to the Internet via BGP using<br></blockquote><blockquote type="cite">its AS number.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'm not sure I understand the need to exclude the following classes of<br></blockquote><blockquote type="cite">organizations from this policy:<br></blockquote><blockquote type="cite">1. Organizations which are obtaining their AS number and IPv4 resources<br></blockquote><blockquote type="cite">at the same time as part of a start-up process.<br></blockquote><br>These folks are not excluded; they're just given extra work. Instead<br>of merely claiming they're going to multihome as they start up, they<br>have to actually do it. 24 hours after they first announce the ISP /24<br>they can apply for an ARIN /24 and ARIN is pretty zippy about<br>completing allocations.<br><br></div></blockquote>Again, this seems absurd to me. ARIN already asks for copies of</div><div>transit contracts to prove multihomed status on existing policy. I think</div><div>that is adequate.<br><blockquote type="cite"><div><br><blockquote type="cite">2. Organizations which may wish to utilize their ability to qualify under<br></blockquote><blockquote type="cite">IPv4 policy for obtaining IPv6 space, but, which have no desire to<br></blockquote><blockquote type="cite">obtain or implement IPv4.<br></blockquote><br>That only applies to end users and is, IMHO, a defect in the IPv6<br>policy. The appropriate place to correct it is in the IPv6 policy but<br>the AC will have to actually carry such a proposal to a meeting and<br>seek consensus before that can happen.<br><br></div></blockquote>It's not currently a defect. The existing IPv6 policy does just fine in</div><div>this area for end users. The only barrier on this for ISPs is the 200</div><div>site requirement which I am strongly in favor of eliminating, but,</div><div>which is still controversial. I think that number will get relaxed in</div><div>the near future, but, probably not eliminated.</div><div><br></div><div>In any case, an organization which qualified for an ISP IPv4</div><div>allocation under existing policy would at that point count as an</div><div>existing known ISP in the ARIN region.</div><div><br><blockquote type="cite"><div><blockquote type="cite">Noteworthy, it also excludes organizations holding more than one AS number,<br></blockquote><blockquote type="cite">but, that is presumably to discourage fragmentation of the allocation/assignment.<br></blockquote><br>My point of view was that if you're holding more than one AS number<br>then you're already past the point where you should be seeking<br>allocations and assignments below the existing minimums.<br><br></div></blockquote>There are lots of reasons for holding multiple AS numbers that have</div><div>almost nothing to do with the size of your network.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">4.4.3.3. The requesting organization must spend at least $8000/year on<br></blockquote><blockquote type="cite">the Internet services in 4.4.3.2.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think this requirement is absurd. First of all, as the price of transit<br></blockquote><blockquote type="cite">continues to fall (currently transit is available for as little<br></blockquote><blockquote type="cite">as $2/mbps on 95th %ile billing) requiring some arbitrary<br></blockquote><blockquote type="cite">price per year (here $333/provider/month) could easily<br></blockquote><blockquote type="cite">become anachronistic.<br></blockquote><blockquote type="cite">Second, in general ARIN policy tries to avoid dictating business<br></blockquote><blockquote type="cite">models or practices, and, requiring paid transit at all (vs. settlement<br></blockquote><blockquote type="cite">free peering as a viable counter-example) seems odd.<br></blockquote><br>I'm open to altering 4.4.3.3 or dropping it entirely if folks feel<br>it's unwanted and unneeded. But I'd offer two points:<br><br>1. The existing minimums are a harmful and backwards way of applying a<br>limit on how much money you have to spend to participate. We know that<br>routing slots are an expensive resource, so why not tackle that issue<br>more directly instead of placing odd technical requirements that hit<br>it only indirectly?<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote>I guess we'll just agree to disagree here.</div><div><br><blockquote type="cite"><div>2. The number isn't arbitrary; it's based on the only available<br>estimate of the cost of BGP routing which for all its faults has<br>actually been reviewed by a professional cost analyst. It could become<br>anachronistic over time, but so what? Like any ARIN policy its subject<br>to update at need.<br><br></div></blockquote>We've already been through my issues with your cost analysis of a BGP</div><div>routing table slot, and, again, I suppose we should agree to disagree</div><div>there as well.</div><div><br><blockquote type="cite"><div><br><br><blockquote type="cite">4.4.3.5. The requesting organization must agree to withdraw any other<br></blockquote><blockquote type="cite">BGP routes it announces from the BGP table within 6 months of<br></blockquote><blockquote type="cite">receiving an allocation or assignment under section 4.4. If the<br></blockquote><blockquote type="cite">organization continues to receive IP addresses from its ISPs, those IP<br></blockquote><blockquote type="cite">addresses will be single-homed within the ISP's larger aggregate<br></blockquote><blockquote type="cite">announcement.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">6 months might be a bit hasty here. I think current ARIN address<br></blockquote><blockquote type="cite">replacement policies allow a longer timeframe and I think this<br></blockquote><blockquote type="cite">should be consistent.<br></blockquote><br>If the consensus is 12 months I'm fine with moving it there.<br><br><br><blockquote type="cite">4.4.3.6. If the requesting organization fails to announce the<br></blockquote><blockquote type="cite">allocation or assignment received under section 4.4 to the Internet<br></blockquote><blockquote type="cite">using its AS number for at least 4 months total within a service year,<br></blockquote><blockquote type="cite">the allocation or assignment is revoked and returned to ARIN.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Does this mean that ARIN is expected to monitor such announcements?<br></blockquote><blockquote type="cite">Is there a defined test point which is considered valid from which the<br></blockquote><blockquote type="cite">routes must be visible? By what objective mechanism and criteria<br></blockquote><blockquote type="cite">can this actually be measured?<br></blockquote><br><blockquote type="cite">From my "implementation notes" towards the end of the rationale section:<br></blockquote><br>Verifying that there's a BGP announcement is trivial: go to any of the<br>hundreds of looking glasses. For the four-month rule, staff may want<br>to let it be practiced in the breach for now. That is, don't go out<br>and look unless someone complains. Writing software that actively<br>checks for it can be part of the address recovery strategy after<br>depletion.<br><br></div></blockquote>There are lots of reasons that lots of routes are in one looking glass</div><div>and not others. Go to any looking glass creates the potential for</div><div>lots of controversy as recipients verify against one looking glass</div><div>while ARIN verifies against another and the complainer(s) verify</div><div>against yet a third view of a routing table.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>As for how you'd write the software down the road, getting copies of<br>various table views is not particularly hard. A number of researchers<br>currently do it. If the route isn't in any of them then whatever the<br>registrant is doing, it isn't what the policy intended.<br><br></div></blockquote>So ARIN should spend resources keeping some rolling >4-month</div><div>historical view of the routing table and build software to validate</div><div>that a particular prefix was/was not there during a given period?</div><div><br><blockquote type="cite"><div><br><br><blockquote type="cite">Depending on where you measure this $8,000/year, it also could<br></blockquote><blockquote type="cite">eliminate folks who connect via exchange points or live in carrier<br></blockquote><blockquote type="cite">hotels and get inexpensive transit by other perfectly legitimate<br></blockquote><blockquote type="cite">means. I understand the theory here, but, in my opinion, it is not<br></blockquote><blockquote type="cite">the role of ARIN policy to dictate economics or business practices.<br></blockquote><br>You can go to Vegas, stay in the discounted rooms in the casino hotels<br>and play the quarter slots. You can also sit at the high stakes table,<br>but if you do you have to ante up.<br><br>BGP on the backbone is the Internet's high stakes table. Arranging for<br>your connectivity costs to rise to $8k/year is always trivially done.<br>Instead of counting computers, I suggest using your willingness to<br>ante up to determine whether you're allowed to sit at the table.<br><br>Of course, if you can somehow justify a /22 without spending at least<br>$8k per year on connectivity then more power to you.<br><br></div></blockquote>You can justify a /22 by purchasing something north of 500 nodes or</div><div>creating a justification for something north of 500 addresses on some</div><div>smaller number of nodes.</div><div><br></div><div>While I won't enumerate them here, there are lots of ways to justify</div><div>multiple addresses per node. Combine that with some creative</div><div>subnetting, and, artificially creating the need for a /22 isn't particularly</div><div>hard.</div><div><br><blockquote type="cite"><div>Besides, if you live in a carrier hotel, you're paying for cross<br>connects or access to the peering switch. That's generally not cheap<br>and is very obviously part of the connectivity costs.<br><br></div></blockquote>Depends on the carrier hotel, actually. All the world is not Equinix</div><div>or Core Site.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite">Q. Does this proposal affect IPv6 allocations and assignments?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A. It does not appear to impact ISP allocations whose criteria is<br></blockquote><blockquote type="cite">spelled out in NRPM section 6.5.1.1. It does impact end user<br></blockquote><blockquote type="cite">assignments under NRPM section 6.5.8.1. End users who qualify for<br></blockquote><blockquote type="cite">addresses under this policy will also be qualified for an IPv6 /48.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">However, it also precludes a network from qualifying under this<br></blockquote><blockquote type="cite">policy and deploying IPv6 without IPv4 resources deployed.<br></blockquote><blockquote type="cite">While this may not be a significant issue today, it does shorten<br></blockquote><blockquote type="cite">the potential valid lifespan of this policy.<br></blockquote><br>That's not a defect with this policy proposal per se. Rather it's a<br>defect with the IPv6 policy for end users which should be addressed<br>there. Here it's just a red herring like the spammer issue was for<br>proposal 2007-6.<br><br></div></blockquote>I suppose we can agree to disagree here. It does, actually impact</div><div>ISP allocations. As soon as a person qualifies for a /24 under this</div><div>policy as an ISP, it would immediately convert them to a known</div><div>ISP in the ARIN service region and make them eligible to receive</div><div>a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing</div><div>unnecessary barriers to multi-homing, I think giving an IPv6 /32</div><div>to every user that justifies a /24 as an ISP opens up a serious</div><div>hole in policy.</div><div><br></div><div>Further, it could be construed (although I don't think it likely) that</div><div>you need to (under this policy) return your IPv4 resources to get</div><div>IPv6 resources within 6 months since it does not make allowance</div><div>for IPv6 resources to be treated separately.</div><div><br><blockquote type="cite"><div>This particular policy proposal need not outlive IPv4.<br><br></div></blockquote>But it will unless it is cancelled exactly at IPv4 runout or before.</div><div>The former is unlikely to be possible and the latter is not, in my</div><div>opinion, desirable.</div><div><br></div><div>Owen</div><div><br></div><br></body></html>