<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 13, 2009, at 7:38 PM, William Herrin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Fri, Dec 11, 2009 at 9:23 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br><blockquote type="cite">- Needs Basis<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">First and probably most important from my personal point of view, I don't<br></blockquote><blockquote type="cite">see a needs basis in this policy, even in the classful IPv4 days you had to<br></blockquote><blockquote type="cite">demonstrate need to get a Class B, or Class A<br></blockquote><br>Hi David,<br><br>If I recollect my history right (and I wasn't involved before '92 so<br>some of this is going to be fuzzy) nothing approaching a formal needs<br>based evaluation came in to play prior to the early '90's. Basically,<br>the guys who were involved when IPv4 was first deployed got class A's.<br>After that, the gentleman (just one) in charge of keeping the address<br>allocation list had something of a "convince me you need a class A and<br>by the way, you don't" policy but he gave out B's and C's for the<br>asking.<br><br></div></blockquote>No... That was not the case.</div><div><br></div><div>Even back that far (I've been involved since ~1986), A's were given to</div><div>large(ish) organizations, not just anyone. There was a time when a C</div><div>was the minimum allocation unit, and, you could get a C essentially</div><div>for the asking, but, you always had to have at least some level of</div><div>justification if you wanted a B or an A. Yes, the bar was raised over</div><div>time on what that justification was, but, there has always been some</div><div>level of needs-based.</div><div><br></div><div><blockquote type="cite"><div>As the Internet got bigger and Network Solutions took over address<br>allocation under contract to the USG, allocation of class B's got<br>tightened up. There was an actual form (instead of an informal "I need<br>a class B" email) and if you were requesting more than a class C you<br>had to write a paragraph or two explaining why. I don't know if there<br>was a formal rule but the informal rule was that if you were a college<br>or government entity of any size, or a well known company, a B was<br>yours for the asking. "We are the United States Bureau of the Office"<br>justified as many class B's as you cared to ask for.<br><br></div></blockquote>That does not match my recollection, but, I think it has become a</div><div>popular mythology. Prior to NSI taking over from SRI, SRI pretty</div><div>much issued on the basis of trusting what was submitted without</div><div>much verification. NSI tightened that up a bit, and later as they</div><div>were preparing to split the address management out of domain</div><div>management, policy started to get even tighter and more formalized.</div><div>The formation of ARIN marked a major step forward in policy</div><div>formulation, and, that process has continued to evolve into what</div><div>we have today.</div><div><br><blockquote type="cite"><div>C's were still the reward for merely submitted a filled-out form, no<br>justification required. Indeed, the "official" policy was we wanted<br>anybody building a TCP/IP network to come and get as many addresses as<br>they thought they needed so that there wouldn't be any grief later<br>when they decided to connect their TCP/IP network with the Internet.<br><br></div></blockquote>That remained mostly true up to the point where CIDR started becoming</div><div>a concern, at which point, policy was tightened up not because of address</div><div>shortage (which started being an issue just a little later), but, because of</div><div>AGS/AGS+ memory limitations.</div><div><br><blockquote type="cite"><div>That's when I personally became involved, fetching a C at the start of<br>'94 and adding an adjacent C just before Network Solutions handed off<br>IP allocation to ARIN. And I can tell you for certain: the only<br>justification anybody ever asked for was "do you intend to use<br>TCP/IP?"<br><br></div></blockquote>Sure... That was the policy for getting a minimum allocation back then,</div><div>but, you always needed more than that to get something more than</div><div>a minimum sized allocation. (True, there was little verification of</div><div>multiple applications for minimum sized allocations, but, that was</div><div>largely an oversight due to the fact that at the time, most people</div><div>couldn' t really see value in asking for more than you needed).</div><div><br></div><div><blockquote type="cite"><div>Class-C giveaways finally started to close down as the RIRs came into<br>existence in the mid-90's and ended with ARN's creation around about<br>'97.<br><br></div></blockquote>Not entirely accurate. The class-C giveaway was actually terminated on</div><div>the altar of CIDR which was purely coincidental in time with the formation</div><div>of the first RIRs and the transition away from SRI/NSI/SAIC.</div><div><br></div><div><blockquote type="cite"><div>The point of my ramble is this: needs-based justification wasn't<br>always around. It's something we invented ad-hoc halfway through the<br>game to address the disaggregation and over-consumption problems. As<br>entrenched as it now is in formal policy, "needs-based allocation" is<br>an underlying assumption we never really thought through all the way<br>from the beginning.<br><br></div></blockquote>Yes it was. To get a minimum allocation, you had to show that you needed</div><div>some IP addresses. To get more, you needed to show that you needed</div><div>more, or, you had to submit multiple applications showing that you needed</div><div>some. Whether or not there was effective enforcement of needs-based,</div><div>the social contract was always needs-based. Prior to 1990, the internet</div><div>was a much friendlier more trusting environment.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>This is no accident. There are multihomed organizations now who can't<br>get usable (i.e. multihomed routable) IPv6 assignment. They have maybe<br>50 very valuable machines online and half a dozen Internet<br>connections.<br>They need multihoming reliability and $10k/year is nothing and<br>$100k/year is a stretch but doable if it gets them the reliability.<br><br></div></blockquote>Um, why can't they get a routable assignment? All such an organization</div><div>would need in order to get a PI /48 from ARIN is apply and pay the one-time</div><div>fee and $100/year thereafter. You can convince me that my ARIN-assigned</div><div>IPv6 /48 isn't routable when I start having trouble reaching IPv6 content I</div><div>care about. So far, that hasn't been an issue.</div><div><br></div><div><blockquote type="cite"><div>Currency is a universal metric. Acting independently, each one of us<br>can equate the worth of behaviors into dollars and back. ISP's can<br>convert the value of accepting routes into dollars. Users can convert<br>the value of multihoming into dollars. It's a mental meeting point<br>that intentionally lacks technical preconditions and as importantly:<br>avoids technical preconceptions.<br><br></div></blockquote>It also ignores the fact that merely thinking something is worth X does not</div><div>necessarily mean that you can afford to pay X for it because someone else</div><div>arbitrarily decided that you should.</div><div><br><blockquote type="cite"><div>A needs based metric like "200 end-user sites" is comparably<br>_arbitrary_. In strictly traditional scenarios (ISP serving dialups<br>and DSLs) it roughly equates with value but the moment you start<br>talking about server farms instead, the value equation is badly<br>skewed. And it leaves no practical way to value creative, innovative<br>systems which need to consume IP addresses or a routing slot.<br><br></div></blockquote>Agreed. We need a better needs-based metric. Money is not a good</div><div>needs-based metric, it is a good greeds-based metric.</div><div><br></div><div><blockquote type="cite"><div>To my way of thinking, this is adequately handled by ARIN's fraud<br>reporting process. You find an AS announcing multiple same-size<br>registrations and they appear to all be a part of that org's unified<br>internal infrastructure, you report them and ARNI audits. Call it a<br>question of mind over matter: if nobody minds, it doesn't matter.<br><br></div></blockquote>Or, more likely, this simply creates an impetus not to actually merge</div><div>the entities and continue to operate them as separate business</div><div>units under common ownership. Thus, no fraud. I don't understand</div><div>how the community benefits from address policy being used to dictate</div><div>business models in this manner, however. This policy approach will</div><div>not reduce the size of the routing table, it will merely create</div><div>administrative hoops to jump through in structuring the merger to</div><div>keep the resources separate in the eyes of the policy.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>Of course, you don't have to go that route. You can also keep the<br>acquired network at arms length, don't fold it in to the rest of your<br>network and keep the acquired legal entity for the purpose of holding<br>the registration and its network resources. The proposed policy does<br>not obstruct such behavior. This is one of the intentional release<br>valves that puts pressure on folks to aggregate but doesn't stand in</div></blockquote><blockquote type="cite"><div>the way of business where the value involved is high enough.<br><br></div></blockquote>I don't see how it puts pressure to do anything other than work around</div><div>the system.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite">Are there some incremental steps we can take toward this vision,<br></blockquote><blockquote type="cite">without jumping off the cliff into a brave but unknown new world?<br></blockquote><br>We could run it in parallel with the current process and let the ISPs<br>decide which one they like better via their filtering policies, but<br>that could create more chaos in a time when we want less.<br><br></div></blockquote>This approach to testing radical reform was tested in California in the</div><div>form of electrical deregulation. Suffice it to say that consumers preferred</div><div>regulated prices based on the savings promised by the energy producers,</div><div>and, the energy producers, led by Enron preferred the spot market.</div><div>The result was that the delivery utilities were caught in a squeeze</div><div>between regulated (low) sell prices to consumers and unregulated</div><div>(high) purchase prices from energy producers who have been shown</div><div>to be more than willing to commit whatever felony was necessary</div><div>to maximize arbitrage opportunities.</div><div><br></div><div>I strongly suggest that we not do this to IP addressing, as I live in</div><div>California and can assure you that electric rates and the economy</div><div>of the state in general are still hurting from that "test".</div><div><br></div><div><blockquote type="cite"><div>We could restrict the top end of the range with a needs analysis but<br>unless there's at least one level of allocation that we're confident<br>the ISPs won't filter before that kicks in, it would trash the whole<br>function of proposal 103 -- ARIN would once again be the routing table<br>gatekeeper. Besides: if someone wants to pay $100k *per year* for a<br>/24, what's the problem exactly?<br><br></div></blockquote>But someone who gets that /24 as an assignment doesn't pay $100k/year.</div><div>They pay $100/year, just like someone who gets a /32 or a /48 assigment.</div><div><br><blockquote type="cite"><div>Other than that, the answer is likely "no." If you accept 103's<br>rationale then the core premise behind today's IPv6 allocation policy<br>is dysfunctional: needs-based justification makes ARIN the gatekeeper<br>to Internet routing policy when it shouldn't be. Like in Millinocket,<br>"you can't get there from here." In order to move forward, we'll first<br>have to identify and back out the practices derived from error. That's<br>what I've attempted with proposal 103.<br><br></div></blockquote>Respectfully, I disagree. I think that needs-based is functional without</div><div>regard to internet routing table gatekeeping being a function of ARIN.</div><div>Verizon is, at this very moment, proving that needs-based /48s being</div><div>issued to people does not prevent a provider from filtering them.</div><div><br><blockquote type="cite"><div><br><br><blockquote type="cite">In the Internet2 world we assigned GigaPOPs /40s out of the Internet2 /32,<br></blockquote><blockquote type="cite">it worked well. Especially, in the early day of IPv6, when people still<br></blockquote><blockquote type="cite">believed in tighter providers based aggregation for IPv6. Think of GigaPOPs<br></blockquote><blockquote type="cite">as regional cooperative providers aggregating end-sites into the national<br></blockquote><blockquote type="cite">member owned Internet2 backbone.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This isn't so radical, and if the rest of the world doesn't follow it still<br></blockquote><blockquote type="cite">might be a good idea anyway.<br></blockquote><br>Not only is that an exceptionally radical suggestion, it was solidly<br>opposed by the participants IRTF Routing Research Group when Heiner<br>Hummel suggested it. You can find a relatively informative iteration<br>of the discussion starting at<br><a href="http://www.ops.ietf.org/lists/rrg/2008/msg01781.html">http://www.ops.ietf.org/lists/rrg/2008/msg01781.html</a> .<br><br></div></blockquote>The IETF also solidly opposed the idea of PI IPv6 at all. The IETF is not</div><div>the canonical source for good operational practice and addressing policy.</div><div><br></div><div>Further, I don't think David was suggesting that GigaPOPs be the model</div><div>for traffic distribution, so much as suggesting an alternative address</div><div>allocation strategy which was, in part, predicated on an understanding</div><div>of the term "GigaPOP".</div><div><br></div><div>Owen</div><div><br></div></body></html>