From marquis at roble.com Sun Aug 1 00:13:29 2010 From: marquis at roble.com (Roger Marquis) Date: Sat, 31 Jul 2010 21:13:29 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100801041329.A24E62B2135@mx5.roble.com> Benson Schliesser > That said, we can learn from all of these comparisons. Spectrum: the FCC > uses a market approach (monetary value/cost) to make sure that spectrum is > allocated efficiently. Problem is radio frequency is a physically limited spectrum, where the need for restrictions is natural. IP exhaustion is anything but natural. It is an artificial shortage imposed on the community by those who stand to profit. It is artificial because the barriers to adoption are well known, basically NAT 64 and 66 standards. These bridges from IPv4 to IPv6 have been blocked by the most specious, inconsistent, and fabricated arguments imaginable. We know NAT works because it is nearly ubiquitous in the IPv4 world. We know there is no good security alternative to NAT, no good multi-homing alternative to NAT, and no business case for GUA. Despite this market intelligence a very small minority of vocal "interests", who claim to be full time network engineers yet seem to have many hours a day to post technically ridiculous criticisms of NAT, have been able to prevent the adoption of NAT64 and 66. This, and only this, is why we are facing address exhaustion. If NAT 64 and 66 had been implemented years ago we would not even be discussing it today. > For IP we should strive to create a fair field of play, but that doesn't > oblige us to artificially de-value address resources. Accepting a thesis > that IP addresses are "private assets" might actually benefit the community > more than the alternative. That is the line IP squatters would have us believe, but there's no business case other than profitability to speculators and squatters. Nothing new here that Enron didn't try 10 years ago. Claims of benefit from an address shortage can only be sustained by ignoring the lessons of history. Roger Marquis From tedm at ipinc.net Sun Aug 1 04:23:26 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 01 Aug 2010 01:23:26 -0700 Subject: [arin-ppml] incentives are better than penalties In-Reply-To: <406393C0-F805-4FE6-A8AE-5D27D27BA0DB@queuefull.net> References: <4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com> <407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com> <4C521B31.7060303@chl.com> <406393C0-F805-4FE6-A8AE-5D27D27BA0DB@queuefull.net> Message-ID: <4C552EFE.9080404@ipinc.net> On 7/31/2010 4:51 PM, Benson Schliesser wrote: > > On 29 Jul 2010, at 7:22 PM, Joe Maimon wrote: > >> I am opposed to reclamation techniques that step up the >> confrontational and adversarial relationship between ARIN and >> address holders, even were it to be essential for continued >> consumption of IPv4 and IPv6 did not exist. I view increasing >> auditing and mandatory triggers of audits with similar concern. >> >> Expending good will and buy in, not to mention financial resources, >> all for relatively limited return along with greater risks of legal >> and political liabilities is not a good bargain. >> >> Bad cop is not a character role an organization like ARIN should >> choose to be identified with. >> >> Incentives for efficiencies, that is where my support lands. Even >> then, I prefer less direct incentives, those that can be spread >> and carried by the invisible hand. > > Amen. > > As ARIN participants we all represent two perspectives that may be at > odds: the success of our organizations, and the ongoing function of > the Internet. The best way to achieve goals associated with the > latter, is to create policy that simultaneously encourages the > former. > > More specifically, we must recognize that the audit and renumbering > of existing IP allocations consumes resources. Few member > organizations are motivated to spend money on returning address > space, because there is no ROI. Creating policy that artificially > penalizes organizations for the status quo (i.e. "stick") will only > encourage the minimal response to avoid trouble, and may encourage > deceit. On the other hand, policy that motivates efficiency (i.e. > "carrot") by assigning real value to number resources will encourage > cooperation and inherently encourages organizations to make excess > resources available. A secondary benefit is that the differential in > cost of plentiful IPv6 and scarce IPv4 will encourage faster take-up > of IPv6. > I personally think that you are getting lost in the kumbayas here. Claims that the RIR's can always peacefully coexist with all IP number consuming orgs are nonsense. No matter how ARIN is structured and no matter what policy it uses there are going to be orgs out there that have a problem with something that they are doing. There are people who would complain about paradise, so please let's not have anymore of this naivete. The question on the table isn't whether the RIR needs to be a good cop, period. The question on the table is whether the RIR needs to "encourage organizations to make excess resources available" by "assigning a real value" to numbering resources, ie: the "carrot" The problem with this idea is that it presumes that no carrot currently exists for orgs to "motivate efficiency" so the RIR's have to provide one. You said it yourself, orgs don't spend money on housekeeping to return addresses because there's no ROI. However this is false. After IPv4 runout, orgs will have plenty of efficiency motivation since that's the only way to self-generate IPv4 demands. Orgs will do this for their own needs, they won't do it for other org's needs. Ted From tedm at ipinc.net Sun Aug 1 04:47:03 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 01 Aug 2010 01:47:03 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> Message-ID: <4C553487.9020103@ipinc.net> On 7/31/2010 8:22 PM, Owen DeLong wrote: > >> >> I disagree unless you mean near ubiquity on the provider side. It's going to be many, many years before the end-users start using it even >> though their provider offers it. >> > We shall see. I suspect it will happen a lot faster than you expect due > to the pressure that will be brought to bear from strong economic > incentives to deprecate IPv4. > I don't believe that because these economic incentives will not exist for all orgs at the same time. It will be very lumpy, some orgs will be desperate for the Internet to shift to IPv6 right away, others will be uninterested for a few years. >>> I also think that >>> the post-runout IPv4 world is going to create a great deal of pressure to >>> deprecate IPv4 much sooner than most people think >> >> I hope this is true. >> > I see one of two things happening: > > 1. The address market is a total flop, nobody wants to sell addresses > at any price. Result: the need for addresses drives a strong and rapid > shift towards IPv6. > > or > > 2. The address market is a wild success, /8s are deaggregated left > and right and sold off as /24s everywhere. The routing table explodes. > Creating a strong economic incentive to deprecate IPv4 just to keep > the internet routable. How about 3: The address market is a wild success for about 6 months until all of the IPv4 speculators and horders are tapped out, then it flops since nobody who is actually USING IPv4 wants to sell it at any price. Result is the need for addresses drives a strong self-generation movement and for another 4-5 years orgs get very creative about reallocating IPv4 addresses within their networks to squeeze out unused IPv4. > >>> There are far too many organizations running IPv6 for me to believe that >>> it cannot be deployed. >>> >> >> And how many of those orgs are IPv6 ONLY? >> > Who said anything about IPv6 only. Deployment of IPv6 does not depend > on deprecation of IPv4. Quite the opposite. > Nobody said that deployment of IPv6 is dependent on deprecation of IPv4. However, you cannot base the notion that IPv6 is ready for production on hundreds of dual-stacked orgs. As long as an org is dual-stacked it simply has no credibility as an example for IPv6 being ready for prime time and your wasting your time trying to convince someone who does not believe IPv6 is ready. It would be like someone trying to argue the advantages of everybody riding the bikes to work, pointing out 50 cyclists who are biking to work that day as evidence. Only the 4 bicyclists in that group of 50 who don't own cars are really walking the talk. And when you come back the next day and it's raining buckets, sure as shootin your only gonna see 4 bicyclists out there, not 50. >> >> Please keep in mind that people who do not have experience with >> enterprise networks, who are coming at this from a small company >> perspective, where everyone is single-homed, simply do not understand >> the difficulties that NAT introduces to multi-site WANs. NAT >> is the "poor man's firewall" to the single-homers and it is >> deployed on millions of residential CPEs and works well on most of >> them, so continuing to harp on how the lack of NAT is a benefit >> to IPv6 goes completely over many people's heads. > > I have substantial experience with SOHO, small enterprise and > large enterprise networks as well as service provider networks > of just about any scale. > > The fact that NAT is widespread does not mean we can't deploy > IPv6 without introducing that damage to IPv6. NAT is not the poor > man's firewall, just a case of ignorance on the part of the poor > man. The poor man's firewall is and has long been stateful > inspection with a default deny inbound policy for all traffic not > matching an existing state table entry. That works with or > without the address mangling of NAT. NAT, on the other hand, > does not work without stateful inspection. > > NAT does cause problems even for the single-homed small > environment, whether those environments are aware of the > problems or not. > Owen, I'm the choir your preaching to here, I'm just telling you that if you want to have credibility with the unrepentant sinners in the congregation you better start thinking like they do. Your running around preaching the evils of NAT and half of these SOHO's out there likely think your talking about some insect that flies up their nose when they ride their bicycle. And the ones that know what it is, they aren't aware of those NAT problems and so they are going to conclude that NAT works fine. I'm just saying, when preaching IPv6, you gotta flog a horse that the listener understands. Ted From owen at delong.com Sun Aug 1 09:28:21 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Aug 2010 06:28:21 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100801041329.A24E62B2135@mx5.roble.com> References: <20100801041329.A24E62B2135@mx5.roble.com> Message-ID: <603E6987-DCDB-467F-947D-3FB9EB836121@delong.com> On Jul 31, 2010, at 9:13 PM, Roger Marquis wrote: > Benson Schliesser >> That said, we can learn from all of these comparisons. Spectrum: the FCC >> uses a market approach (monetary value/cost) to make sure that spectrum is >> allocated efficiently. > > Problem is radio frequency is a physically limited spectrum, where the > need for restrictions is natural. IP exhaustion is anything but natural. > It is an artificial shortage imposed on the community by those who stand > to profit. It is artificial because the barriers to adoption are well No, it really isn't. First, nobody really stands to profit in a meaningful way from IPv4 exhaustion (note, it's IPv4 exhaustion, not IP exhaustion). Sure, a few address holders might make some as yet unknown amount of money from address trading, but, that's pretty much a one-time transaction. Real profit comes from repeatable business. > known, basically NAT 64 and 66 standards. These bridges from IPv4 to > IPv6 have been blocked by the most specious, inconsistent, and fabricated > arguments imaginable. NAT64 hasn't been blocked by any argument so much as nobody has been able to deploy a particularly workable version of it. As to the arguments against NAT66, I would hardly call them specious: 1. It's unnecessary and provides zero benefit. 2. It's tremendously harmful and costly with most of the costs not borne by the organizations deploying or wanting to deploy it. In essence, the argument against NAT66 is about on par with the argument against subsidizing a factory to produce toxic waste and dump it into the environment. > We know NAT works because it is nearly ubiquitous > in the IPv4 world. We know there is no good security alternative to NAT, > no good multi-homing alternative to NAT, and no business case for GUA. Actually, all of those arguments are quite specious: 1. We know NAT can be coerced into minimal functionality because we've managed to do so at great cost in the IPv4 world. We have given up much functionality along the way and we have accepted a large number of tradeoffs. Herpes type 1 is nearly ubiquitous among humans. That doesn't make cold sores any more desirable than any other less prevalent disease. 2. We know that NAT does absolutely nothing for security. Security comes from the stateful inspection that is a prerequisite for the kind of NAT you are imagining provides security. 3. The good multi-homing alternative to NAT is PI GUA. In IPv4, there simply weren't enough addresses to make that possible. In IPv6, there is no such address shortage, so, there is no need for NAT as a workaround or alternative to using PI GUA for multihoming. The next-best multi-homing alternative in IPv6 is PA GUA with prefixes from each of your two providers. This requires a bit of intelligence on your routers to detect when a provider goes down and deprecate the RAs for that prefix, but, it's do-able. It also requires some amount of source address selection policy to be deployed to your hosts. Again, not as convenient as PI GUA, but, do-able if you're determined not to pay $100/year for PI GUA. 4. No business case for GUA? That's such an individual and subjective measure that is unique to each organization, it is hard to comment meaningfully. I can say that many organizations have PI GUA and PA GUA, so, at least for many organizations, that simply isn't true. I find it really hard to imagine a situation where I could justify the cost of multihoming to dual service providers and the routers to support that, but, couldn't justify an initial $1250 and a recurring $100/year to keep the organization humming along with connectivity to the internet > Despite this market intelligence a very small minority of vocal > "interests", who claim to be full time network engineers yet seem to have > many hours a day to post technically ridiculous criticisms of NAT, have > been able to prevent the adoption of NAT64 and 66. This, and only this, > is why we are facing address exhaustion. If NAT 64 and 66 had been > implemented years ago we would not even be discussing it today. > An interesting characterization of those who disagree with you. The failure to implement NAT64 will increase the pain threshold of the transition and probably shorten the duration of the transition, frankly, but, it is not a significant reason not to deploy IPv6. If anything, it's a reason to deploy IPv6 in a dual-stack fashion on your IPv4-capable equipment. The lack of NAT66 may be giving some organizations pause, but, in most cases, that represents ignorance of the above 4 points or some form of religion. Such organizations do not represent the majority of organizations that have not yet deployed IPv6, however. I was a full time network engineer up until about May of last year. Since that time, I took on a new role attempting to help people learn about, understand, and ultimately deploy IPv6. As such, I talk to many organizations that have not yet deployed IPv6 on nearly a daily basis. I also work for a major IPv6 provider and have access to pretty good data about what is connected to the IPv6 internet, connection rates, traffic growth, etc. The adoption rate of IPv6 is definitely accelerating. In talking to organizations that have not deployed IPv6 yet, the major reasons I hear most often are: 1. "We didn't know we needed to. Thanks for letting us know what was going on." 2. "We know it's coming, but, we didn't realize it was coming so soon and we've been focused on other priorities." 3. "We'll deploy IPv6 when we have to. We don't see the need yet." 4. "We're waiting for our upstream providers to support it." 5. "Our vendors haven't enabled it in our gear yet." You are actually the only person to ever tell me that the lack of NAT66 is a barrier to IPv6 deployment. >> For IP we should strive to create a fair field of play, but that doesn't >> oblige us to artificially de-value address resources. Accepting a thesis >> that IP addresses are "private assets" might actually benefit the community >> more than the alternative. > > That is the line IP squatters would have us believe, but there's no > business case other than profitability to speculators and squatters. While I don't agree with your reasoning, i do feel that treating integers as property is absurd and certainly not in the public interest. > Nothing new here that Enron didn't try 10 years ago. Claims of benefit > from an address shortage can only be sustained by ignoring the lessons of > history. > While the rhetoric is entertaining, the shortage of IPv4 addresses is neither artificial, nor is it being created by people who seek to profit from runout. The simple reality is that when you consider the number of devices that require IP addresses per person. I expect this number to be an average of somewhere around 5 when you consider: Laptop Cellphone Desktop @work Desktop @home Portable Entertainment/e-Book device (iPad/Nook/Kindle/etc.) Now, multiply that by 6.8 billion people (http://www.census.gov/main/www/popclock.html) Now, add in some amount for servers. For now, I'll leave this at zero because I don't have a good source for a meaningful number to put in. As such, I would say that my number of required IP addresses below is rather conservative. When I do the math, 5*6.8e9, I come up with 34,000,000,000. When I look at the IPv4 unicast address space, I come up with 3,706,650,624. (This factors in Loopback, RFC-1918, 0.0.0.0/8, 224/4, and 240/4 as non-unicast). According to my math, that leaves us with a shortage of 30,293,349,376 addresses in IPv4 just for the world population without accounting for servers. That does not seem artificial to me. Now, you can argue that some portion of that belongs behind NAT, but, I don't buy that argument. People should be free to choose whether they want to provide content or services to the outside world or not. That requires that they have globally unique addresses. Inflicting NAT upon them removes that choice and is unacceptable in the long run. Owen From owen at delong.com Sun Aug 1 09:43:44 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Aug 2010 06:43:44 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <4C553487.9020103@ipinc.net> References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> <4C553487.9020103@ipinc.net> Message-ID: On Aug 1, 2010, at 1:47 AM, Ted Mittelstaedt wrote: > > > On 7/31/2010 8:22 PM, Owen DeLong wrote: >> >>> >>> I disagree unless you mean near ubiquity on the provider side. It's going to be many, many years before the end-users start using it even >>> though their provider offers it. >>> >> We shall see. I suspect it will happen a lot faster than you expect due >> to the pressure that will be brought to bear from strong economic >> incentives to deprecate IPv4. >> > > I don't believe that because these economic incentives will not exist > for all orgs at the same time. It will be very lumpy, some orgs will > be desperate for the Internet to shift to IPv6 right away, others will be uninterested for a few years. > My point is that in fairly short order, the ISPs providing the transit services will have strong economic incentives to deprecate IPv4. This will, in turn, lead to strong economic incentives being passed along to their customers in the form of "If you want us to keep routing IPv4, it's going to cost you." >>>> I also think that >>>> the post-runout IPv4 world is going to create a great deal of pressure to >>>> deprecate IPv4 much sooner than most people think >>> >>> I hope this is true. >>> >> I see one of two things happening: >> >> 1. The address market is a total flop, nobody wants to sell addresses >> at any price. Result: the need for addresses drives a strong and rapid >> shift towards IPv6. >> >> or >> >> 2. The address market is a wild success, /8s are deaggregated left >> and right and sold off as /24s everywhere. The routing table explodes. >> Creating a strong economic incentive to deprecate IPv4 just to keep >> the internet routable. > > How about 3: > > The address market is a wild success for about 6 months until all of > the IPv4 speculators and horders are tapped out, then it flops since > nobody who is actually USING IPv4 wants to sell it at any price. > Result is the need for addresses drives a strong self-generation > movement and for another 4-5 years orgs get very creative about > reallocating IPv4 addresses within their networks to squeeze out > unused IPv4. In that 6 months, the routing table growth will meet criteria number 2 and the rest won't matter. >> >>>> There are far too many organizations running IPv6 for me to believe that >>>> it cannot be deployed. >>>> >>> >>> And how many of those orgs are IPv6 ONLY? >>> >> Who said anything about IPv6 only. Deployment of IPv6 does not depend >> on deprecation of IPv4. Quite the opposite. >> > > Nobody said that deployment of IPv6 is dependent on deprecation of IPv4. > However, you cannot base the notion that IPv6 is ready for production > on hundreds of dual-stacked orgs. As long as an org is dual-stacked it > simply has no credibility as an example for IPv6 being ready for > prime time and your wasting your time trying to convince someone who > does not believe IPv6 is ready. > The main thing about IPv6 not being ready for prime time (the main reason you need dual stack) in most cases is the ability to reach orgs that don't yet have IPv6. There are a few other straggler problems such as windows resolvers that require IPv4, but, for the most part, that's a local need for IPv4, not a need for global IPv4 connectivity. That need can be met even through RFC-1918 without IPv4 internet connectivity, so, is not impacted significantly by IPv4 runout. > It would be like someone trying to argue the advantages of everybody > riding the bikes to work, pointing out 50 cyclists who are biking to > work that day as evidence. Only the 4 bicyclists in that group of 50 > who don't own cars are really walking the talk. And when you come back > the next day and it's raining buckets, sure as shootin your only gonna > see 4 bicyclists out there, not 50. > I don't think that's quite an apples to apples comparison, but, time will tell. >>> >>> Please keep in mind that people who do not have experience with >>> enterprise networks, who are coming at this from a small company >>> perspective, where everyone is single-homed, simply do not understand >>> the difficulties that NAT introduces to multi-site WANs. NAT >>> is the "poor man's firewall" to the single-homers and it is >>> deployed on millions of residential CPEs and works well on most of >>> them, so continuing to harp on how the lack of NAT is a benefit >>> to IPv6 goes completely over many people's heads. >> >> I have substantial experience with SOHO, small enterprise and >> large enterprise networks as well as service provider networks >> of just about any scale. >> >> The fact that NAT is widespread does not mean we can't deploy >> IPv6 without introducing that damage to IPv6. NAT is not the poor >> man's firewall, just a case of ignorance on the part of the poor >> man. The poor man's firewall is and has long been stateful >> inspection with a default deny inbound policy for all traffic not >> matching an existing state table entry. That works with or >> without the address mangling of NAT. NAT, on the other hand, >> does not work without stateful inspection. >> >> NAT does cause problems even for the single-homed small >> environment, whether those environments are aware of the >> problems or not. >> > > Owen, I'm the choir your preaching to here, I'm just telling you > that if you want to have credibility with the unrepentant sinners > in the congregation you better start thinking like they do. > > Your running around preaching the evils of NAT and half of these SOHO's > out there likely think your talking about some insect that flies up > their nose when they ride their bicycle. And the ones that know > what it is, they aren't aware of those NAT problems and so they > are going to conclude that NAT works fine. I'm just saying, > when preaching IPv6, you gotta flog a horse that the listener > understands. > Right now, I'm mostly focused on preaching to the content providers and ISPs that the SOHOs connect to. The SOHOs will likely accept whatever is handed to them by their upstream as they have in the past. So far, the message seems to be getting through to the intended audience reasonably well, but, I'll keep this in mind when I start directly addressing SOHOs. Owen From andrew.dul at quark.net Sun Aug 1 12:32:15 2010 From: andrew.dul at quark.net (Andrew Dul - andrew.dul) Date: Sun, 01 Aug 2010 10:32:15 -0600 Subject: [arin-ppml] Set aside round deux In-Reply-To: <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> References: <4C5260B2.3070803@quark.net> <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> Message-ID: <44263b4900e19189ce5ca6c701c33f34@8-continents.com> On Fri, 30 Jul 2010 09:56:07 -0400, "Hannigan, Martin" wrote: > On 7/30/10 1:18 AM, "Andrew Dul" wrote: > >> Has anyone considered that maybe what we should do is just reserve the >> block for future use and not try to predict the future too much at this >> point >> and instead comeback after IPv4 exhaustion and then write an appropriate >> policy. Yes this does kick the ball down the field, but it also allows >> the >> ability to have space to work with in the future to use for an >> appropriate use >> after IPv4 run-out. >> >> Andrew >> > > > Hi Andrew, > > Guess I'm not sure what would be speculation or not. I think that there are > some facts at hand: > > - ipv4 addresses will run out at the IANA this year > - at least three RIR's (ARIN, RIPE, APNIC) will run out of ipv4 address > space next year > - networks will need to find ipv4 addresses in order to grow and > transition > I agree with your facts here. > > We could modify such a proposal later if it were posed and succeeds, and > finally, if something is broken horribly and there's consensus the BoT > could > act (and probably not be vilified). I'd prefer the community to develop policy rather than having a policy which pushes the decision to the BoT. > Setting aside a block for future use doesn't seem prudent to me. The time > to > take it from "reserved" to "in use" would be significant. The fact that we > don't have policy already that sets a direction for transition is troubling > and I see the opportunity to do that with a solid set-aside proposal. > I see the current NRPM 4.10 policy as the policy which should be part of the transition process. While 4.10 is probably not a perfect policy it does seem like it gives an option to a set of orgs after IPv4 run-out. Mostly what I was seeing in my reading of the mailing-list was not a lot of consensus on what should be done right now in the use of the last /8. Granted "reading" the mailing-list is an imperfect method of determining consensus, and maybe you have a different opinion that consensus is building around a particular policy. So I'm not specifically opposed to your policy proposal, just that maybe now isn't the best time to figure out how to slice it up since we don't have a large number of organizations deploying transition technologies...yet... On Thu, 29 Jul 2010 22:28:28 -0700, Scott Leibrand wrote: > Joe proposed that for the whole /8, and it didn't get much support. How > big a block were you thinking? > Today, 4.10 sets aside a /10 or 1/4 of the last /8. If we think we needed additional policy now to use some of the remaining /8 in a different way other than 4.10, using another /10 now seems reasonable and reserving the remaining /9 for the future. We could even codify that the remaining part of the last ARIN /8 is released after 4.10's current /10 is used up or some other timing mechanisms. Since 4.10 is rate-limited to 1 block of a small size every 6 months, then its use will probably be pretty consistent once we start allocating/assigning from the 4.10 block. On Fri, 30 Jul 2010 00:17:43 -0700, Owen DeLong wrote: > I think to some extent 4.10 attempted to do that. > I agree 4.10 is what we have now to assist through the transition phase. > I think that 116 is an attempt to do a little more of that. As it > currently stands, there are no criteria > for 4.10 so arguably ARIN staff could either not be able to issue space > for any technology under > existing 4.10, or, they may not be able to make any determination that any > particular claimed > usage is not transitional. I understand your concern here, but I also think that the current 4.10 text is OK. I haven't talked with ARIN staff specifically about the 4.10 language and their concern so perhaps you have more insight here, but given that the usage is rate-limited and small blocks I don't necessarily believe that what is there now won't work. > As such, I think we need to do something to shore up 4.10. 116 was an > attempt to do that while > not restricting the policy only to the technologies known now. Having just gone back and read 116 and 4.10, I can see why you want to add a few more restrictions to 4.10, but 4.10 seems reasonable to me. I guess to me 4.10 seems "good enough" right now. I have a little bit of a problem with the 116 text in that it attempts to specify the technologies, but then has "etc" and "other transitional technologies at the time of proposal" as escape clauses. Seems to me that the current 4.10 language of some examples and staff discretion is OK. Andrew From ipv6nog at gmail.com Sun Aug 1 13:08:26 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Sun, 1 Aug 2010 12:08:26 -0500 Subject: [arin-ppml] IPv6 Update Message-ID: IPv6 Update 1.IPv6 is operational, it plays an expanding role in Windows, especially Windows7. 2. Microsoft's FREE domain name system built on the (rootless) Peer-Name-Resolution-Protocol PNRP requires IPv6. 3. IPv6 is stable in Linux Kernels especially 2.6 now making their way into $50 CPE devices. 4. DD-WRT with the Linux 2.6 Kernel runs on the Cisco/Linksys WRT160N CPE WIFI routers [Version 3 hardware] Refurb units are common at $40. Cisco still uses the 2.4 Kernel and provides all of the open source including build environment. 5. Since IPv6 address space is massive, FREE allocations are readily available. Prefix Uniqueness is derived from domain names at $7/year. ASNs are also FREE. 6. Comcast and ISC have a joint venture field-trial with an open source IPv6 to IPv4 (network-based proxy) arrangement. DNS is likely involved. 7. ISC has just announced more DNS plans and software. See http://CircleID.com --- IPv6 is operational. IPv4 still has a massive amount of space once audits are complete and clean-up is done. Also, as people move to IPv6 that will free up IPv4. IPv6 is a separate network. It is one of many migration options from IPv4, which will have extended addressing. Standards groups like the Mobile IPTV people did not select IPv6 they opted for a UDP-shim extension on IPv4. IPv6 sales people have a hammer - everything looks like a nail... -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquis at roble.com Sun Aug 1 17:40:28 2010 From: marquis at roble.com (Roger Marquis) Date: Sun, 1 Aug 2010 14:40:28 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100731204846.H15759@eboyr.pbz> References: <20100731204846.H15759@eboyr.pbz> Message-ID: <20100801214028.6D4292B213A@mx5.roble.com> Ted Mittelstaedt wrote: > Owen ... Your running around preaching the evils of NAT and half of these > SOHO's out there likely think your talking about some insect that flies up > their nose when they ride their bicycle. And the ones that know what it is, > they aren't aware of those NAT problems and so they are going to conclude > that NAT works fine. I'm just saying, when preaching IPv6, you gotta flog a > horse that the listener understands. It's not a matter of understanding. Many of us have been deploying NAT for decades. We understand that it brings both costs and benefits, however, in our companies NAT is just one element in a matrix. We understand NAT's role in multi-homing gateways, we understand the security provided by NAT, and we also understand the drawbacks to the so-called NAT alternatives. If there is a lack of understanding it has more to do with these and other business deliverables. Aside from network engineering our IT departments are also responsible for securing IP (intellectual property), managing intrusion detection systems, meeting budgets, and regulatory compliance. These are all at least as important as the perceived convenience of network engineering staff. This should not imply that I've met a network engineer who has any problems with NAT. The organizations I have worked for are not ILECs or backbone providers, so neteng job candidates expressing a problem with NAT would not normally get past the first interview. That said, it does seem that the arin-ppml mailing list is backbone-centric, and if it had more representation from administrators of other network models we would hear less from the minority of engineers who have problems with NAT and more from the rest who understand NAT's advantages over the proposed alternatives. Roger Marquis From warren at wholesaleinternet.com Sun Aug 1 17:47:07 2010 From: warren at wholesaleinternet.com (Warren Johnson) Date: Sun, 1 Aug 2010 16:47:07 -0500 Subject: [arin-ppml] Set aside round deux In-Reply-To: <4C553487.9020103@ipinc.net> References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> <4C553487.9020103@ipinc.net> Message-ID: <01c201cb31c3$181a9490$484fbdb0$@com> There is always a price. It's straight forward to calculate. Supposing that selling my IP allocations to another org puts me out of business, how much would I make in the next 5 (you pick the time frame if you want) years in my current business venture. Add on to that number consideration for market value, supply-and-demand etc and you wind up with a selling price. The bigger question is whether that number will be too high for the buyer. I am of the opinion that the Internet will continue to require v4 IP addresses for a long time to come and anyone who wants to play in the big game will have to acquire them somewhere. It is not impossible to imagine a relatively closed system that tremendously favors the incumbents until such time as new technology completely supersedes the current one. I won't go into any more detail about my opinions because last time I did that I got called a troll ;-). -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Sunday, August 01, 2010 3:47 AM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Set aside round deux How about 3: The address market is a wild success for about 6 months until all of the IPv4 speculators and horders are tapped out, then it flops since nobody who is actually USING IPv4 wants to sell it at any price. Result is the need for addresses drives a strong self-generation movement and for another 4-5 years orgs get very creative about reallocating IPv4 addresses within their networks to squeeze out unused IPv4. > >>> There are far too many organizations running IPv6 for me to believe that >>> it cannot be deployed. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3090 bytes Desc: not available URL: From ipv6nog at gmail.com Sun Aug 1 19:04:57 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Sun, 1 Aug 2010 18:04:57 -0500 Subject: [arin-ppml] IPv6 Education via ARIN Labor Union Hall ? Message-ID: IPv6 Education via ARIN Labor Union Hall ? As a suggestion, ARIN may want to provide some IPv6 Education for your rank and file members at your union hall. It appears people are not familiar with IPv6 and how it works. Also, those Evil NAT Boxes may now morph into professional-grade IPv6 Network Elements in a more comprehensive architecture. They were placed in the CPE for a reason. They have flash memories to allow upgrades. They also allow storage for DHT - Distributed Hash Table parameters. If you are not educated about IPv6 DHTs may be very hard to grok. The address/key is 480 bits not 128 which is way too small. In other IPv6 news/education you may want to note that proposals are being made to change the basic 320-bit header. IPv4 has 160-bit basic headers and changes are harder with ASICs in hardware routers. http://www.ietf.org/mail-archive/web/ipv6/current/msg12067.html Speaking of education, you might want to take advantage of various Do It Yourself Router Construction classes. http://NetFPGA.org At the risk of making the picture more complex, it may be important to track the IEEE 802.1Q work on single, double and triple VLAN Tagging. The 60 and 66 bit Address Plans bracket 64-bit plans. http://en.wikipedia.org/wiki/Talk:IEEE_802.1Q At the end of the day, the Address Plan survives the protocol(s). Renumbering is expensive. Lastly, there are groups doing what they call "research". http://www.irtf.org/charter?gtype=rg&group=rrg They seem mostly focused on a Location ID split, which people already use in IPv6. If you view the evolution as a (Fringe(Edge(Core))) three ring target IPv6 is the Edge. IPv4 currently dominates the Core, with MPLS which is outside the IP Header. IPv4 can of course be extended with much larger address spaces for Core players. IPv6 helps to restore the illusion of an end-to-end best-effort .NET that just works. ...that is the illusion from "the Fringe"... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Aug 1 19:13:15 2010 From: jcurran at arin.net (John Curran) Date: Sun, 1 Aug 2010 19:13:15 -0400 Subject: [arin-ppml] IPv6 Education via ARIN Labor Union Hall ? In-Reply-To: References: Message-ID: <118932DD-D3BE-4CB0-B3C9-E62E27B1E3D9@arin.net> Hello Jim - You've got quite a bit of interesting information in your posts; I'd ask that if possible you focus on the policy implications or suggestions for policy changes (if any) that are necessary as as result of your information. Thanks! /John John Curran President and CEO ARIN p.s. For those interesting in training materials on IPv6, ARIN maintains a collection of these educational materials at On Aug 1, 2010, at 4:04 PM, Jim Fleming wrote: IPv6 Education via ARIN Labor Union Hall ? As a suggestion, ARIN may want to provide some IPv6 Education for your rank and file members at your union hall. It appears people are not familiar with IPv6 and how it works. Also, those Evil NAT Boxes may now morph into professional-grade IPv6 Network Elements in a more comprehensive architecture. They were placed in the CPE for a reason. They have flash memories to allow upgrades. They also allow storage for DHT - Distributed Hash Table parameters. If you are not educated about IPv6 DHTs may be very hard to grok. The address/key is 480 bits not 128 which is way too small. In other IPv6 news/education you may want to note that proposals are being made to change the basic 320-bit header. IPv4 has 160-bit basic headers and changes are harder with ASICs in hardware routers. http://www.ietf.org/mail-archive/web/ipv6/current/msg12067.html Speaking of education, you might want to take advantage of various Do It Yourself Router Construction classes. http://NetFPGA.org At the risk of making the picture more complex, it may be important to track the IEEE 802.1Q work on single, double and triple VLAN Tagging. The 60 and 66 bit Address Plans bracket 64-bit plans. http://en.wikipedia.org/wiki/Talk:IEEE_802.1Q At the end of the day, the Address Plan survives the protocol(s). Renumbering is expensive. Lastly, there are groups doing what they call "research". http://www.irtf.org/charter?gtype=rg&group=rrg They seem mostly focused on a Location ID split, which people already use in IPv6. If you view the evolution as a (Fringe(Edge(Core))) three ring target IPv6 is the Edge. IPv4 currently dominates the Core, with MPLS which is outside the IP Header. IPv4 can of course be extended with much larger address spaces for Core players. IPv6 helps to restore the illusion of an end-to-end best-effort .NET that just works. ...that is the illusion from "the Fringe"... _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ipv6nog at gmail.com Sun Aug 1 19:43:11 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Sun, 1 Aug 2010 18:43:11 -0500 Subject: [arin-ppml] IN-ADDR.ARPA Policy Enforcement & Edge Router Null Routes Message-ID: IN-ADDR.ARPA Policy Enforcement & Edge Router Null Routes DNS plays a role in IPv4 Address Space Management http://www.circleid.com/posts/20100728_taking_back_the_dns/ New "Edge" devices will shutdown /27 subnets in Real-Time if IN-ADDR.ARPA is not configured correctly. IPv4 Address Space can be reclaimed, even from the so-called "SWAMP". The /18 is the aggregator for the /27s but ultimately the /8 can be null-routed. IN-ADDR.ARPA Policy Enforcement & Edge Router Null Routes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel_Alexander at Cable.Comcast.com Mon Aug 2 00:06:41 2010 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 2 Aug 2010 00:06:41 -0400 Subject: [arin-ppml] Do people see a middle ground? Message-ID: Not too long ago there were policy discussions about rationing the last of the IP resources allocated to ARIN. Many were opposed to this. The general opinion was that organizations should not be denied needed resources now, for something that may be needed later. Then some found a compromise in section4.10. Then there are proposals that suggest parking resources for the future because we cannot be sure what the situation will be two years from now. These topics were met with opposition against denying known, current needs for unknown circumstances in the future. Finally, there are the discussions about rationing the last bits of IPv4 space by defining what technologies are worthy of receiving the last of the unallocated IPv4 resources. So a couple questions come to mind. Of all the methods being discussed, aren?t they just rationing in one form or another? If so, they why don?t we simplify the conversation and ration the last of the IP space by size and timeframe without all the requirements on an organization that add to the overhead of ARIN staff? Wouldn?t the end result be the same? Should ARIN be defining topologies or technologies for an organization? Many argued strongly in the past against this direction. How much will really be accomplished fine tuning the use of the last 0.4% of the IPv4 space compared to how the other 99.996% is being used? Are some forms of rationing more acceptable than others? I?m curious if there are some who are opposed to outright rationing but find putting requirements on technologies as an acceptable middle ground? What do they feel is the difference or the compromise? Please let me know your thoughts. Dan Alexander ARIN AC -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Aug 2 02:43:52 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Aug 2010 23:43:52 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100801214028.6D4292B213A@mx5.roble.com> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> Message-ID: <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> On Aug 1, 2010, at 2:40 PM, Roger Marquis wrote: > Ted Mittelstaedt wrote: >> Owen ... Your running around preaching the evils of NAT and half of these >> SOHO's out there likely think your talking about some insect that flies up >> their nose when they ride their bicycle. And the ones that know what it is, >> they aren't aware of those NAT problems and so they are going to conclude >> that NAT works fine. I'm just saying, when preaching IPv6, you gotta flog a >> horse that the listener understands. > > It's not a matter of understanding. Many of us have been deploying NAT > for decades. We understand that it brings both costs and benefits, > however, in our companies NAT is just one element in a matrix. > > We understand NAT's role in multi-homing gateways, we understand the > security provided by NAT, and we also understand the drawbacks to the > so-called NAT alternatives. If there is a lack of understanding it has > more to do with these and other business deliverables. Aside from > network engineering our IT departments are also responsible for securing > IP (intellectual property), managing intrusion detection systems, meeting > budgets, and regulatory compliance. These are all at least as important > as the perceived convenience of network engineering staff. > I've spent plenty of time in enterprise networking and the vast majority of enterprise networkers I have met who actually understand things are, frankly, inclined to view NAT as a necessary evil rather than a good thing. If you think NAT offers any security whatsoever, I would argue that pretty well proves a certain lack of understanding. NAT does not do anything for you that a default-deny state-ful inspection policy cannot do without mangling the headers. A default-deny state-ful policy fails just as closed as a NAT and is no harder or easier to subvert. > This should not imply that I've met a network engineer who has any > problems with NAT. The organizations I have worked for are not ILECs or > backbone providers, so neteng job candidates expressing a problem with > NAT would not normally get past the first interview. That said, it does > seem that the arin-ppml mailing list is backbone-centric, and if it had > more representation from administrators of other network models we would > hear less from the minority of engineers who have problems with NAT and > more from the rest who understand NAT's advantages over the proposed > alternatives. > Interesting that you refer to those who do not mind NAT as administrators and those who understand reality as engineers. I think that is a good and valid distinction as network administrators do tend to be more checklist procedure oriented and less grounded in the theory and under-the-hood nature of networking. I can see where such a group would be less informed on the true costs of NAT and would be less likely to understand all of the problems it causes which are outside of their experience. Since they are probably limited in experience to networks that had NAT before they got any where near the network and have likely never experienced a network without NAT, it would make sense. The majority of network administrators, those who follow a set script for dealing with things and have to escalate problems not within their script to an engineer probably don't understand why NAT is bad or know that objecting to it is even possible. I will buy that, and, given some of your earlier statements, if you so claim, I am willing to consider you part of that group. The majority of network engineers, on the other hand, are unlikely to think that NAT is anything better than a necessary evil in IPv4 at best and no longer necessary in IPv6. Owen From owen at delong.com Mon Aug 2 03:21:15 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 00:21:15 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <9741D2A7-FD79-41EC-9C96-B77B8A396277@delong.com> On Aug 1, 2010, at 9:06 PM, Alexander, Daniel wrote: > > Not too long ago there were policy discussions about rationing the last of the IP resources allocated to ARIN. Many were opposed to this. The general opinion was that organizations should not be denied needed resources now, for something that may be needed later. Then some found a compromise in section4.10. > > Then there are proposals that suggest parking resources for the future because we cannot be sure what the situation will be two years from now. These topics were met with opposition against denying known, current needs for unknown circumstances in the future. > > Finally, there are the discussions about rationing the last bits of IPv4 space by defining what technologies are worthy of receiving the last of the unallocated IPv4 resources. > > So a couple questions come to mind. > > Of all the methods being discussed, aren?t they just rationing in one form or another? If so, they why don?t we simplify the conversation and ration the last of the IP space by size and timeframe without all the requirements on an organization that add to the overhead of ARIN staff? Wouldn?t the end result be the same? > I guess that depends on your definition of same. Would the result cause final IPv4 runout to be at the same time? Possibly the parameters could be tuned in either system such that the results would come close. However, I do not believe it would result in the distribution being to the same set of organizations or in using the addresses for the same purposes. As I see it, 4.10 isn't about making IPv4 last and giving it out to needful organizations slowly. As I see it, the purpose for 4.10 is to try and make sure we don't end up in some form of deadly embrace where further deployment of IPv6 depends on the availability of IPv4 resources which are no longer available. My intent in writing proposal 116 was to try and enumerate the technologies that require IPv4 in order to enable IPv6 deployment rather than the technologies that provide continuing IPv4-only services. > Should ARIN be defining topologies or technologies for an organization? Many argued strongly in the past against this direction. How much will really be accomplished fine tuning the use of the last 0.4% of the IPv4 space compared to how the other 99.996% is being used? > I would argue that generally, no they should not. However, if you consider my above explanation of the purpose of 4.10, I don't think that's is really what 4.10 or 116 seek to do. > Are some forms of rationing more acceptable than others? I?m curious if there are some who are opposed to outright rationing but find putting requirements on technologies as an acceptable middle ground? What do they feel is the difference or the compromise? > I don't think rationing is a particularly effective strategy here. I think that reserving a certain amount of IPv4 space to use for the enablement of IPv6 deployment is worthwhile and should be done. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Mon Aug 2 10:26:40 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 2 Aug 2010 08:26:40 -0600 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel wrote: > > Not too long ago there were policy discussions about rationing the last of > the IP resources allocated to ARIN. Many were opposed to this. The general > opinion was that organizations should not be denied needed resources now, > for something that may be needed later. Then some found a compromise in > section4.10. > > Then there are proposals that suggest parking resources for the future > because we cannot be sure what the situation will be two years from now. > These topics were met with opposition against denying known, current needs > for unknown circumstances in the future. > > Finally, there are the discussions about rationing the last bits of IPv4 > space by defining what technologies are worthy of receiving the last of the > unallocated IPv4 resources. > > So a couple questions come to mind. > > Of all the methods being discussed, aren?t they just rationing in one form > or another? If so, they why don?t we simplify the conversation and ration > the last of the IP space by size and timeframe without all the requirements > on an organization that add to the overhead of ARIN staff? Wouldn?t the end > result be the same? I don't think it would be the same. They key difference in the proposals currently on the table and pure rationing (with no technical requirements) is the focus on transitioning to IPv6. > Should ARIN be defining topologies or technologies for an organization? Many > argued strongly in the past against this direction. How much will really be > accomplished fine tuning the use of the last 0.4% of the IPv4 space compared > to how the other 99.996% is being used? ARIN should not define topologies or technologies, no. But... If ARIN is going to restrict a block of addresses to "transitional technologies" than it probably makes sense to define or at least explain through example what is meant by "transitional technology." Defining a term is not quite the same as defining the specific technology or topology to be used. Also - the fight against ARIN getting involved in operational matters is a valid one but not one that we can take to either extreme. As has also been discussed many times before, minimum and maximum allocations and assignments define operational practices to some extent, as does efficient utilization requirements, needs based justification, etc. There is a balance that must be maintained, not an absolute law to be followed. Internet stewardship should be the guiding beacon, and sometimes that means dipping our toes into issues that have effects on operational practice. To your second point; I would reverse the question: How much will we gain by allowing the last 0.4% of the IPv4 space be used just like the other 99.996%? Once we level set, then we can ask how much can we gain by tweaking the use of that same space. In that context, I think it is clear that the bigger win is in tuning the use, rather than taking our hands off the wheel. > Are some forms of rationing more acceptable than others? I?m curious if > there are some who are opposed to outright rationing but find putting > requirements on technologies as an acceptable middle ground? What do they > feel is the difference or the compromise? The goal is not to slow the usage of the last piece of unallocated IPv4 space (rationing), the focus is on leveraging that last piece to accelerate the adoption of IPv6 and the (re)homogenization of the Internet (technical restrictions). $0.02 ~Chris > Please let me know your thoughts. > Dan Alexander > ARIN AC > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From jmaimon at chl.com Mon Aug 2 11:20:52 2010 From: jmaimon at chl.com (Joe Maimon) Date: Mon, 02 Aug 2010 11:20:52 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <4C56E254.6000302@chl.com> Alexander, Daniel wrote: > > Not too long ago there were policy discussions about rationing the last > of the IP resources allocated to ARIN. Many were opposed to this. The > general opinion was that organizations should not be denied needed > resources now, for something that may be needed later. Then some found a > compromise in section4.10. I considered 4.10 a successful trojan horse, a reservation proposal dressed up in IPv6 finery, that I have and continue to support. I also really like the anti-mop-up effect of Draft Policy 2010-1, whether that also came in under the radar is less clear. Many important steps towards what I would consider a middle ground approach to the end game have already succeeded. Considering how many more have failed > > Then there are proposals that suggest parking resources for the future > because we cannot be sure what the situation will be two years from now. > These topics were met with opposition against denying known, current > needs for unknown circumstances in the future. As author of that proposal I thank you for the opportunity to restate that I believe that argument to be penny wise pound foolish, or just plain foolish. > > Finally, there are the discussions about rationing the last bits of IPv4 > space by defining what technologies are worthy of receiving the last of > the unallocated IPv4 resources. > > So a couple questions come to mind. > > Of all the methods being discussed, aren?t they just rationing in one > form or another? Yes. Rationing and scarcity are so conjoined as to be nearly indistinguishable. Two sides to the same coin, synonyms in a sense. The choice is not between some rationing or none. In fact, in this sense, rationing is and has for quite some time already been in effect. ABC's are no longer available to all simply for the asking, are they? The choices and potential outcomes have to do with who or what will be participating in the sharply increasing rationing effect that is inevitable post free pool and subsequent RiR runout. Free or less free market forces? Incumbents forming a cartel, de-facto or otherwise? Some government body or similar authority? ARIN? Rationing of IPv4 will cease to be the reality only when scarcity is removed. That is certainly not going to be the case before issue free IPv6 only service is in vogue for most users of the network. Do you want to lay odds on when that will be? I do not believe a coherent time frame for that eventuality exists at this time. I prefer ARIN attempt to remain in the game and not cede the field completely to all other potential actors. > If so, they why don?t we simplify the conversation and > ration the last of the IP space by size and timeframe without all the > requirements on an organization that add to the overhead of ARIN staff? > Wouldn?t the end result be the same? > > Should ARIN be defining topologies or technologies for an organization? > Many argued strongly in the past against this direction. Put me down in the against column even though characterizing this debate as a binary choice is inaccurate. While I wont say that ARIN must never do so, I would greatly prefer that the case to do so, if ever, be quite compelling in its benefit versus risk calculations. Such risks include the fact that the more frequently policy dabbles in technicalities the more it is likely to continue to do so. I cite 4.10 and recent proposals as evidence to that effect. > How much will > really be accomplished fine tuning the use of the last 0.4% of the IPv4 > space compared to how the other 99.996% is being used? Nothing will be accomplished if that last percentage is used by the same entities for the same purposes and at the same rate. If the portion of that bit potentially available to those who wish to continue consumption at present conditions scales comparably to their existing holdings, it makes even less sense. > > Are some forms of rationing more acceptable than others? I?m curious if > there are some who are opposed to outright rationing but find putting > requirements on technologies as an acceptable middle ground? What do > they feel is the difference or the compromise? > > Please let me know your thoughts. > Dan Alexander > ARIN AC > > The volume of end game proposals, draft policies, adopted and abandoned that litter the past few years suggests that consensus on an overarching middle ground is either being built slowly and meticulously or is flat out impossible, depending on your interpretation. Strictly speaking, wherever we end up, there we are, at a middle ground, by definition. On the assumption your query's target audience includes even those who have broadcast their opinions repeatedly at deafening volume, I favor PP110 and PP112 as the best effort to date at a middle ground, albeit one of the least successful ones. I acknowledge my full bias as the author of those abandoned policy proposal. Without a complete petition worth of support in hand, they are dead and gone. The action continues to move on. Hopefully Martin can produce something compelling that will muster more support than I managed. For whatever it is worth, I will voice my support for any proposal that expands the size of 4.10 or has any reasonable bottleneck effect on it, causing as a side effect preservation of resources available for potentially more useful or important purposes at some later date. I do not consider technical restrictions or requirements on transition to be overly meaningful, as after all is said and done, I estimate such requirements will likely have minimal to no effect on whether and to what extent transition does occur. I also believe the converse to be true, that a lack of requirements and technical restrictions would result in little to none retardation of transition efforts and trends. If 4.10 remains mostly unused, with or without added restrictions, and the need for IPv4 for non-transitional (as defined by 4.10) purposes does not abate, do you not expect pressure to mount for reversing those restrictions and re-purposing 4.10 or to create something similar without those restrictions, assuming resources for it can be found somewhere, somehow? Is anyone else expecting another clarifying statement from the AC regarding IPv4 proposals? Joe From andrew.dul at quark.net Mon Aug 2 11:37:32 2010 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 02 Aug 2010 08:37:32 -0700 Subject: [arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10) Message-ID: <4C56E63C.9010104@quark.net> I support the petition to bring 116 to the meeting. I am specifically supporting this because based upon my read of the mailing-list discussion needs to occur about how the last /8 should be used. Andrew From marquis at roble.com Mon Aug 2 13:14:12 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 2 Aug 2010 10:14:12 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> Message-ID: <20100802171412.2255E2B213A@mx5.roble.com> > If you think NAT offers any security whatsoever, I would argue that pretty > well proves a certain lack of understanding. Good luck finding a job outside of the carrier community with that opinion. > Interesting that you refer to those who do not mind NAT as administrators > and those who understand reality as engineers. I think that is a good and > valid distinction as network administrators do tend to be more checklist > procedure oriented and less grounded in the theory and under-the-hood > nature of networking. That's not a definition of network admin I am familiar with. Sound like you're confusing it with operations. Roger Marquis From ipv6nog at gmail.com Mon Aug 2 13:22:34 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Mon, 2 Aug 2010 12:22:34 -0500 Subject: [arin-ppml] ARIN on NPR - Public Confusion, Perception & Reputation ? Message-ID: ARIN on NPR - Public Confusion, Perception & Reputation ? 1. "ARIN" was on NPR... http://www.ietf.org/mail-archive/web/ipv6/current/msg12092.html http://www.npr.org/templates/story/story.php?storyId=10 2. ARIN is 4-letters 3. ARIN.NET is widely known 4. The ICANN CEO has declared .NET to be a "worthless TLD". 5. Someone secretly purchased ARIN.COM for an un-disclosed sum prior to a major lawsuit. 6. ARIN claims to be non-profit and the public assumes that would be ARIN.ORG 7. DNS Reputation Systems are starting to be disclosed by ARIN Executives/Leaders/Management? http://www.circleid.com/posts/20100728_taking_back_the_dns/#6860 8. IN-ADDR.ARPA Zones are part of the DNS and will allow "Reputations" for sections of IP Address Space [Will companies have a choice to not be with the .XXX zones?] 9. IANA Scheme Names are now on investor's radar screens...they are FREE as in $$$ ? http://www.iana.org/assignments/uri-schemes.html http:// mail:// news:// xxx:// and all 4-Letter Strings ? ARIN:// zoom://ZOOM 10. Twitter appears to be willing to give 4-Letter .COM owners their names, without a battle 11. The 4-Letter .COM owners have FREE IPv6 Address Space (ARIN.COM also) --- Where is ARIN headed ? to the .NET only core ? to .ORG ? to .COM ? to just the Brand "ARIN" ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From springer at inlandnet.com Mon Aug 2 13:28:18 2010 From: springer at inlandnet.com (John Springer) Date: Mon, 2 Aug 2010 10:28:18 -0700 (PDT) Subject: [arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10) In-Reply-To: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com> References: <65131AED-F794-4F5F-8BE0-7901445A0FA1@delong.com> Message-ID: <20100802102600.N46637@mail.inlandnet.com> I support the petition for discussion of proposal 116. I believe it deserves discussion in Atlanta. John Springer From sethm at rollernet.us Mon Aug 2 14:49:26 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 02 Aug 2010 11:49:26 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <4C571336.2090205@rollernet.us> On 8/1/2010 21:06, Alexander, Daniel wrote: > > So a couple questions come to mind. > > Of all the methods being discussed, aren?t they just rationing in one > form or another? If so, they why don?t we simplify the conversation and > ration the last of the IP space by size and timeframe without all the > requirements on an organization that add to the overhead of ARIN staff? > Wouldn?t the end result be the same? > > Should ARIN be defining topologies or technologies for an organization? > Many argued strongly in the past against this direction. How much will > really be accomplished fine tuning the use of the last 0.4% of the IPv4 > space compared to how the other 99.996% is being used? Under normal circumstances I'd say no (i.e. I wouldn't support a proposal prohibiting /30 PTP links). However, the run out of IPv4 is a unique enough event that should be given special consideration, including assistance migrating to IPv6. I believe that reserving some space for IPv6 transitional technologies and denoting that it's not for "business as usual" is a worthy cause. It's likely that the run out brick wall will only happen once, but I'm sure some IPv4 space will be reclaimed afterward from the normal attrition of entities closing shop or bills not being paid. ~Seth From jmaimon at chl.com Mon Aug 2 15:18:55 2010 From: jmaimon at chl.com (Joe Maimon) Date: Mon, 02 Aug 2010 15:18:55 -0400 Subject: [arin-ppml] Set aside round deux In-Reply-To: References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> Message-ID: <4C571A1F.1060208@chl.com> Owen DeLong wrote: > The fact that NAT is widespread does not mean we can't deploy > IPv6 without introducing that damage to IPv6. NAT is not the poor > man's firewall, just a case of ignorance on the part of the poor > man. The poor man's firewall is and has long been stateful > inspection with a default deny inbound policy for all traffic not > matching an existing state table entry. That works with or > without the address mangling of NAT. NAT, on the other hand, > does not work without stateful inspection. > > NAT does cause problems even for the single-homed small > environment, whether those environments are aware of the > problems or not. > > Owen > I would like to address this specific point, oft repeated that NAPT's stateful inspection protection is a byproduct and can easily be replaced with a basic firewall turned on by default. While certainly true from a technical viewpoint, I think this glosses over a somewhat non technical practical reality and interaction between protocols, vendors, firewalls, designers, users and administrators. Without the ubiquity of NAPT, how long do you think it will be before having a default deny inbound rule becomes non practical, or that UPNP hole punching is a basic requirement to the extent that firewall are a swiss cheese joke? How many times as a NAT/Firewall admin on any size or class device have you been asked to "open the firewall" for this or that protocol? Do those requesters even understand the concept of flow direction/initiation? The difference between permit rules and inbound translation maps, the difference between bi-directional static NAT and multiplexed NAPT or differing inside and outside ports? Have they even tried using the application before blaming the "firewall"? Do they know which ports and protocols are involved or whether the application can be tuned to work properly without a specific inbound permit, or worse a gigantic monster truck sized 16K dynamic port range hole? Yeah, I thought so. Its you who is the bad guy, breaking their cute little protocol/application. Now apply that to the residential market. Protocol designers, users and administrators are not any less lazy than the rest of us. Possibly more. NAT ubiquity have forced all but the die hard idealists to avoid any use of cheap protocols tricks that prove burdensome and unwieldy in not only a NAPT environment, but also in an SPI environment, except as properly justified or required (one hopes). That is a good thing in my opinion and I would hate to see the pendulum swing the other way to the extent that cheap CPE which are not intended to burden its user with actual operation of them can no longer use a default deny inbound SPI. Its much easier to tell someone turn off the firewall if you want my protocol to work "just for testing" than to tell them to turn off NAPT. In the former, the protocol will magically start to work and the firewall will stay off. In the latter, nothing will work and NAT will be turned back on. In a sense, this is the correct expansive definition of the phrase "NAT fails close", where fail is the failure of protocols, admins and users to adhere to proper security diligence. Lets face it, requiring L4 and higher protocols to have knowledge of L3 detail is a layering violation and should be frowned upon by those who believe layering violations are the source of all protocol evil. So where does this leave me? I believe firmly that NAPT should become a choice made by users, not a requirement for basic service as it is now, nor a practical impossibility as IPv6 currently intends. Joe From bensons at queuefull.net Mon Aug 2 15:29:47 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 2 Aug 2010 14:29:47 -0500 Subject: [arin-ppml] incentives are better than penalties In-Reply-To: <4C552EFE.9080404@ipinc.net> References: <4C51DBE8.9060108@chl.com> <4C51E1F7.1000302@rollernet.us> <4C51E4F5.9090003@chl.com> <407CBD88-571A-4C0E-B1F4-D4460C4D51F2@delong.com> <4C521B31.7060303@chl.com> <406393C0-F805-4FE6-A8AE-5D27D27BA0DB@queuefull.net> <4C552EFE.9080404@ipinc.net> Message-ID: <958E9D22-B148-47B0-9088-A2BD9449B4F5@queuefull.net> On 1 Aug 10, at 3:23 AM, Ted Mittelstaedt wrote: > I personally think that you are getting lost in the kumbayas here. ... > There are people who would complain about paradise, so please let's not > have anymore of this naivete. I'm not talking about utopia, here. You're inserting too much between-the-lines of my suggestion, and it is insulting to both of our intelligences. > You said it yourself, orgs don't spend > money on housekeeping to return addresses because there's no > ROI. > > However this is false. After IPv4 runout, orgs will have plenty > of efficiency motivation since that's the only way to self-generate > IPv4 demands. Orgs will do this for their own needs, they won't > do it for other org's needs. Your current position seems to be that no organization can be motivated to free up excess addresses for another. This may be true under current policy, but ARIN can do better than status quo. Thus the policy development process exists. Everybody has a price, and there are a number of organizations with many more address resources than they will ever need. This suggests that, with the right motivation, organizations with vast excess addresses would make them available. Further, in time, organizations with marginally excessive address space would make them available albeit at a higher price. Absent an IPv6 Internet, some day even those with existing business might be willing to close operations in order to sell their addresses, if somebody was willing to pay the price. Of course, it would be best if this last group never existed. But the first two groups could carry us through a number of years. We can motivate these organizations, while encouraging Internet growth and operations, by embracing a well-balanced market approach. This isn't a beautiful world full of peace and love, it's competition regulated to arrive at the desired end. Cheers, -Benson From owen at delong.com Mon Aug 2 15:53:58 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 12:53:58 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100802171412.2255E2B213A@mx5.roble.com> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> <20100802171412.2255E2B213A@mx5.roble.com> Message-ID: <4DDD336D-3BAE-4678-AC4B-79A5E3517813@delong.com> On Aug 2, 2010, at 10:14 AM, Roger Marquis wrote: >> If you think NAT offers any security whatsoever, I would argue that pretty >> well proves a certain lack of understanding. > > Good luck finding a job outside of the carrier community with that > opinion. > I have had several jobs outside of the carrier community and doubt that I would have much trouble finding another one. However, currently I am very happy with my position at Hurricane Electric and feel I can do more to contribute to the IPv6 transition process from here than virtually anywhere else I can imagine. As such, I have no plans to put that question to the test at this time. Owen From owen at delong.com Mon Aug 2 16:11:45 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 13:11:45 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <4C571A1F.1060208@chl.com> References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> <4C571A1F.1060208@chl.com> Message-ID: <31E6B613-4020-4CD1-A1FE-123764A1AF04@delong.com> On Aug 2, 2010, at 12:18 PM, Joe Maimon wrote: > > > Owen DeLong wrote: > > >> The fact that NAT is widespread does not mean we can't deploy >> IPv6 without introducing that damage to IPv6. NAT is not the poor >> man's firewall, just a case of ignorance on the part of the poor >> man. The poor man's firewall is and has long been stateful >> inspection with a default deny inbound policy for all traffic not >> matching an existing state table entry. That works with or >> without the address mangling of NAT. NAT, on the other hand, >> does not work without stateful inspection. >> >> NAT does cause problems even for the single-homed small >> environment, whether those environments are aware of the >> problems or not. >> >> Owen >> > > I would like to address this specific point, oft repeated that NAPT's stateful inspection protection is a byproduct and can easily be replaced with a basic firewall turned on by default. > > While certainly true from a technical viewpoint, I think this glosses over a somewhat non technical practical reality and interaction between protocols, vendors, firewalls, designers, users and administrators. > Bring it on... > Without the ubiquity of NAPT, how long do you think it will be before having a default deny inbound rule becomes non practical, or that UPNP hole punching is a basic requirement to the extent that firewall are a swiss cheese joke? > This differs from the current reality with NAPT how? I don't see any reason that state-ful inspection without NAPTT would be any more or less secure than it is with NAPT. > How many times as a NAT/Firewall admin on any size or class device have you been asked to "open the firewall" for this or that protocol? > The presence of NAPT does nothing to improve this and the absence of NAT would only have the following effect: 1. Your audit logs will be easier to correlate. 2. Things are easier to troubleshoot because you don't have to correlate address mappings that are transient in nature. 3. Historical data will be more useful (again due to lack of transient mappings that may or may not get recorded). > Do those requesters even understand the concept of flow direction/initiation? The difference between permit rules and inbound translation maps, the difference between bi-directional static NAT and multiplexed NAPT or differing inside and outside ports? Have they even tried using the application before blaming the "firewall"? Do they know which ports and protocols are involved or whether the application can be tuned to work properly without a specific inbound permit, or worse a gigantic monster truck sized 16K dynamic port range hole? Yeah, I thought so. Its you who is the bad guy, breaking their cute little protocol/application. Now apply that to the residential market. > In many cases, yes, but, in some cases no. However, a key issue here is that you are juxtaposing residential and enterprise requirements in a manner that doesn't really further either discussion. In the residential situation, I'm not worried about any failure to deploy IPv6 due to lack of NAT. Residential users are going to end up on IPv6 simply as a result of the lack of IPv4 and the fact that they are least in a position to manipulate their providers' behavior. In the enterprise situation (where this thread started and where my comments have primarily been directed), as you point out, there is a firewall administrator responsible for working with the users to evaluate such requests and analyze the security implications for the organization. It's that person's job to be the "bad guy" when required. His job isn't any harder or easier because of NAPT and it doesn't get any better or worse as a result of deprecating NAPT. > Protocol designers, users and administrators are not any less lazy than the rest of us. Possibly more. NAT ubiquity have forced all but the die hard idealists to avoid any use of cheap protocols tricks that prove burdensome and unwieldy in not only a NAPT environment, but also in an SPI environment, except as properly justified or required (one hopes). > Many things that I would not call stupid protocol tricks are unwieldy in a NAPT environment but work just fine in a stateful inspection environment. Address mangling introduces additional problems that are not present simply from stateful inspection. > That is a good thing in my opinion and I would hate to see the pendulum swing the other way to the extent that cheap CPE which are not intended to burden its user with actual operation of them can no longer use a default deny inbound SPI. > Agreed. I don't see how NAPT helps this, however. > Its much easier to tell someone turn off the firewall if you want my protocol to work "just for testing" than to tell them to turn off NAPT. > That doesn't necessarily have to be true, but, given the ubiquity of things like UPNP on residential gateways, I don't see how that really matters. Oh, and, I have seen people get told try putting your machine directly behind the DSL modem instead of behind the router... (Which amounts to turn off NAPT). It really is just about as easy. > In the former, the protocol will magically start to work and the firewall will stay off. In the latter, nothing will work and NAT will be turned back on. In a sense, this is the correct expansive definition of the phrase "NAT fails close", where fail is the failure of protocols, admins and users to adhere to proper security diligence. > Uh, no, see above. > Lets face it, requiring L4 and higher protocols to have knowledge of L3 detail is a layering violation and should be frowned upon by those who believe layering violations are the source of all protocol evil. > First, not everyone shares this belief, but, even for those that do, there are things that break from NAT without layering violations. > So where does this leave me? I believe firmly that NAPT should become a choice made by users, not a requirement for basic service as it is now, nor a practical impossibility as IPv6 currently intends. > I'm fine with users choosing to do whatever damage they want to their own network. What I would like to avoid is having that choice inflict that damage upon ISVs and others in the form of requiring vast amounts of code to create NAT traversal technologies to overcome that damage when there is no longer any need to damage the network in such a way. Owen From tedm at ipinc.net Mon Aug 2 16:26:34 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 02 Aug 2010 13:26:34 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100801214028.6D4292B213A@mx5.roble.com> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> Message-ID: <4C5729FA.6020104@ipinc.net> On 8/1/2010 2:40 PM, Roger Marquis wrote: > Ted Mittelstaedt wrote: >> Owen ... Your running around preaching the evils of NAT and half of these >> SOHO's out there likely think your talking about some insect that >> flies up >> their nose when they ride their bicycle. And the ones that know what >> it is, >> they aren't aware of those NAT problems and so they are going to conclude >> that NAT works fine. I'm just saying, when preaching IPv6, you gotta >> flog a >> horse that the listener understands. > > It's not a matter of understanding. Many of us have been deploying NAT > for decades. We understand that it brings both costs and benefits, > however, in our companies NAT is just one element in a matrix. > > We understand NAT's role in multi-homing gateways, we understand the > security provided by NAT, and we also understand the drawbacks to the > so-called NAT alternatives. If there is a lack of understanding it has > more to do with these and other business deliverables. Aside from > network engineering our IT departments are also responsible for securing > IP (intellectual property), managing intrusion detection systems, meeting > budgets, and regulatory compliance. These are all at least as important > as the perceived convenience of network engineering staff. > > This should not imply that I've met a network engineer who has any > problems with NAT. The organizations I have worked for are not ILECs or > backbone providers, so neteng job candidates expressing a problem with > NAT would not normally get past the first interview. That said, it does > seem that the arin-ppml mailing list is backbone-centric, and if it had > more representation from administrators of other network models we would > hear less from the minority of engineers who have problems with NAT and > more from the rest who understand NAT's advantages over the proposed > alternatives. > Roger, I cut my teeth using debug to format and compsurf to brand ESDI drives. I deployed NAT in production when the ONLY way you could do it was apply a massive patch to the FreeBSD 2.x kernel. This was long before Cisco released 11.2 IOS which was the first "commercial router" that supported NAT - and only on certain platforms (ie:2500, not 1000) and long before Linksys was anything more than a misspelling of a childrens toy set. And, I daresay, long before YOU knew anything about what NAT is. So I'm intimately familiar with NAT and how it's used. NAT's days are numbered and no matter how many benefits you think it brings, one way or another it's going to be gone. I saw and worked with a LOT of kludges during the days when orgs switched from Netware to TCP/IP. Remember that IP-over-IPX thing that Novell had going where the client spoke IPX to some proxy that actually talked to the Internet? Yech! All of those - gone. Except for the handful of orgs who lack the imagination to come into the 21st century. There will undoubtedly be vendors in the IPv6 Internet who will make money off those sorts. I will point out that most listmembers on arin-ppml who are backbone centric in outlook, didn't spring from the womb as full blown backbone admins. Please give us a little credit, we all had to cut our teeth as greenhorn admins of "other network models" We "get it" But we have come to the realization that NAT isn't going to work in the long haul and there's no point in telling people who are just starting to learn about IPv6 that it is. Better to raise them properly from the first place. As others have said, securing IP (intellectual property), managing intrusion detection systems, meeting budgets, and regulatory compliance can all be done without NAT. If you not familiar with how to do them without NAT then learn. Your only hurting yourself by refusing to do so. Ted > Roger Marquis > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Mon Aug 2 16:32:43 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 02 Aug 2010 13:32:43 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <4C572B6B.3060207@ipinc.net> On 8/1/2010 9:06 PM, Alexander, Daniel wrote: > > Not too long ago there were policy discussions about rationing the last of > the IP resources allocated to ARIN. Many were opposed to this. The general > opinion was that organizations should not be denied needed resources now, > for something that may be needed later. Then some found a compromise in > section4.10. > > Then there are proposals that suggest parking resources for the future > because we cannot be sure what the situation will be two years from now. > These topics were met with opposition against denying known, current needs > for unknown circumstances in the future. > > Finally, there are the discussions about rationing the last bits of IPv4 > space by defining what technologies are worthy of receiving the last of the > unallocated IPv4 resources. > > So a couple questions come to mind. > > Of all the methods being discussed, aren?t they just rationing in one form > or another? If so, they why don?t we simplify the conversation and ration > the last of the IP space by size and timeframe without all the requirements > on an organization that add to the overhead of ARIN staff? Wouldn?t the end > result be the same? > > Should ARIN be defining topologies or technologies for an organization? Many > argued strongly in the past against this direction. How much will really be > accomplished fine tuning the use of the last 0.4% of the IPv4 space compared > to how the other 99.996% is being used? > > Are some forms of rationing more acceptable than others? I?m curious if > there are some who are opposed to outright rationing but find putting > requirements on technologies as an acceptable middle ground? What do they > feel is the difference or the compromise? > > Please let me know your thoughts. > Dan Alexander > ARIN AC > My $0.02 is that the second you institute some form of formalized rationing, your saying that IPv4 is over. The largest orgs cannot get blocks anymore and thus to them, the IPv4 party is over, the cops have come, and the host is busy throwing everyone out the back door. Once your no longer able to fill large IP address requests, it's over. Ted > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From packetgrrl at gmail.com Mon Aug 2 16:49:34 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 2 Aug 2010 14:49:34 -0600 Subject: [arin-ppml] ARIN on NPR - Public Confusion, Perception & Reputation ? In-Reply-To: References: Message-ID: Here is the actual transcript of John Curran's interview on NPR http://www.npr.org/templates/transcript/transcript.php?storyId=128907099 enjoy! On Mon, Aug 2, 2010 at 11:22 AM, Jim Fleming wrote: > ARIN on NPR - Public Confusion, Perception & Reputation ? > > 1. "ARIN" was on NPR... > http://www.ietf.org/mail-archive/web/ipv6/current/msg12092.html > > http://www.npr.org/templates/story/story.php?storyId=10 > > > 2. ARIN is 4-letters > > 3. ARIN.NET is widely known > > 4. The ICANN CEO has declared .NET to be a "worthless TLD". > > 5. Someone secretly purchased ARIN.COM for an un-disclosed sum prior to a > major lawsuit. > > 6. ARIN claims to be non-profit and the public assumes that would be > ARIN.ORG > > 7. DNS Reputation Systems are starting to be disclosed by ARIN > Executives/Leaders/Management? > http://www.circleid.com/posts/20100728_taking_back_the_dns/#6860 > > 8. IN-ADDR.ARPA Zones are part of the DNS and will allow "Reputations" for > sections of IP Address Space > [Will companies have a choice to not be with the .XXX zones?] > > 9. IANA Scheme Names are now on investor's radar screens...they are FREE as > in $$$ ? > http://www.iana.org/assignments/uri-schemes.html > http:// > mail:// > news:// > xxx:// > and all 4-Letter Strings ? > ARIN:// > zoom://ZOOM > > 10. Twitter appears to be willing to give 4-Letter .COM owners their names, > without a battle > > 11. The 4-Letter .COM owners have FREE IPv6 Address Space (ARIN.COM also) > > --- > Where is ARIN headed ? to the .NET only core ? to .ORG ? to .COM ? to just > the Brand "ARIN" ? > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Aug 2 17:05:22 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 02 Aug 2010 14:05:22 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <4C571A1F.1060208@chl.com> References: <20100730141545.A77546@eboyr.pbz> <20100731022000.92ACC2B2135@mx5.roble.com> <1BB98D09-528F-4576-9F02-DED9E5B529B2@delong.com> <4C5495C1.2070404@ipinc.net> <4C571A1F.1060208@chl.com> Message-ID: <4C573312.3090608@ipinc.net> On 8/2/2010 12:18 PM, Joe Maimon wrote: > > > Owen DeLong wrote: > > >> The fact that NAT is widespread does not mean we can't deploy >> IPv6 without introducing that damage to IPv6. NAT is not the poor >> man's firewall, just a case of ignorance on the part of the poor >> man. The poor man's firewall is and has long been stateful >> inspection with a default deny inbound policy for all traffic not >> matching an existing state table entry. That works with or >> without the address mangling of NAT. NAT, on the other hand, >> does not work without stateful inspection. >> >> NAT does cause problems even for the single-homed small >> environment, whether those environments are aware of the >> problems or not. >> >> Owen >> > > I would like to address this specific point, oft repeated that NAPT's > stateful inspection protection is a byproduct and can easily be replaced > with a basic firewall turned on by default. > > While certainly true from a technical viewpoint, I think this glosses > over a somewhat non technical practical reality and interaction between > protocols, vendors, firewalls, designers, users and administrators. > > Without the ubiquity of NAPT, how long do you think it will be before > having a default deny inbound rule becomes non practical, or that UPNP > hole punching is a basic requirement to the extent that firewall are a > swiss cheese joke? > > How many times as a NAT/Firewall admin on any size or class device have > you been asked to "open the firewall" for this or that protocol? > > Do those requesters even understand the concept of flow > direction/initiation? The difference between permit rules and inbound > translation maps, the difference between bi-directional static NAT and > multiplexed NAPT or differing inside and outside ports? Have they even > tried using the application before blaming the "firewall"? Do they know > which ports and protocols are involved or whether the application can be > tuned to work properly without a specific inbound permit, or worse a > gigantic monster truck sized 16K dynamic port range hole? Yeah, I > thought so. Its you who is the bad guy, breaking their cute little > protocol/application. Now apply that to the residential market. > > Protocol designers, users and administrators are not any less lazy than > the rest of us. Possibly more. NAT ubiquity have forced all but the die > hard idealists to avoid any use of cheap protocols tricks that prove > burdensome and unwieldy in not only a NAPT environment, but also in an > SPI environment, except as properly justified or required (one hopes). > > That is a good thing in my opinion and I would hate to see the pendulum > swing the other way to the extent that cheap CPE which are not intended > to burden its user with actual operation of them can no longer use a > default deny inbound SPI. > > Its much easier to tell someone turn off the firewall if you want my > protocol to work "just for testing" than to tell them to turn off NAPT. > > In the former, the protocol will magically start to work and the > firewall will stay off. In the latter, nothing will work and NAT will be > turned back on. In a sense, this is the correct expansive definition of > the phrase "NAT fails close", where fail is the failure of protocols, > admins and users to adhere to proper security diligence. > > Lets face it, requiring L4 and higher protocols to have knowledge of L3 > detail is a layering violation and should be frowned upon by those who > believe layering violations are the source of all protocol evil. > > So where does this leave me? I believe firmly that NAPT should become a > choice made by users, not a requirement for basic service as it is now, > nor a practical impossibility as IPv6 currently intends. > The problem is that comparing IPv4 NAT to some hypothetical IPv6 NAT implementation isn't an apples-to-apples comparison. For the residential CPE folks, you can build a cheap, NATless IPv6 CPE that has a default inbound deny rule and stateful inspection, that uses UPnP to open holes as-needed, automagically. SO I don't even count them in the equation. For the corporate folks, the principle reason to use NAT is that their ISP cannot supply them with enough public numbers as needed for the inside, or if they can they would be very expensive. That won't be a problem with IPv6. Thus, NAT is a requirement for them for IPv4 at the current time, and all examination and discussion of security, portability and everything else all revolves around the NAT environment from the get-go. With IPv6, NAT is not a requirement so that assumption does not hold true. I could logically prove that a NAT-less IPv4 connection is just as secure as a NAT-less IPv6 connection but it's always going to be trumped by the requirement for NAT due to the small supply of public IP addresses any org gets from their ISP. Ted From Daniel_Alexander at Cable.Comcast.com Mon Aug 2 17:22:20 2010 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 2 Aug 2010 17:22:20 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> Thank you Chris and Owen for the replies. I think you articulated the point better than I did. If we were talking about simply stretching out the last pieces of IPv4 space, both rationing or the technical requirements could probably be tweaked to accomplish the same thing. The difference is the attempt to leverage the last pieces of IPv4 to facilitate IPv6 deployments. What I question is whether technology requirements are the proper knob to try and turn. Will adding things like review panels and acceptable lists of transition technologies actually achieve the objective of getting IPv6 deployed, or will it just distract people to debate what are acceptable methods in how to get there? I am trying to understand the policy gap we are trying to fill here. How will the current policy be abused that staff cannot manage? And will the gains achieved in preventing this abuse really be offset by the addition of review panels on what everyone deems "acceptable" transition technologies. Just adding my $.02 to your $.02. Soon we will be rich. :) -Dan -----Original Message----- From: Chris Grundemann [mailto:cgrundemann at gmail.com] Sent: Monday, August 02, 2010 10:27 AM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel wrote: > > Not too long ago there were policy discussions about rationing the last of > the IP resources allocated to ARIN. Many were opposed to this. The general > opinion was that organizations should not be denied needed resources now, > for something that may be needed later. Then some found a compromise in > section4.10. > > Then there are proposals that suggest parking resources for the future > because we cannot be sure what the situation will be two years from now. > These topics were met with opposition against denying known, current needs > for unknown circumstances in the future. > > Finally, there are the discussions about rationing the last bits of IPv4 > space by defining what technologies are worthy of receiving the last of the > unallocated IPv4 resources. > > So a couple questions come to mind. > > Of all the methods being discussed, aren't they just rationing in one form > or another? If so, they why don't we simplify the conversation and ration > the last of the IP space by size and timeframe without all the requirements > on an organization that add to the overhead of ARIN staff? Wouldn't the end > result be the same? I don't think it would be the same. They key difference in the proposals currently on the table and pure rationing (with no technical requirements) is the focus on transitioning to IPv6. > Should ARIN be defining topologies or technologies for an organization? Many > argued strongly in the past against this direction. How much will really be > accomplished fine tuning the use of the last 0.4% of the IPv4 space compared > to how the other 99.996% is being used? ARIN should not define topologies or technologies, no. But... If ARIN is going to restrict a block of addresses to "transitional technologies" than it probably makes sense to define or at least explain through example what is meant by "transitional technology." Defining a term is not quite the same as defining the specific technology or topology to be used. Also - the fight against ARIN getting involved in operational matters is a valid one but not one that we can take to either extreme. As has also been discussed many times before, minimum and maximum allocations and assignments define operational practices to some extent, as does efficient utilization requirements, needs based justification, etc. There is a balance that must be maintained, not an absolute law to be followed. Internet stewardship should be the guiding beacon, and sometimes that means dipping our toes into issues that have effects on operational practice. To your second point; I would reverse the question: How much will we gain by allowing the last 0.4% of the IPv4 space be used just like the other 99.996%? Once we level set, then we can ask how much can we gain by tweaking the use of that same space. In that context, I think it is clear that the bigger win is in tuning the use, rather than taking our hands off the wheel. > Are some forms of rationing more acceptable than others? I'm curious if > there are some who are opposed to outright rationing but find putting > requirements on technologies as an acceptable middle ground? What do they > feel is the difference or the compromise? The goal is not to slow the usage of the last piece of unallocated IPv4 space (rationing), the focus is on leveraging that last piece to accelerate the adoption of IPv6 and the (re)homogenization of the Internet (technical restrictions). $0.02 ~Chris > Please let me know your thoughts. > Dan Alexander > ARIN AC > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From tedm at ipinc.net Mon Aug 2 18:11:34 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 02 Aug 2010 15:11:34 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> References: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> Message-ID: <4C574296.5070200@ipinc.net> On 8/2/2010 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > In my opinion I believe that ARIN should definitely do more to promote "recommended lists of transition technlogies" I would shy away from the verbage "acceptable lists of transition technologies" Ted > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > From cgrundemann at gmail.com Mon Aug 2 18:14:21 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 2 Aug 2010 16:14:21 -0600 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> References: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> Message-ID: On Mon, Aug 2, 2010 at 15:22, Alexander, Daniel wrote: > > I am trying to understand the policy gap we are trying to fill here. Looking strictly at the existing policy (section 4.10. of the NRPM), I think the gaps that need addressed are: 1) A /10 is to small. 2) Future returns and reclamations are not addressed. 3) Current transitional needs are not addressed. 4) The /28 minimum is too small. 5) The /24 maximum over 6 months is too small. 6) Renumbering should be avoided if at all possible. 7) The policy could go further in advancing IPv6 deployment while still allowing the Internet to grow. I hate to list problems without solutions, so here is how I would address those gaps (much/all of this has already been proposed or at least suggested by folks much smarter than I): 1) Commit the entire last /8 to this purpose. 2) Allocate all future returned and/or reclaimed IPv4 space to this purpose. 3) Allow Orgs to apply for transition space now, and allocate that space from the general unallocated pool until we reach the last /8. 4) Hand out a /24 minimum, in the case of smaller Orgs, make that /24 based on a longer-than-6-month utilization window. If they really can't justify a /24, send them to their upstream(s). 5) The window should be 3 months (possibly even 2). The maximum allocation/assignment is negotiable but will need to be higher than /24. 6) A long-term reservation solves the re-numbering problem (like the 30-month forcast that Marty has suggested). 7) A complete and definitive white-list of all current and future technologies is not realistic nor desirable, imho. What may be very useful is some more text around what types of uses should qualify and an expanded list of examples. Also, if there are technologies that should be allowed but only with certain caveats or restrictions, those should be spelled out explicitly. Does that make $.08? ~Chris > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From owen at delong.com Mon Aug 2 18:22:06 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 15:22:06 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> References: <997BC128AE961E4A8B880CD7442D948018A42E92@NJCHLEXCMB01.cable.comcast.com> Message-ID: <9610FA7A-7C77-46B6-827F-E0A19EDA77D9@delong.com> So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Daniel_Alexander at Cable.Comcast.com Mon Aug 2 21:58:05 2010 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 2 Aug 2010 21:58:05 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <9610FA7A-7C77-46B6-827F-E0A19EDA77D9@delong.com> Message-ID: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. On 8/2/10 6:22 PM, "Owen DeLong" wrote: > So far, proposal 116 does not establish a review panel and I remain > unconvinced that doing so is the correct approach vs. leaving it to > staff judgment guided by the BoT. > > I'm open to any suggestions on a better way to limit abuse, but, it was > made obvious to by a number of people that 4.10 can be easily perverted > into pretty much business-as-usual by the creative leaving no IPv4 addresses > available for true cases of need in order to deploy IPv6. I would hate to see > us end up in that kind of dead-lock because we failed to address and > close a loophole in a policy that was passed with a general community > understanding of "This is a good placeholder, we'll make it more specific > when the time comes and we better understand the implications." > > While you could well argue that we still don't understand the implications > significantly better than when 4.10 was enacted, I do not think it is possible > to argue that the time has not come. Atlanta may well be the last public > policy meeting prior to IANA runout. In fact, I will be very surprised if it > is > not. > > As such, I think it is very important to get something on the agenda for > Atlanta > with the possibility of becoming policy, even if we need to tweak it > in last call. > > Owen > > On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > >> > Thank you Chris and Owen for the replies. I think you articulated the >> > point better than I did. If we were talking about simply stretching out >> > the last pieces of IPv4 space, both rationing or the technical >> > requirements could probably be tweaked to accomplish the same thing. The >> > difference is the attempt to leverage the last pieces of IPv4 to >> > facilitate IPv6 deployments. >> > >> > What I question is whether technology requirements are the proper knob >> > to try and turn. Will adding things like review panels and acceptable >> > lists of transition technologies actually achieve the objective of >> > getting IPv6 deployed, or will it just distract people to debate what >> > are acceptable methods in how to get there? >> > >> > I am trying to understand the policy gap we are trying to fill here. How >> > will the current policy be abused that staff cannot manage? And will the >> > gains achieved in preventing this abuse really be offset by the addition >> > of review panels on what everyone deems "acceptable" transition >> > technologies. >> > >> > Just adding my $.02 to your $.02. Soon we will be rich. :) >> > -Dan >> > >> > >> > -----Original Message----- >> > From: Chris Grundemann [mailto:cgrundemann at gmail.com] >> > Sent: Monday, August 02, 2010 10:27 AM >> > To: Alexander, Daniel >> > Cc: arin-ppml at arin.net >> > Subject: Re: [arin-ppml] Do people see a middle ground? >> > >> > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel >> > wrote: >>> >> >>> >> Not too long ago there were policy discussions about rationing the >> > last of >>> >> the IP resources allocated to ARIN. Many were opposed to this. The >> > general >>> >> opinion was that organizations should not be denied needed resources >> > now, >>> >> for something that may be needed later. Then some found a compromise >> > in >>> >> section4.10. >>> >> >>> >> Then there are proposals that suggest parking resources for the future >>> >> because we cannot be sure what the situation will be two years from >> > now. >>> >> These topics were met with opposition against denying known, current >> > needs >>> >> for unknown circumstances in the future. >>> >> >>> >> Finally, there are the discussions about rationing the last bits of >> > IPv4 >>> >> space by defining what technologies are worthy of receiving the last >> > of the >>> >> unallocated IPv4 resources. >>> >> >>> >> So a couple questions come to mind. >>> >> >>> >> Of all the methods being discussed, aren't they just rationing in one >> > form >>> >> or another? If so, they why don't we simplify the conversation and >> > ration >>> >> the last of the IP space by size and timeframe without all the >> > requirements >>> >> on an organization that add to the overhead of ARIN staff? Wouldn't >> > the end >>> >> result be the same? >> > >> > I don't think it would be the same. They key difference in the >> > proposals currently on the table and pure rationing (with no technical >> > requirements) is the focus on transitioning to IPv6. >> > >>> >> Should ARIN be defining topologies or technologies for an >> > organization? Many >>> >> argued strongly in the past against this direction. How much will >> > really be >>> >> accomplished fine tuning the use of the last 0.4% of the IPv4 space >> > compared >>> >> to how the other 99.996% is being used? >> > >> > ARIN should not define topologies or technologies, no. But... If ARIN >> > is going to restrict a block of addresses to "transitional >> > technologies" than it probably makes sense to define or at least >> > explain through example what is meant by "transitional technology." >> > Defining a term is not quite the same as defining the specific >> > technology or topology to be used. Also - the fight against ARIN >> > getting involved in operational matters is a valid one but not one >> > that we can take to either extreme. As has also been discussed many >> > times before, minimum and maximum allocations and assignments define >> > operational practices to some extent, as does efficient utilization >> > requirements, needs based justification, etc. There is a balance that >> > must be maintained, not an absolute law to be followed. Internet >> > stewardship should be the guiding beacon, and sometimes that means >> > dipping our toes into issues that have effects on operational >> > practice. >> > >> > To your second point; I would reverse the question: How much will we >> > gain by allowing the last 0.4% of the IPv4 space be used just like the >> > other 99.996%? Once we level set, then we can ask how much can we gain >> > by tweaking the use of that same space. In that context, I think it is >> > clear that the bigger win is in tuning the use, rather than taking our >> > hands off the wheel. >> > >>> >> Are some forms of rationing more acceptable than others? I'm curious >> > if >>> >> there are some who are opposed to outright rationing but find putting >>> >> requirements on technologies as an acceptable middle ground? What do >> > they >>> >> feel is the difference or the compromise? >> > >> > The goal is not to slow the usage of the last piece of unallocated >> > IPv4 space (rationing), the focus is on leveraging that last piece to >> > accelerate the adoption of IPv6 and the (re)homogenization of the >> > Internet (technical restrictions). >> > >> > $0.02 >> > ~Chris >> > >>> >> Please let me know your thoughts. >>> >> Dan Alexander >>> >> ARIN AC >>> >> _______________________________________________ >>> >> PPML >>> >> You are receiving this message because you are subscribed to >>> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> >> Unsubscribe or manage your mailing list subscription at: >>> >> http://lists.arin.net/mailman/listinfo/arin-ppml >>> >> Please contact info at arin.net if you experience any issues. >>> >> >> > >> > -- >> > @ChrisGrundemann >> > weblog.chrisgrundemann.com >> > www.burningwiththebush.com >> > www.coisoc.org >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/arin-ppml >> > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sob at academ.com Mon Aug 2 22:00:31 2010 From: sob at academ.com (Stan Barber) Date: Mon, 02 Aug 2010 21:00:31 -0500 Subject: [arin-ppml] (no subject) Message-ID: <27b46ee6ed3439071930079ad4f930c4@academ.com> I support the petition for discussion of proposal 116. Stan Barber (SB98-ARIN) Academ Consulting Services (ACS-12) sob at academ.com 1713747270 From owen at delong.com Mon Aug 2 23:16:11 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 20:16:11 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: Message-ID: <069152E2-D28D-4ED6-8CED-C1622CF1C63C@delong.com> 4.10 currently does nothing to define what is a "transitional technology". Arguably, addresses for dual-homed hosts could be called a "transitional technology". NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). Staff has stated that 4.10 is too vague to implement effectively. When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. Owen On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: > > Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. > > > On 8/2/10 6:22 PM, "Owen DeLong" wrote: > >> So far, proposal 116 does not establish a review panel and I remain >> unconvinced that doing so is the correct approach vs. leaving it to >> staff judgment guided by the BoT. >> >> I'm open to any suggestions on a better way to limit abuse, but, it was >> made obvious to by a number of people that 4.10 can be easily perverted >> into pretty much business-as-usual by the creative leaving no IPv4 addresses >> available for true cases of need in order to deploy IPv6. I would hate to see >> us end up in that kind of dead-lock because we failed to address and >> close a loophole in a policy that was passed with a general community >> understanding of "This is a good placeholder, we'll make it more specific >> when the time comes and we better understand the implications." >> >> While you could well argue that we still don't understand the implications >> significantly better than when 4.10 was enacted, I do not think it is possible >> to argue that the time has not come. Atlanta may well be the last public >> policy meeting prior to IANA runout. In fact, I will be very surprised if it is >> not. >> >> As such, I think it is very important to get something on the agenda for Atlanta >> with the possibility of becoming policy, even if we need to tweak it >> in last call. >> >> Owen >> >> On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: >> >> > Thank you Chris and Owen for the replies. I think you articulated the >> > point better than I did. If we were talking about simply stretching out >> > the last pieces of IPv4 space, both rationing or the technical >> > requirements could probably be tweaked to accomplish the same thing. The >> > difference is the attempt to leverage the last pieces of IPv4 to >> > facilitate IPv6 deployments. >> > >> > What I question is whether technology requirements are the proper knob >> > to try and turn. Will adding things like review panels and acceptable >> > lists of transition technologies actually achieve the objective of >> > getting IPv6 deployed, or will it just distract people to debate what >> > are acceptable methods in how to get there? >> > >> > I am trying to understand the policy gap we are trying to fill here. How >> > will the current policy be abused that staff cannot manage? And will the >> > gains achieved in preventing this abuse really be offset by the addition >> > of review panels on what everyone deems "acceptable" transition >> > technologies. >> > >> > Just adding my $.02 to your $.02. Soon we will be rich. :) >> > -Dan >> > >> > >> > -----Original Message----- >> > From: Chris Grundemann [mailto:cgrundemann at gmail.com] >> > Sent: Monday, August 02, 2010 10:27 AM >> > To: Alexander, Daniel >> > Cc: arin-ppml at arin.net >> > Subject: Re: [arin-ppml] Do people see a middle ground? >> > >> > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel >> > wrote: >> >> >> >> Not too long ago there were policy discussions about rationing the >> > last of >> >> the IP resources allocated to ARIN. Many were opposed to this. The >> > general >> >> opinion was that organizations should not be denied needed resources >> > now, >> >> for something that may be needed later. Then some found a compromise >> > in >> >> section4.10. >> >> >> >> Then there are proposals that suggest parking resources for the future >> >> because we cannot be sure what the situation will be two years from >> > now. >> >> These topics were met with opposition against denying known, current >> > needs >> >> for unknown circumstances in the future. >> >> >> >> Finally, there are the discussions about rationing the last bits of >> > IPv4 >> >> space by defining what technologies are worthy of receiving the last >> > of the >> >> unallocated IPv4 resources. >> >> >> >> So a couple questions come to mind. >> >> >> >> Of all the methods being discussed, aren't they just rationing in one >> > form >> >> or another? If so, they why don't we simplify the conversation and >> > ration >> >> the last of the IP space by size and timeframe without all the >> > requirements >> >> on an organization that add to the overhead of ARIN staff? Wouldn't >> > the end >> >> result be the same? >> > >> > I don't think it would be the same. They key difference in the >> > proposals currently on the table and pure rationing (with no technical >> > requirements) is the focus on transitioning to IPv6. >> > >> >> Should ARIN be defining topologies or technologies for an >> > organization? Many >> >> argued strongly in the past against this direction. How much will >> > really be >> >> accomplished fine tuning the use of the last 0.4% of the IPv4 space >> > compared >> >> to how the other 99.996% is being used? >> > >> > ARIN should not define topologies or technologies, no. But... If ARIN >> > is going to restrict a block of addresses to "transitional >> > technologies" than it probably makes sense to define or at least >> > explain through example what is meant by "transitional technology." >> > Defining a term is not quite the same as defining the specific >> > technology or topology to be used. Also - the fight against ARIN >> > getting involved in operational matters is a valid one but not one >> > that we can take to either extreme. As has also been discussed many >> > times before, minimum and maximum allocations and assignments define >> > operational practices to some extent, as does efficient utilization >> > requirements, needs based justification, etc. There is a balance that >> > must be maintained, not an absolute law to be followed. Internet >> > stewardship should be the guiding beacon, and sometimes that means >> > dipping our toes into issues that have effects on operational >> > practice. >> > >> > To your second point; I would reverse the question: How much will we >> > gain by allowing the last 0.4% of the IPv4 space be used just like the >> > other 99.996%? Once we level set, then we can ask how much can we gain >> > by tweaking the use of that same space. In that context, I think it is >> > clear that the bigger win is in tuning the use, rather than taking our >> > hands off the wheel. >> > >> >> Are some forms of rationing more acceptable than others? I'm curious >> > if >> >> there are some who are opposed to outright rationing but find putting >> >> requirements on technologies as an acceptable middle ground? What do >> > they >> >> feel is the difference or the compromise? >> > >> > The goal is not to slow the usage of the last piece of unallocated >> > IPv4 space (rationing), the focus is on leveraging that last piece to >> > accelerate the adoption of IPv6 and the (re)homogenization of the >> > Internet (technical restrictions). >> > >> > $0.02 >> > ~Chris >> > >> >> Please let me know your thoughts. >> >> Dan Alexander >> >> ARIN AC >> >> _______________________________________________ >> >> PPML >> >> You are receiving this message because you are subscribed to >> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> Please contact info at arin.net if you experience any issues. >> >> >> > >> > -- >> > @ChrisGrundemann >> > weblog.chrisgrundemann.com >> > www.burningwiththebush.com >> > www.coisoc.org >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/arin-ppml >> > Please contact info at arin.net if you experience any issues. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Tue Aug 3 01:57:01 2010 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 2 Aug 2010 22:57:01 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <44263b4900e19189ce5ca6c701c33f34@8-continents.com> References: <4C5260B2.3070803@quark.net> <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> <44263b4900e19189ce5ca6c701c33f34@8-continents.com> Message-ID: On Sun, Aug 1, 2010 at 16:32, Andrew Dul - andrew.dul wrote: > I have a little bit of a problem with the 116 text in that it attempts to > specify the technologies, but then has "etc" and "other transitional > technologies at the time of proposal" as escape clauses. ?Seems to me that > the current 4.10 language of some examples and staff discretion is OK. Just to throw out a thought as to the technologies, would something like the formulation of an IETF WG on tne transition technology be a replacement for a "small panel of experts"? Would the bar be too high? Too low? Would it pass muster with ARIN legal? Gary From owen at delong.com Tue Aug 3 02:36:37 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Aug 2010 23:36:37 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: References: <4C5260B2.3070803@quark.net> <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> <44263b4900e19189ce5ca6c701c33f34@8-continents.com> Message-ID: On Aug 2, 2010, at 10:57 PM, Gary Buhrmaster wrote: > On Sun, Aug 1, 2010 at 16:32, Andrew Dul - andrew.dul > wrote: >> I have a little bit of a problem with the 116 text in that it attempts to >> specify the technologies, but then has "etc" and "other transitional >> technologies at the time of proposal" as escape clauses. Seems to me that >> the current 4.10 language of some examples and staff discretion is OK. > > Just to throw out a thought as to the technologies, would something > like the formulation of an IETF WG on tne transition technology be a > replacement for a "small panel of experts"? Would the bar be too > high? Too low? Would it pass muster with ARIN legal? > I think that the panel of experts idea probably isn't going to take hold. I think it's going to be staff discretion aided by guidance from the BoT. There just wasn't much support and a number of concerns surrounding the implementation of a panel. The problem with the existing 4.10 language, Andrew, is that staff has basically said it is too open ended and wouldn't really give them the tools to narrow the field at all. The escape clauses are there for that reason, so that staff still has discretion to approve things not considered in the policy text. To clarify, the second clause is "other transitional technologies NOT envisioned at the time of this proposal". It's an attempt to prevent the policy from penalizing innovation in that area. Look for some updates to 116 in the near future which I hope will greatly expand the support base for it. Owen From bicknell at ufp.org Tue Aug 3 08:24:52 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 3 Aug 2010 05:24:52 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <44263b4900e19189ce5ca6c701c33f34@8-continents.com> References: <4C5260B2.3070803@quark.net> <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> <44263b4900e19189ce5ca6c701c33f34@8-continents.com> Message-ID: <20100803122452.GA11574@ussenterprise.ufp.org> In a message written on Sun, Aug 01, 2010 at 10:32:15AM -0600, Andrew Dul - andrew.dul wrote: > I have a little bit of a problem with the 116 text in that it attempts to > specify the technologies, but then has "etc" and "other transitional > technologies at the time of proposal" as escape clauses. Seems to me that > the current 4.10 language of some examples and staff discretion is OK. I think it is way too premature to know which transition technologies will be widely deployed and need this space. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From marty at akamai.com Tue Aug 3 08:39:31 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 3 Aug 2010 08:39:31 -0400 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100803122452.GA11574@ussenterprise.ufp.org> Message-ID: On 8/3/10 8:24 AM, "Leo Bicknell" wrote: > In a message written on Sun, Aug 01, 2010 at 10:32:15AM -0600, Andrew Dul - > andrew.dul wrote: >> I have a little bit of a problem with the 116 text in that it attempts to >> specify the technologies, but then has "etc" and "other transitional >> technologies at the time of proposal" as escape clauses. Seems to me that >> the current 4.10 language of some examples and staff discretion is OK. > > I think it is way too premature to know which transition technologies > will be widely deployed and need this space. I agree, but a little bit of discretion and the ability to change the policy either during a pp meeting or by other means that are in-line with the intent of the policy are reasonable solutions to such a concern. Best, -M< From kkargel at polartel.com Tue Aug 3 14:18:17 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 3 Aug 2010 13:18:17 -0500 Subject: [arin-ppml] Set aside round deux In-Reply-To: <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> Message-ID: <8695009A81378E48879980039EEDAD288C0498D7@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Monday, August 02, 2010 1:44 AM > To: Roger Marquis > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Set aside round deux > > SNIP > > The majority of network engineers, on the other hand, are unlikely > to think that NAT is anything better than a necessary evil in IPv4 > at best and no longer necessary in IPv6. > > Owen > I wanted to chime in here and support Owen. I am an active SysAdmin for an ISP and I completely agree with the designation of NAT/PAT as a necessary evil. A simple stateful inspection firewall will provide at least as much security as NAT, be much simpler with less overhead, simplify troubleshooting and provide an easy method of reversal should rolls change or troubleshooting require. NAT/PAT breaks many common consumer applications, requiring complex workarounds that consume much helpdesk time. NAT costs my organization time (s/time/money/g) every day when we have to deal with it. That time would be much reduced if we could simply add an 'allow' rule rather than going through the steps to properly configure PAT. Kevin From Daniel_Alexander at Cable.Comcast.com Tue Aug 3 22:33:49 2010 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 3 Aug 2010 22:33:49 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <069152E2-D28D-4ED6-8CED-C1622CF1C63C@delong.com> References: <069152E2-D28D-4ED6-8CED-C1622CF1C63C@delong.com> Message-ID: <997BC128AE961E4A8B880CD7442D948018B0478B@NJCHLEXCMB01.cable.comcast.com> I'll try and make this one of the last questions. Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? -Dan From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, August 02, 2010 11:16 PM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? 4.10 currently does nothing to define what is a "transitional technology". Arguably, addresses for dual-homed hosts could be called a "transitional technology". NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). Staff has stated that 4.10 is too vague to implement effectively. When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. Owen On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. On 8/2/10 6:22 PM, "Owen DeLong" > wrote: So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Aug 4 00:40:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Aug 2010 21:40:52 -0700 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <997BC128AE961E4A8B880CD7442D948018B0478B@NJCHLEXCMB01.cable.comcast.com> References: <069152E2-D28D-4ED6-8CED-C1622CF1C63C@delong.com> <997BC128AE961E4A8B880CD7442D948018B0478B@NJCHLEXCMB01.cable.comcast.com> Message-ID: My intent in 116 was not so much to create a list as to use a list of examples as the best tool I had available for defining the functionality and depend on staff discretion beyond that. Hence the unfortunately vague choice of terms like "etc." and "technologies not envisioned at the time of this proposal". I certainly would be happy to amend 116 if anyone has better ways to specify this. FWIW, by my count, only 2 more signatures are needed in order for 116 to see discussion in Atlanta. There is still time to sign the petition. Even if you do not feel that 116 as currently written is the best policy we can get, discussing 116 in Atlanta is likely the only chance to do something other than the current state of 4.10 prior to runout. I am extremely amenable to making reasonable changes to 116 in order to gain broader community support. Owen On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote: > I'll try and make this one of the last questions. > > Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? > > -Dan > > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, August 02, 2010 11:16 PM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > 4.10 currently does nothing to define what is a "transitional technology". > > Arguably, addresses for dual-homed hosts could be called a "transitional technology". > > NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a > "transitional technology". > > The reality is that if we allow such uses, there's no set-aside because these "uses" are > essentially identical to the current "business as usual" (residential customers generally > get a single IPv4 address today, for example). > > Staff has stated that 4.10 is too vague to implement effectively. > > When 4.10 was adopted, I recall the discussion both on PPML and at the microphones > expressly including an expectation that clarifying language for how to use the /10 would > be generated as we got closer to need. Atlanta may well be the last public policy meeting > prior to need. As such, I think it is important that we at least bring something to the floor > for discussion there. > > Owen > > On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: > > > > Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. > > > On 8/2/10 6:22 PM, "Owen DeLong" wrote: > > > So far, proposal 116 does not establish a review panel and I remain > unconvinced that doing so is the correct approach vs. leaving it to > staff judgment guided by the BoT. > > I'm open to any suggestions on a better way to limit abuse, but, it was > made obvious to by a number of people that 4.10 can be easily perverted > into pretty much business-as-usual by the creative leaving no IPv4 addresses > available for true cases of need in order to deploy IPv6. I would hate to see > us end up in that kind of dead-lock because we failed to address and > close a loophole in a policy that was passed with a general community > understanding of "This is a good placeholder, we'll make it more specific > when the time comes and we better understand the implications." > > While you could well argue that we still don't understand the implications > significantly better than when 4.10 was enacted, I do not think it is possible > to argue that the time has not come. Atlanta may well be the last public > policy meeting prior to IANA runout. In fact, I will be very surprised if it is > not. > > As such, I think it is very important to get something on the agenda for Atlanta > with the possibility of becoming policy, even if we need to tweak it > in last call. > > Owen > > On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > > > Thank you Chris and Owen for the replies. I think you articulated the > > point better than I did. If we were talking about simply stretching out > > the last pieces of IPv4 space, both rationing or the technical > > requirements could probably be tweaked to accomplish the same thing. The > > difference is the attempt to leverage the last pieces of IPv4 to > > facilitate IPv6 deployments. > > > > What I question is whether technology requirements are the proper knob > > to try and turn. Will adding things like review panels and acceptable > > lists of transition technologies actually achieve the objective of > > getting IPv6 deployed, or will it just distract people to debate what > > are acceptable methods in how to get there? > > > > I am trying to understand the policy gap we are trying to fill here. How > > will the current policy be abused that staff cannot manage? And will the > > gains achieved in preventing this abuse really be offset by the addition > > of review panels on what everyone deems "acceptable" transition > > technologies. > > > > Just adding my $.02 to your $.02. Soon we will be rich. :) > > -Dan > > > > > > -----Original Message----- > > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > > Sent: Monday, August 02, 2010 10:27 AM > > To: Alexander, Daniel > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Do people see a middle ground? > > > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > > wrote: > >> > >> Not too long ago there were policy discussions about rationing the > > last of > >> the IP resources allocated to ARIN. Many were opposed to this. The > > general > >> opinion was that organizations should not be denied needed resources > > now, > >> for something that may be needed later. Then some found a compromise > > in > >> section4.10. > >> > >> Then there are proposals that suggest parking resources for the future > >> because we cannot be sure what the situation will be two years from > > now. > >> These topics were met with opposition against denying known, current > > needs > >> for unknown circumstances in the future. > >> > >> Finally, there are the discussions about rationing the last bits of > > IPv4 > >> space by defining what technologies are worthy of receiving the last > > of the > >> unallocated IPv4 resources. > >> > >> So a couple questions come to mind. > >> > >> Of all the methods being discussed, aren't they just rationing in one > > form > >> or another? If so, they why don't we simplify the conversation and > > ration > >> the last of the IP space by size and timeframe without all the > > requirements > >> on an organization that add to the overhead of ARIN staff? Wouldn't > > the end > >> result be the same? > > > > I don't think it would be the same. They key difference in the > > proposals currently on the table and pure rationing (with no technical > > requirements) is the focus on transitioning to IPv6. > > > >> Should ARIN be defining topologies or technologies for an > > organization? Many > >> argued strongly in the past against this direction. How much will > > really be > >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > > compared > >> to how the other 99.996% is being used? > > > > ARIN should not define topologies or technologies, no. But... If ARIN > > is going to restrict a block of addresses to "transitional > > technologies" than it probably makes sense to define or at least > > explain through example what is meant by "transitional technology." > > Defining a term is not quite the same as defining the specific > > technology or topology to be used. Also - the fight against ARIN > > getting involved in operational matters is a valid one but not one > > that we can take to either extreme. As has also been discussed many > > times before, minimum and maximum allocations and assignments define > > operational practices to some extent, as does efficient utilization > > requirements, needs based justification, etc. There is a balance that > > must be maintained, not an absolute law to be followed. Internet > > stewardship should be the guiding beacon, and sometimes that means > > dipping our toes into issues that have effects on operational > > practice. > > > > To your second point; I would reverse the question: How much will we > > gain by allowing the last 0.4% of the IPv4 space be used just like the > > other 99.996%? Once we level set, then we can ask how much can we gain > > by tweaking the use of that same space. In that context, I think it is > > clear that the bigger win is in tuning the use, rather than taking our > > hands off the wheel. > > > >> Are some forms of rationing more acceptable than others? I'm curious > > if > >> there are some who are opposed to outright rationing but find putting > >> requirements on technologies as an acceptable middle ground? What do > > they > >> feel is the difference or the compromise? > > > > The goal is not to slow the usage of the last piece of unallocated > > IPv4 space (rationing), the focus is on leveraging that last piece to > > accelerate the adoption of IPv6 and the (re)homogenization of the > > Internet (technical restrictions). > > > > $0.02 > > ~Chris > > > >> Please let me know your thoughts. > >> Dan Alexander > >> ARIN AC > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > >> > > > > -- > > @ChrisGrundemann > > weblog.chrisgrundemann.com > > www.burningwiththebush.com > > www.coisoc.org > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquis at roble.com Wed Aug 4 00:45:48 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 3 Aug 2010 21:45:48 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100804044548.052A22B2148@mx5.roble.com> Kevin Kargel wrote: > A simple stateful inspection firewall will provide at least as much > security as NAT, be much simpler with less overhead, simplify > troubleshooting and provide an easy method of reversal should rolls change > or troubleshooting require. This has been gone over here before but please do explain what NAT breaks that wouldn't have otherwise been dealt with by statefull inspection? Yes we know that UPNP and dirt-cheap CPE break easily. Most recognize this as an implementation and not a protocol issue. > NAT/PAT breaks many common consumer applications, requiring complex > workarounds that consume much helpdesk time. NAT costs my organization time > (s/time/money/g) every day when we have to deal with it. Really? "many common consumer applications", such as? > That time would be much reduced if we could simply add an 'allow' rule > rather than going through the steps to properly configure PAT. Good luck selling "we could simply add an 'allow' rule" to the security officer. Consider too that even organizations with sufficient addresses space (from legacy allocations) still use NAT on their internal networks. This is because they have network engineers who understand security. Roger Marquis From JOHN at egh.com Wed Aug 4 00:21:25 2010 From: JOHN at egh.com (John Santos) Date: Wed, 4 Aug 2010 00:21:25 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: <997BC128AE961E4A8B880CD7442D948018B0478B@NJCHLEXCMB01.cable.comcast.com> Message-ID: <1100804000859.24096B-400000@Ives.egh.com> Could some kind of metric be applied? Such as a minimum ratio of the number of IPv6-only hosts that could interact with existing IPv4 hosts per IPv4 address provided under the policy? I.E. If each IPv4 address allowed thousands of IPv6-only hosts to communicate with existing IPv4 hosts, then that would be acceptable. If each IPv4 address only provided communication for a single IPv6 host, then that would not be acceptible as it would be no better than it would be no better than dual-stacking the IPv6 hosts. So somewhere in between there must be a magic number that says "do better than this and it's worth giving you a piece of the dwindling IPv4 pie." Is that number 2? 1 million? Somewhere in between, like 10 or 256 or 10,000? Does the number depend on circumstances/protocol, or should it be the same for everybody? (If its not constant, then it wouldn't make a good metric.) If we can come up with a formula like this, then that should make the ARIN staff's job much easier and better defined, without worrying about specific protocols. The applicant just has to show their expected ratio and how they derived it. If the assumptions are reasonable, and the arithmetic correct, then give them an allocation. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- I'll try and make this one of the last questions. Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? -Dan From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, August 02, 2010 11:16 PM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? 4.10 currently does nothing to define what is a "transitional technology". Arguably, addresses for dual-homed hosts could be called a "transitional technology". NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). Staff has stated that 4.10 is too vague to implement effectively. When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. Owen On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. On 8/2/10 6:22 PM, "Owen DeLong" > wrote: So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kevinb at thewire.ca Wed Aug 4 01:10:08 2010 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 4 Aug 2010 01:10:08 -0400 (EDT) Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: References: <069152E2-D28D-4ED6-8CED-C1622CF1C63C@delong.com> <997BC128AE961E4A8B880CD7442D948018B0478B@NJCHLEXCMB01.cable.comcast.com> Message-ID: <090001cb3393$52c48110$f84d8330$@thewire.ca> I support the petition for discussion of proposal 116. Kevin Blumberg The Wire Inc. T 416.214.9473 x31 From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, August 04, 2010 12:41 AM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? My intent in 116 was not so much to create a list as to use a list of examples as the best tool I had available for defining the functionality and depend on staff discretion beyond that. Hence the unfortunately vague choice of terms like "etc." and "technologies not envisioned at the time of this proposal". I certainly would be happy to amend 116 if anyone has better ways to specify this. FWIW, by my count, only 2 more signatures are needed in order for 116 to see discussion in Atlanta. There is still time to sign the petition. Even if you do not feel that 116 as currently written is the best policy we can get, discussing 116 in Atlanta is likely the only chance to do something other than the current state of 4.10 prior to runout. I am extremely amenable to making reasonable changes to 116 in order to gain broader community support. Owen On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote: I'll try and make this one of the last questions. ? Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? ? -Dan ? From:?Owen DeLong [mailto:owen at delong.com]? Sent:?Monday, August 02, 2010 11:16 PM To:?Alexander, Daniel Cc:?arin-ppml at arin.net Subject:?Re: [arin-ppml] Do people see a middle ground? ? 4.10 currently does nothing to define what is a "transitional technology". ? Arguably, addresses for dual-homed hosts could be called a "transitional technology". ? NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". ? The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). ? Staff has stated that 4.10 is too vague to implement effectively. ? When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. ? Owen ? On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes.? On 8/2/10 6:22 PM, "Owen DeLong" wrote: So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc:?arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >>?http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact?info at arin.net?if you experience any issues. >> > > -- > @ChrisGrundemann >?weblog.chrisgrundemann.com >?www.burningwiththebush.com >?www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: >?http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact?info at arin.net?if you experience any issues. ? From marquis at roble.com Wed Aug 4 01:21:16 2010 From: marquis at roble.com (Roger Marquis) Date: Tue, 3 Aug 2010 22:21:16 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100804052116.85FBC2B2148@mx5.roble.com> Ted Mittelstaedt wrote: > Roger, I cut my teeth using debug to format and compsurf to brand ESDI > drives. I deployed NAT in production when the ONLY way you could do it > was apply a massive patch to the FreeBSD 2.x kernel. This was long > before Cisco released 11.2 IOS which was the first "commercial router" > that supported NAT - and only on certain platforms (ie:2500, not 1000) > and long before Linksys was anything more than a misspelling of a > childrens toy set. And, I daresay, long before YOU knew anything about > what NAT is. So I'm intimately familiar with NAT and how it's used. Most of us old-timers were using application gateways long before FreeBSD 2, even before SunOS 4. NCSA, FWTK, bind 4, sendmail... But I digress, and would just point out that your history is not relevant to the discussion. It is another tangent in place of a technical case. * If you can explain how multihoming will work without NAT and without internal renumbering then please do. If you think internal renumbering is feasible please explain how to maintain persistent connections across a renumbering? * How to would you do transparent load-balancing and fail-over, ingress or egress, without NAT? * Also, since nobody has yet made a good business case for GUA (other that upstream lock-in), please explain how consumers' privacy and vendor independence would be preserved in the GUA world you're advocating. * How would you deal with routing table growth in absence of NAT? * And most importantly, please explain what NAT breaks that stateful inspection has not already "fixed-up"? These are all questions a project manager would need BEFORE proclaiming a project to be feasible. > NAT's days are numbered and no matter how many benefits you think it > brings, one way or another it's going to be gone. Again, lots of assertions, few technical details. Seems to be the MO of NAT-o-phobes. OTOH we have people with far more experience than Ted and I put together, people like John Levine, whose residential nodes have worked behind LSN for months without even knowing it. The majority of neteng departments at small and large shops alike, places like Sun/Oracle, IBM, Yahoo, Google, also use NAT everywhere and don't seem to have Ted's issues. Personally, I prefer facts over opinion, particularly David Farmer's take on the issue: > I think telling other people how to run there network is much more ugly > thing than NAT. And how much ever I dislike NAT, it has been an > effective way to run a network for a lot of people. How effective have > you been in telling other people how to run (or not run) there network? Roger Marquis From michael.dillon at bt.com Wed Aug 4 04:24:06 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 4 Aug 2010 09:24:06 +0100 Subject: [arin-ppml] Set aside round deux In-Reply-To: References: <4C5260B2.3070803@quark.net> <797D62CE-15B7-40CB-AF63-7B5FAF80551A@delong.com> <44263b4900e19189ce5ca6c701c33f34@8-continents.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918093F60@EMV01-UKBR.domain1.systemhost.net> > I think that the panel of experts idea probably isn't going to take > hold. > > I think it's going to be staff discretion aided by guidance from the > BoT. You can't eliminate staff discretion without changing ARIN's charter. So let's work with it and feed it. The applicant must use a transition technology such as NAT-PT 6RD dual stacking NAT64 and similar technologies. This list is not exhaustive and ARIN staff have the discretion to accept any other technology that advances the deployment of IPv6 in the applicant's network and is not merely a stopgap measure like IPv4 NAT whether carrier grade or not. Could use some wordsmithing but the intent is to list the well-known transition technologies that are acceptable, to explicitly note that ARIN staff have the discretion to accept other transition technologies that advance IPv6 deployment, and to note that purely IPv4 technologies are not acceptable justification. Anyone who uses carrier grade NAT is not going to need more addresses anyway. --Michael Dillon From michael.dillon at bt.com Wed Aug 4 04:31:07 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 4 Aug 2010 09:31:07 +0100 Subject: [arin-ppml] Set aside round deux In-Reply-To: <8695009A81378E48879980039EEDAD288C0498D7@MAIL1.polartel.local> References: <20100731204846.H15759@eboyr.pbz> <20100801214028.6D4292B213A@mx5.roble.com> <6EA2E3ED-A302-419D-858A-A32629BFC7B9@delong.com> <8695009A81378E48879980039EEDAD288C0498D7@MAIL1.polartel.local> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423918093F72@EMV01-UKBR.domain1.systemhost.net> > A simple stateful inspection firewall will provide at least as much > security as NAT, be much simpler with less overhead, simplify > troubleshooting and provide an easy method of reversal should rolls > change or troubleshooting require. Announcing the new STeadySTate IPv6 NAT Firewall! Our new No-Address-Translation firewall is the perfect accompaniment to your home's luxurious d?cor. Sitting silently by the telco demarc point, the STeadySTate firewall blocks all incoming IPv6 packets unless you have specifically asked for them. This IPv6 NAT firewall function is the same as you are used to on IPv4 NAT devices, but with the added IPv6 feature of No-Address Translation. This means that you no longer have to run your entire household on one measly IPv4 address. Now your ISP will give you an entire /56 block with millions of addresses which you can use to subnet your home into separate discrete and confidential networks. The STeadySTate IPv6 NAT Firewall is perfect for defining a separate public WiFi network for guests in your home, for setting up a bandwidth-limited teenager network for the kids, and a separate subnet for Mom in the in-law suite. Remember to ask for it by name, the STeadySTate IPv6 NAT Firewall with the added oomph of No-Address Translation, the superior IPv6 protection for your home. --Michael Dillon P.S. Consumers rule! From derrickp2prudent at hotmail.com Wed Aug 4 09:08:35 2010 From: derrickp2prudent at hotmail.com (Derrick Barshell) Date: Wed, 4 Aug 2010 13:08:35 +0000 Subject: [arin-ppml] Welcome to the "ARIN-PPML" mailing list In-Reply-To: References: Message-ID: derrickp2prudent at hotmail.com Derrick P. Barshell Program Administrator YMCA Computer Training Program YMCA of Liberia 126 Crown Hill, Broad Street 1000 Monrovia, 10 Liberia Cell: (+231) 5 481 575 > Subject: Welcome to the "ARIN-PPML" mailing list > From: arin-ppml-request at arin.net > To: derrickp2prudent at hotmail.com > Date: Wed, 4 Aug 2010 05:57:18 -0400 > > Welcome to the ARIN-PPML at arin.net mailing list! > > To post to this list, send your email to: > > arin-ppml at arin.net > > General information about the mailing list is at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > http://lists.arin.net/mailman/options/arin-ppml/derrickp2prudent%40hotmail.com > > > You can also make such adjustments via email by sending a message to: > > ARIN-PPML-request at arin.net > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > gladiator > > Normally, Mailman will remind you of your arin.net mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Wed Aug 4 09:54:50 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 4 Aug 2010 09:54:50 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: Message-ID: I support this petition for Proposal 116. Martin Hannigan OrgID: Akamai 8 Cambridge Center MS/926-G Cambridge, MA 02142 marty at akamai.com On 8/4/10 12:40 AM, "Owen DeLong" wrote: My intent in 116 was not so much to create a list as to use a list of examples as the best tool I had available for defining the functionality and depend on staff discretion beyond that. Hence the unfortunately vague choice of terms like "etc." and "technologies not envisioned at the time of this proposal". I certainly would be happy to amend 116 if anyone has better ways to specify this. FWIW, by my count, only 2 more signatures are needed in order for 116 to see discussion in Atlanta. There is still time to sign the petition. Even if you do not feel that 116 as currently written is the best policy we can get, discussing 116 in Atlanta is likely the only chance to do something other than the current state of 4.10 prior to runout. I am extremely amenable to making reasonable changes to 116 in order to gain broader community support. Owen On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote: I'll try and make this one of the last questions. Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? -Dan From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, August 02, 2010 11:16 PM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? 4.10 currently does nothing to define what is a "transitional technology". Arguably, addresses for dual-homed hosts could be called a "transitional technology". NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). Staff has stated that 4.10 is too vague to implement effectively. When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. Owen On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. On 8/2/10 6:22 PM, "Owen DeLong" > wrote: So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marty at akamai.com Wed Aug 4 09:59:35 2010 From: marty at akamai.com (Hannigan, Martin) Date: Wed, 4 Aug 2010 09:59:35 -0400 Subject: [arin-ppml] Do people see a middle ground? In-Reply-To: Message-ID: Owen, I ?signed? the petition as you saw. I wanted to point out that it is because of the compromises that you have included. I?m still not convinced that it has gone far enough yet, but it is progress. Changes are still required from my perspective, but we should try to get something done this meeting and not the next. Best, -M< On 8/4/10 12:40 AM, "Owen DeLong" wrote: My intent in 116 was not so much to create a list as to use a list of examples as the best tool I had available for defining the functionality and depend on staff discretion beyond that. Hence the unfortunately vague choice of terms like "etc." and "technologies not envisioned at the time of this proposal". I certainly would be happy to amend 116 if anyone has better ways to specify this. FWIW, by my count, only 2 more signatures are needed in order for 116 to see discussion in Atlanta. There is still time to sign the petition. Even if you do not feel that 116 as currently written is the best policy we can get, discussing 116 in Atlanta is likely the only chance to do something other than the current state of 4.10 prior to runout. I am extremely amenable to making reasonable changes to 116 in order to gain broader community support. Owen On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote: I'll try and make this one of the last questions. Are there key functionalities that make a transitional technology "acceptable" for most? Would the policy become more flexible if it were written around this functionality, rather than trying to maintain a list the technologies directly? -Dan From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, August 02, 2010 11:16 PM To: Alexander, Daniel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Do people see a middle ground? 4.10 currently does nothing to define what is a "transitional technology". Arguably, addresses for dual-homed hosts could be called a "transitional technology". NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a "transitional technology". The reality is that if we allow such uses, there's no set-aside because these "uses" are essentially identical to the current "business as usual" (residential customers generally get a single IPv4 address today, for example). Staff has stated that 4.10 is too vague to implement effectively. When 4.10 was adopted, I recall the discussion both on PPML and at the microphones expressly including an expectation that clarifying language for how to use the /10 would be generated as we got closer to need. Atlanta may well be the last public policy meeting prior to need. As such, I think it is important that we at least bring something to the floor for discussion there. Owen On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote: Can we get some examples of how 4.10 can be circumvented. That might help the discussion about how to close any loopholes. On 8/2/10 6:22 PM, "Owen DeLong" > wrote: So far, proposal 116 does not establish a review panel and I remain unconvinced that doing so is the correct approach vs. leaving it to staff judgment guided by the BoT. I'm open to any suggestions on a better way to limit abuse, but, it was made obvious to by a number of people that 4.10 can be easily perverted into pretty much business-as-usual by the creative leaving no IPv4 addresses available for true cases of need in order to deploy IPv6. I would hate to see us end up in that kind of dead-lock because we failed to address and close a loophole in a policy that was passed with a general community understanding of "This is a good placeholder, we'll make it more specific when the time comes and we better understand the implications." While you could well argue that we still don't understand the implications significantly better than when 4.10 was enacted, I do not think it is possible to argue that the time has not come. Atlanta may well be the last public policy meeting prior to IANA runout. In fact, I will be very surprised if it is not. As such, I think it is very important to get something on the agenda for Atlanta with the possibility of becoming policy, even if we need to tweak it in last call. Owen On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote: > Thank you Chris and Owen for the replies. I think you articulated the > point better than I did. If we were talking about simply stretching out > the last pieces of IPv4 space, both rationing or the technical > requirements could probably be tweaked to accomplish the same thing. The > difference is the attempt to leverage the last pieces of IPv4 to > facilitate IPv6 deployments. > > What I question is whether technology requirements are the proper knob > to try and turn. Will adding things like review panels and acceptable > lists of transition technologies actually achieve the objective of > getting IPv6 deployed, or will it just distract people to debate what > are acceptable methods in how to get there? > > I am trying to understand the policy gap we are trying to fill here. How > will the current policy be abused that staff cannot manage? And will the > gains achieved in preventing this abuse really be offset by the addition > of review panels on what everyone deems "acceptable" transition > technologies. > > Just adding my $.02 to your $.02. Soon we will be rich. :) > -Dan > > > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, August 02, 2010 10:27 AM > To: Alexander, Daniel > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Do people see a middle ground? > > On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel > > wrote: >> >> Not too long ago there were policy discussions about rationing the > last of >> the IP resources allocated to ARIN. Many were opposed to this. The > general >> opinion was that organizations should not be denied needed resources > now, >> for something that may be needed later. Then some found a compromise > in >> section4.10. >> >> Then there are proposals that suggest parking resources for the future >> because we cannot be sure what the situation will be two years from > now. >> These topics were met with opposition against denying known, current > needs >> for unknown circumstances in the future. >> >> Finally, there are the discussions about rationing the last bits of > IPv4 >> space by defining what technologies are worthy of receiving the last > of the >> unallocated IPv4 resources. >> >> So a couple questions come to mind. >> >> Of all the methods being discussed, aren't they just rationing in one > form >> or another? If so, they why don't we simplify the conversation and > ration >> the last of the IP space by size and timeframe without all the > requirements >> on an organization that add to the overhead of ARIN staff? Wouldn't > the end >> result be the same? > > I don't think it would be the same. They key difference in the > proposals currently on the table and pure rationing (with no technical > requirements) is the focus on transitioning to IPv6. > >> Should ARIN be defining topologies or technologies for an > organization? Many >> argued strongly in the past against this direction. How much will > really be >> accomplished fine tuning the use of the last 0.4% of the IPv4 space > compared >> to how the other 99.996% is being used? > > ARIN should not define topologies or technologies, no. But... If ARIN > is going to restrict a block of addresses to "transitional > technologies" than it probably makes sense to define or at least > explain through example what is meant by "transitional technology." > Defining a term is not quite the same as defining the specific > technology or topology to be used. Also - the fight against ARIN > getting involved in operational matters is a valid one but not one > that we can take to either extreme. As has also been discussed many > times before, minimum and maximum allocations and assignments define > operational practices to some extent, as does efficient utilization > requirements, needs based justification, etc. There is a balance that > must be maintained, not an absolute law to be followed. Internet > stewardship should be the guiding beacon, and sometimes that means > dipping our toes into issues that have effects on operational > practice. > > To your second point; I would reverse the question: How much will we > gain by allowing the last 0.4% of the IPv4 space be used just like the > other 99.996%? Once we level set, then we can ask how much can we gain > by tweaking the use of that same space. In that context, I think it is > clear that the bigger win is in tuning the use, rather than taking our > hands off the wheel. > >> Are some forms of rationing more acceptable than others? I'm curious > if >> there are some who are opposed to outright rationing but find putting >> requirements on technologies as an acceptable middle ground? What do > they >> feel is the difference or the compromise? > > The goal is not to slow the usage of the last piece of unallocated > IPv4 space (rationing), the focus is on leveraging that last piece to > accelerate the adoption of IPv6 and the (re)homogenization of the > Internet (technical restrictions). > > $0.02 > ~Chris > >> Please let me know your thoughts. >> Dan Alexander >> ARIN AC >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronh at bind.com Wed Aug 4 10:35:02 2010 From: aaronh at bind.com (Aaron Hughes) Date: Wed, 4 Aug 2010 07:35:02 -0700 Subject: [arin-ppml] Petition for discussion of policy proposal 116 Message-ID: <20100804143502.GA86985@trace.bind.com> I support the intent of 116 and am in favor this petition to bring it back to the floor. Cheers, Aaron -- Aaron Hughes aaronh at bind.com +1-831-824-4161 Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8 http://www.bind.com/ From kkargel at polartel.com Wed Aug 4 10:46:01 2010 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 4 Aug 2010 09:46:01 -0500 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100804044548.052A22B2148@mx5.roble.com> References: <20100804044548.052A22B2148@mx5.roble.com> Message-ID: <8695009A81378E48879980039EEDAD288C0498E6@MAIL1.polartel.local> > > This has been gone over here before but please do explain what NAT breaks > that wouldn't have otherwise been dealt with by statefull inspection? > There are many examples but to pick the perhaps most common consumer app talk to anyone who has an Xbox and wants to host games. They can probably quote you chapter and verse about "Strict NAT" and they will be more than happy to tell you about the woes of getting it to work. Yes you can make it work by taking the time to configure port forwarding through NAT or to place the game console in the DMZ, but these are really workarounds to defeat NAT and also defeat any perceived security offered by NAT. > Yes we know that UPNP and dirt-cheap CPE break easily. Most recognize > this as an implementation and not a protocol issue. > > > NAT/PAT breaks many common consumer applications, requiring complex > > workarounds that consume much helpdesk time. NAT costs my organization > time > > (s/time/money/g) every day when we have to deal with it. > > Really? "many common consumer applications", such as? > Almost any of the P2P apps requiring an outside host to initiate a connection. Again, port forwarding or DMZ hosting will resolve that but it is a lot more time (read money) to walk a casual consumer through accomplishing that than it would be to adjust an SPI firewall. > > That time would be much reduced if we could simply add an 'allow' rule > > rather than going through the steps to properly configure PAT. > > Good luck selling "we could simply add an 'allow' rule" to the security > officer. Consider too that even organizations with sufficient addresses > space (from legacy allocations) still use NAT on their internal networks. > This is because they have network engineers who understand security. And this is different from getting the 'security officer' to create a PAT rule for NAT how, aside from taking much less time to accomplish? For the record I am talking about the hordes of residential customers, not from the perspective of an enterprise organization. I don't know of any residential consumers who have a 'security officer'. Most of them will happily do whatever the helpdesk suggests they do. As has been said multiple times here, any security benefits from NAT come from the SPI firewall that is required to implement NAT, not from the NAT itself. > > Roger Marquis From info at arin.net Wed Aug 4 11:15:20 2010 From: info at arin.net (ARIN) Date: Wed, 04 Aug 2010 11:15:20 -0400 Subject: [arin-ppml] Board adopts Draft Policy 2010-2 Message-ID: <4C598408.8060808@arin.net> On 9 July 2010 the ARIN Board of Trustees adopted the following policy: 2010-2: /24 End User Minimum Assignment Unit This policy will be be implemented no later than 30 September 2010. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From cengel at sponsordirect.com Wed Aug 4 11:25:46 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 4 Aug 2010 11:25:46 -0400 Subject: [arin-ppml] Set aside round deux In-Reply-To: Message-ID: > Ted Mittelstaedt wrote: > > Roger, I cut my teeth using debug to format and compsurf to > brand ESDI > > drives. I deployed NAT in production when the ONLY way you > could do it > > was apply a massive patch to the FreeBSD 2.x kernel. This was long > > before Cisco released 11.2 IOS which was the first > "commercial router"............... This discussion again?? We could sit here and compare Tech "street cred." all day. I've been in Enterprise IT since 1990, get glowing marks on every performance review by the business owners and manage network operations and security for an ASP that has had ZERO successfull exploits of it's production servers in it's entire 10 year history of operation. Does that give me enough "street cred." not to be considered a newbie? I rely on NAT as a usefull tool in my tool-box of solutions for specific business needs. I haven't seen anything in IPv6 that adequitely replaces that tool without having greater cost to me then NAT does. I insist on having NAT like solutions on the devices I deploy at MY network boundaries and will continue to do so in an IPv6 world....including defraying adoption of IPv6 until such solutions are available. Unless some-one is paying my salary, it's really not thier place to try to tell me to do otherwise. There are enough folks like me willing to put enough cash on the table for those solutions that sooner or later vendors will listen. The bottom line is that not all experienced engineers have to agree that a specific method is the best way to achieve X (fill in whatever you like for X) nor do all experienced engineers even have to agree that X is desirable to be achieved in the first place. That doesn't make them bad engineers, it doesn't make them ignorant and it doesn't make them wrong... it makes them individuals. Anyone that can't accept that and afford people with differing technical viewpoints some measure of proffesional respect has deeper issues then just techical misunderstandings. You can reiterate the same arguements until you are blue in the face. You simply aren't going to convince me and others like me that NAT isn't useful to me when years of personal experience using it tell me otherwise. Nor, unless you have some means to play internet Stalin and reach into my network, are you going to get me to stop using it. Nor am I going to try to convince you that it is NOT problematic for you... I'm sure it has been. Once I've presented my basic viewpoint on why it's proven useful to me, I'm done. The internet should be a big enough, diverse enough and flexible enough place to accomodate both our viewpoints and our agendas. If it isn't then it fails in it's basic mission. You have two options, you can either accept and accomodate my view as being a valid OPTION for the people who hold it... and try to accomdate that into the work/arguements you make that involve us all... or you can dismiss it. If you choose to dismiss it...I'll simply regard you as some-one unable to work with me....and whatever work or structure you do will loose relevance for me. If anyone wonders why places like ARIN and IETF and the public lists they publish DON'T get more participation from folks like me, it's simple... 1) We are too busy runnning our oganizations daily functions to take much time away to participate. 2) Those organizations don't do a very good job in advertising their public participatory aspects. 3) Every time we do wander into them and attempt to offer a view that differs from that which seems to be accepted by the orthodoxy we get dismissed as ingorant, inexperienced or simply wrong....and our viewpoints aren't taken into account. So what becomes the point of participation? The echo chamber only wants to hear from itself. It's part of the same reasons (IMO) why IPv6 is having such slow adoption... If you give people a "My Way or the Highway" type choice...they are likely to choose the Highway most of the time. On a positive note, there are some folks on this list that are very good at accepting that well meaning and knowledgeble proffesionals CAN disagree on some very basic concepts and still work with one another. I personally, really appreciate how folks like David Farmer can disagree with some of the views that I hold...but still respect that I may have valid reasons for holding them. Christopher Engel From cgrundemann at gmail.com Wed Aug 4 11:29:21 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 4 Aug 2010 09:29:21 -0600 Subject: [arin-ppml] Petition for discussion of policy proposal 116 (Permitted Uses of Space Reserved Under NRPM 4.10) In-Reply-To: <4C472539.7080909@arin.net> References: <4C472539.7080909@arin.net> Message-ID: I support the petition of prop 116, this topic needs to be discussed in Atlanta. ~Chris On Wed, Jul 21, 2010 at 10:50, Member Services wrote: > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement of > support to PPML on this thread. Point of contact information is > required, either to the entire PPML or with a follow up post to > petition at arin.net with full POC information (name, organization, street > address, email, phone). > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From cengel at sponsordirect.com Wed Aug 4 14:12:07 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Wed, 4 Aug 2010 14:12:07 -0400 Subject: [arin-ppml] Set aside round deux In-Reply-To: Message-ID: Kevin Kargel wrote: > > This has been gone over here before but please do explain what NAT > > breaks that wouldn't have otherwise been dealt with by statefull > > inspection? > > > There are many examples but to pick the perhaps most common > consumer app talk to anyone who has an Xbox and wants to host > games. They can probably quote you chapter and verse about > "Strict NAT" and they will be more than happy to tell you > about the woes of getting it to work. > > Yes you can make it work by taking the time to configure port > forwarding through NAT or to place the game console in the > DMZ, but these are really workarounds to defeat NAT and also > defeat any perceived security offered by NAT. I don't have much experience on the consumer side of things but, I assume if the consumer has a reasonably secure network boundary device it will have some sort of DENY ALL IN rule anyway. Which means they are going to need to adjust thier FW to do any sort of hosting in the first place. Is it really that much more difficult to create a NAT entry for the desired device on the FW then it is to create the Allow In rule on the FW? If so, is that a problem with the protocol archetecture or with the UI of the device itself? I've always found it just as easy to setup NAT entries on the devices I've worked with as I have to setup FW rules....albiet I always have a static IP pool to work with on the external interface of my devices..... not sure how much more complicated it gets when you (presumably) are having to use public IP's assigned through DHCP. The benefit of NAT is that it provides a layer of abstraction between the public and private address spaces. An SI firewall doesn't do that, it simply acts as a Gate-Keeper for traffic at the boundary....an incredibly usefull function no doubt...perhaps quite more usefull then abstraction....but not at all the same thing... and not the equivalent of a Gate-Keeper AND Abstraction. With NAT, an external intruder can't compromise the web-server that my printer manufacturer oh so helpfully included as a feature of that device even IF my SI firewall is misconfigured to allow his packets through. He has no way of knowing the printer exists and no way of addressing packets to it to probe for it. He can only probe what I have explicitly externaly advertised through NAT. That solution doesn't force me to deploy a seperate address scheme for public and private addresses on EACH device on my network. Just to have one internal address scheme and a mapping to the bits of it I want publicaly exposed on my FW. Furthermore, the level of abstraction allows me to shift stuff around internaly without changing anything about the external advertisement of services. Thus if I want to move a particular public service from machine #1 to machine #2, I don't need to renumber those machines....and I don't need to call up Charlie, the Admin over at the guys using that service and say "Hey we just switched Service X from x.x.x.27 to x.x.x.52 make the changes on your FW so your users can get to the new machine we're hosting it on." ... I just change the NAT mapping on my FW for those machines. That to me is incredibly usefull. Again, I have no problem with people saying "You know NAT is really, really problematic for the type of situations I deal with..... I really wish I didn't have to employ it." That's a perfectly valid stance to take....and the good news is that IPv6 will allow you to avoid deploying it. That stance is a far cry from "NAT is really, really problematic for me..... therefore it MUST be really, really problematic for you....and you are only deluding yourself that it is usefull.... under our new regieme THOU SHALT NOT USE IT..... we will make no allowence for it." Christopher Engel From info at arin.net Wed Aug 4 17:20:16 2010 From: info at arin.net (ARIN) Date: Wed, 04 Aug 2010 17:20:16 -0400 Subject: [arin-ppml] Petition Successful - Policy Proposal 116. Permitted Uses of space reserved under NRPM 4.10 Message-ID: <4C59D990.5090400@arin.net> The petition received 10 statements of support and is therefore successful. The proposal will be posted shortly as a Draft Policy for discussion and review by the community on the Public Policy Mailing List and at the Public Policy Meeting in October. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Aug 4 17:23:49 2010 From: info at arin.net (ARIN) Date: Wed, 04 Aug 2010 17:23:49 -0400 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 Message-ID: <4C59DA65.6050202@arin.net> Draft Policy 2010-13 Permitted Uses of space reserved under NRPM 4.10 Draft Policy 2010-13 comes from the successful petition of "Policy Proposal 116: Permitted Uses of space reserved under NRPM 4.10." The draft policy is being posted for adoption discussion on the PPML and at the Public Policy Meeting in October. The text of this draft policy is under the control of the petitioner, Owen DeLong, until the conclusion of the Public Policy Meeting. Draft Policy 2010-13 is below and can be found at: https://www.arin.net/policy/proposals/2010_13.html You are encouraged to discuss Draft Policy 2010-13 on the PPML prior to the Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-13 Permitted Uses of space reserved under NRPM 4.10 Version/Date: 4 August 2010 Policy statement: Amend section 4.10 replacing "...a contiguous /10 IPv4 block..." with "...that /8..." and replacing "...within that /10 block." with "within this /8." Add the following to section 4.10 of the NRPM 6. Under this policy, applications must be for one of two types of transitional uses, declared at time of application. (a) An ISP/LIR may request a block not less than a /24 nor more than a /18 to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time ARIN received this reserved block from IANA. 1. No customer may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 space with native IPv6 connectivity to the ISP/LIR and must be making use of IPv6 within their network. 6. The total of all allocations by ARIN under this provision shall not be allowed to consume more than 3/4 of the /8 (the equivalent of a /9 + a /10). 7. No organization shall receive more than a total of a /16 or equivalent under this section. or (b) An ISP/LIR or End user organization may request not less than a /28 and not more than a /24 for purposes relevant to their ability to deploy IPv6 as specified in section 4.12. 1. No organization shall receive more than a total of a /20 or equivalent under this section. 2. Space issued under this policy is an assignment, not an allocation. An LIR may not distribute this space to their customers. 7. For purposes of section 4.10.1, separate times shall be considered for 4.10.6(a) vs. 4.10.6(b). An organization may make applications for both types within 6 months. 8. Other than transfers under NRPM section 8, all space returned to ARIN after IANA depletion shall either be returned to IANA or shall be added to the reserved pool created by 4.10.1. Add the following to section 4 of the NRPM 4.11 Required utilization for subsequent allocation under section 4.10 No organization shall receive more than one allocation or assignment under section 4.10 unless all prior space issued under 4.10 meets the utilization requirements of this section: 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. 2. All utilization must be permitted under section 4.12 3. All prior 4.10 allocation/assignments must be at least 90% utilized. 4. For purposes of this computation, space received under 4.10(a) shall be considered separately from space received under 4.10(b) if an organization has received resources of both types. 4.12 Permitted uses of allocations or assignments under section 4.10(b) No organization shall use space received under section 4.10 for any purpose other than as specified in this section 1. To provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. DNS64 or other transitional DNS enablers e. For other technologies of similar purpose and scope. 2. For other transitional technologies not envisioned at the time of this proposal, but, in no case for general IPv4 addressing provided to customers. 4.13 Quarterly Utilization Monitoring Allocations and assignments under section 4.10 shall be subject to quarterly verification of utilization. 1. An organization which is not meeting their utilization targets may have their allocation or assignment reduced accordingly with the reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. 2. An organization which is using space received under 4.10 in a manner contrary to 4.10 et seq. may have their allocation or assignment reduced or revoked with reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. From marquis at roble.com Thu Aug 5 00:05:37 2010 From: marquis at roble.com (Roger Marquis) Date: Wed, 4 Aug 2010 21:05:37 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100805040537.C81292B213A@mx5.roble.com> >> "many common consumer applications", such as? >> > Almost any of the P2P apps requiring an outside host to initiate a > connection. Again, port forwarding or DMZ hosting will resolve that but it > is a lot more time (read money) to walk a casual consumer through > accomplishing that than it would be to adjust an SPI firewall. If the consumer had spent just a few extra dollars for better equipment they may not have had to get tech support in the first place. I've used Forstwire through Cisco and Juniper firewalls without such application-specific mods. Are you saying the cost of cheap CPE, plus support, plus reduced security is less than the cost of more capable gear? My take would be that would only be true only as long as the cheap CPE with inbound holes doesn't lead to an intrusion. > And this is different from getting the 'security officer' to create a PAT > rule for NAT how, aside from taking much less time to accomplish? Granted it is different but then you're talking about opening a firewall to inbound connections without stateful inspection, or at best with minimal inspection (without deep packet inspection). Wouldn't you agree? > As has been said multiple times here, any security benefits from NAT come > from the SPI firewall that is required to implement NAT, not from the NAT > itself. Well, yes and no. The security benefits of NAT do come from SPI to a degree, as you've indicated, but they also insure that degree of security in a way that other methods of filtering inbound connects have not done to date. Be that as it may I think the best policy, even for cheap CPE, is not to deny consumers a choice of NAT and non-NAT devices, especially when giving them NAT makes IPv6 feasible. Roger Marquis From michael.dillon at bt.com Thu Aug 5 06:14:37 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 5 Aug 2010 11:14:37 +0100 Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391915B429@EMV01-UKBR.domain1.systemhost.net> > > With NAT, an external intruder can't compromise the web-server that my > printer manufacturer oh so helpfully included as a feature of that > device even IF my SI firewall is misconfigured to allow his packets > through. He has no way of knowing the printer exists and no way of > addressing packets to it to probe for it. He can only probe what I have > explicitly externaly advertised through NAT. But this is exactly what IPv6 No-Address Translation does. There is nothing to configure in the IPv6 box. It simply does not let any incoming packets through unless an internal box has already sent outgoing packets. If it is TCP, then the TCP session is allowed to work until the socket is closed. If it is UDP then a short window of opportunity is opened for return packets. The IPv6 No-Address Translation function does not ever translate any addresses. It is purely about admission control to the network based on inspection of outgoing packets. An external party cannot probe your network for addresses which are not currently sending packets to that party. I think that people are thinking of specific implementations of stateful inspection which are part of a larger firewall product and are optional. IPv6 NAT (No-Address Translation) should be implemented as a non-optional part of an Internet gateway device. People who don't want that can install a plain IPv6 router instead. If IPv6 NAT was implemented in this way, then I believe that it would be far more accepted rather than people demanding that IPv4 style address translation should be included in the device as well. > Furthermore, the level of abstraction allows me to shift stuff around > internaly without changing anything about the external advertisement of > services. Thus if I want to move a particular public service from > machine #1 to machine #2, I don't need to renumber those > machines....and I don't need to call up Charlie, the Admin over at the > guys using that service and say "Hey we just switched Service X from > x.x.x.27 to x.x.x.52 make the changes on your FW so your users can get > to the new machine we're hosting it on." ... I just change the NAT > mapping on my FW for those machines. That to me is incredibly usefull. If you are going to install a firewall, then this whole discussion of IPv6 NAT gateways does not apply to you. A firewall has far more features than a NAT box. We are really discussing boxes which have had a bit of firewall functionality (called NAT) added to them but which do not deserve the name, "firewall". --Michael Dillon From marquis at roble.com Thu Aug 5 14:31:23 2010 From: marquis at roble.com (Roger Marquis) Date: Thu, 5 Aug 2010 11:31:23 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100805183123.C1A0F2B214B@mx5.roble.com> michael.dillon at bt.com wrote: > If you are going to install a firewall, then this whole discussion > of IPv6 NAT gateways does not apply to you. A firewall has far more > features than a NAT box. We are really discussing boxes which have > had a bit of firewall functionality (called NAT) added to them but > which do not deserve the name, "firewall". There is no such thing as a "NAT box". Firewalls == NAT == firewalls whichever way you look at it. Getting back to the technical reasons for NAT, or at least trying to, are there no takers for these questions? * If you can explain how multihoming will work without NAT and without internal renumbering then please do. If you think internal renumbering is feasible please explain how to maintain persistent connections across a renumbering? * How to would you do transparent load-balancing and fail-over, ingress or egress, without NAT? * Also, since nobody has yet made a good business case for GUA (other that upstream lock-in), please explain how consumers' privacy and vendor independence would be preserved in the GUA world you're advocating. * How would you deal with routing table growth in absence of NAT? * And most importantly, please explain what NAT breaks that stateful inspection has not already "fixed-up"? Roger Marquis From owen at delong.com Thu Aug 5 15:27:05 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Aug 2010 12:27:05 -0700 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100805183123.C1A0F2B214B@mx5.roble.com> References: <20100805183123.C1A0F2B214B@mx5.roble.com> Message-ID: <06EA2620-C746-472C-BDED-F4A8B9C67348@delong.com> Apologies to PPML, but, there is at least some policy education content to this: On Aug 5, 2010, at 11:31 AM, Roger Marquis wrote: > michael.dillon at bt.com wrote: >> If you are going to install a firewall, then this whole discussion >> of IPv6 NAT gateways does not apply to you. A firewall has far more >> features than a NAT box. We are really discussing boxes which have >> had a bit of firewall functionality (called NAT) added to them but >> which do not deserve the name, "firewall". > > There is no such thing as a "NAT box". Firewalls == NAT == firewalls > whichever way you look at it. > Not quite... Yes, a NAT box cannot function without stateful inspection. However, that does not mean that a NAT box is a firewall. Additionally, you can have firewalls of many forms which DO NOT require or implement NAT. Neither is actually a sub or superset of the other and they are definitely not conjoint twins. > Getting back to the technical reasons for NAT, or at least trying to, are > there no takers for these questions? > > * If you can explain how multihoming will work without NAT and without > internal renumbering then please do. If you think internal renumbering > is feasible please explain how to maintain persistent connections across > a renumbering? > Once again, I will endeavor to explain this to you: If you are multihomed, you can get global unicast addresses directly from your RIR and advertise them to your upstreams, just like multihoming is supposed to work in IPv4. No NAT required, no super special secret technology. Not even different from IPv4 except that because we don't have a shortage of IPv6 addresses, it's easier to get plenty of addresses for your network in IPv6. > * How to would you do transparent load-balancing and fail-over, ingress > or egress, without NAT? > Again, I will endeavor to explain this to you: Border Ingress and Egress -- BGP is fairly good at this. At least as good as any of the cobbled IPv4 NAT solutions I am aware of. LAN Egress -- IPv6 supports the idea of multiple default routers and router liveness detection by default. As such, fail-over is fully automatic and load-balancing merely takes a small amount of effort to properly configure your router-advertisements. LAN Ingress -- As with IPv4 NAT or not, this depends on the configuration of your routing and routing protocols on the routers between your ASBRs and the routers connected to your customer LANs, inclusive. > * Also, since nobody has yet made a good business case for GUA (other > that upstream lock-in), please explain how consumers' privacy and vendor > independence would be preserved in the GUA world you're advocating. > I really don't understand why you keep equating GUA with upstream lock-in. Please explain to me how getting a prefix from ARIN locks you into any particular upstream because I simply am not understanding this argument. > * How would you deal with routing table growth in absence of NAT? > NAT doesn't reduce route table growth. NAT reduces address consumption. In fact, address conservation has done more to contribute to route table growth than almost any other factor. Currently, there are 9.5 prefixes+ for every active ASN in the IPv4 routing table. With IPv6 and liberal address allocations/assignments, we should be able to bring that number down to somewhere between 1 and 2. Given a 5:1 or so reduction in route-table size vs. IPv4, I think that route-table growth is not an issue in IPv6 for some time. The bottom line is that we need to find a better routing paradigm for the long-term regardless of the technology employed. Even the IPv4 routing table with NAT is becoming unwieldy and may get abruptly and dramatically worse after IPv4 free-space exhaustion. > * And most importantly, please explain what NAT breaks that stateful > inspection has not already "fixed-up"? > Please explain what you mean by the term "fixed-up" and I will be happy to answer the question. Preferably off-list since most people on the list are tired of this conversation. Owen From marquis at roble.com Thu Aug 5 16:18:08 2010 From: marquis at roble.com (Roger Marquis) Date: Thu, 5 Aug 2010 13:18:08 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: <06EA2620-C746-472C-BDED-F4A8B9C67348@delong.com> References: <20100805183123.C1A0F2B214B@mx5.roble.com> <06EA2620-C746-472C-BDED-F4A8B9C67348@delong.com> Message-ID: <20100805201808.5D2212B213A@mx5.roble.com> > Yes, a NAT box cannot function without stateful inspection. However, that > does not mean that a NAT box is a firewall. By the same logic a tcp firewall can function without udp or icmp. In the real world, however, you don't see such implementations. >> * If you can explain how multihoming will work without NAT and without >> internal renumbering then please do. If you think internal renumbering >> is feasible please explain how to maintain persistent connections across >> a renumbering? >> > Once again, I will endeavor to explain this to you: > > If you are multihomed, you can get global unicast addresses directly from > your RIR and advertise them to your upstreams, just like multihoming is > supposed to work in IPv4. No NAT required, no super special secret > technology. Please Owen, you know what I'm talking about, not theoretical multihoming but the real world stuff, where internal clients have a single IP and a single default route that doesn't change, without localhost accommodations (ie., points of failure) of any kind. >> * How to would you do transparent load-balancing and fail-over, ingress >> or egress, without NAT? >> > Again, I will endeavor to explain this to you: > > Border Ingress and Egress -- BGP is fairly good at this. At least as good > as any of the cobbled IPv4 NAT solutions I am aware of. This assumes all upstreams will always route foreign source addresses from your link, also not sustainable in most real-word implementations. > I really don't understand why you keep equating GUA with upstream lock-in. In ARIN-PPML GUA has been used to mean every end-node is mapped externally i.e., your network connectivity is dependent on upstreams knowing about, having routes for, maintaining routing for, and dampening routes for, your internal hosts at their discretion, not yours. Not just your gateways, but your internal hosts. Not just some of them either, but all of them. > Please explain to me how getting a prefix from ARIN locks you into any > particular upstream because I simply am not understanding this argument. Please explain the return for end-users of adding ARIN as a point of failure? Come on Owen, these are purely rhetorical arguments without technical merit, without a reasonable business case, and with negative ROI. >> * How would you deal with routing table growth in absence of NAT? >> > NAT doesn't reduce route table growth. NAT reduces address consumption. Ok, no routing table growth. Would love to see your math. Such is the case against NAT i.e., purely rhetorical. So rhetorical in fact that most engineers I know consider them proof of an agenda. To find that agenda follow the money to several animated discussions of the post-exhaustion address market in NANOG and other mailing list archives. I believe economists call this "pump and dump". Roger Marquis From michael.dillon at bt.com Fri Aug 6 06:02:43 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 6 Aug 2010 11:02:43 +0100 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100805183123.C1A0F2B214B@mx5.roble.com> References: <20100805183123.C1A0F2B214B@mx5.roble.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391915B96E@EMV01-UKBR.domain1.systemhost.net> > There is no such thing as a "NAT box". Firewalls == NAT == firewalls > whichever way you look at it. >From a consumer point of view, a firewall is some software that runs on the PC and a NAT box is the thing that connects to the DSL or cable provider. Stateful inspection firewalls are the simplest sort because they can function without rules and without configuration. That is what "box" means in this context. You and I may know that a NAT box has a stateful inspection firewall built in regardless of whether it is IPv4 Network Address Translation or IPv6 No-Address Translation, but to the consumer, these details don't matter. The consumer knows that a NAT box protects his network. > * How to would you do transparent load-balancing and fail-over, > ingress > or egress, without NAT? It's quite simple really. You focus on what you need and not on how it is implemented. Many commercial vendors supply IPv6 load balancing. You can also get opensource software like IPVS. They don't all work the same way. > * Also, since nobody has yet made a good business case for GUA I have no idea what GUA is. > * How would you deal with routing table growth in absence of NAT? One prefix per ISP should significantly reduce routing table size. --Michael Dillon From michael.dillon at bt.com Fri Aug 6 06:49:11 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 6 Aug 2010 11:49:11 +0100 Subject: [arin-ppml] Set aside round deux In-Reply-To: <20100805201808.5D2212B213A@mx5.roble.com> References: <20100805183123.C1A0F2B214B@mx5.roble.com> <06EA2620-C746-472C-BDED-F4A8B9C67348@delong.com> <20100805201808.5D2212B213A@mx5.roble.com> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B42391915B9BC@EMV01-UKBR.domain1.systemhost.net> > > If you are multihomed, you can get global unicast addresses directly > from > > your RIR and advertise them to your upstreams, just like multihoming > is > > supposed to work in IPv4. No NAT required, no super special secret > > technology. > > Please Owen, you know what I'm talking about, not theoretical > multihoming > but the real world stuff, where internal clients have a single IP and a > single default route that doesn't change, without localhost > accommodations (ie., points of failure) of any kind. This is just plain weird. You seem to be using "multihome" to mean something other than BGP multihoming. In any case, the point is that IPv6 routing works just like IPv4 routing. --Michael Dillon From owen at delong.com Fri Aug 6 15:37:53 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 6 Aug 2010 12:37:53 -0700 Subject: [arin-ppml] IPv6 Allocation Planning Message-ID: In thinking about address planning and deployment, I've been doing some various math. It seems to me that we have more than enough addresses to use the following methodology without any concern for exhaustion or shortage for a very long time. It also seems to me that the advantages in terms of human factors and network planning simplicity are large enough to be worthy of consideration. As such, I'd like to get community input on whether they would support policy that would allow ARIN to issue ISP allocations on this basis: 1. Take your number of end-sites attached to each pop. Round up to the nearest value of x such that x = 2^n where n % 4 = 0 (in other words, round up your POP size to a nibble boundary). 2. Take your expected number of POPs, say a Z-year plan (I seek community input on the desired value of Z, I'm thinking 5 years). Again, round up to a nibble boundary. Let's call this value y. 3. Multiply x*y to get the number of /48s (ISP) needed. Convert this to a number (n) of bits (2^n=x*y). 4. ARIN should approve you for a 48-n prefix or a /32, whichever is larger. Examples: 3000 end sites per POP 154 POPs 3000 rounds up to 4096 (12 bits). 154 rounds up to 256 (8 bits). Total need: 1,048,076 end sites (20 bits) 48-20 = 28 -- This provider should receive a /28. -- 53,000 users per POP 350 POPs 53000 -> 65536 (16 bits) 350 -> 4096 (12 bits) Total need: 268,435,456 /48s (28 bits) 48-28 = 20 -- This provider should receive a /20. -- 300 End sites per POP 10 POPs 300 -> 4096 (12 bits) 10 -> 16 (4 bits) 48 - 16 = 32 -- This provider should receive a /32. I think the above examples are a reasonably representative set of values for medium, large, and small providers. I realize that the resulting values result in a tremendous amount of extra space being issued as a result of the double rounding, but, I believe it is worth while for the likely gains in aggregation. To put it in perspective, if we took twice as many ISPs in each region as there are active ASNs in the entire IPv4 internet today, and gave them all /28s, we would barely use up the first /12 in each region. We would still have tremendous room to grow within the first 11 /12s out of 512 that are contained within 2000::/3. In my estimation, the average allocation under this scheme would likely work out very close to that, but, even if I'm off by a factor of 16, we'd still only use most of 176 /12s and we'd have 336 /12s untouched in 2000::/3 with the internet being more than double its current size. Please let me know what you think of this idea. If it receives some positive feedback, I'll start working on turning it into policy. Thanks, Owen From bill at herrin.us Fri Aug 6 17:22:10 2010 From: bill at herrin.us (William Herrin) Date: Fri, 6 Aug 2010 17:22:10 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: On Fri, Aug 6, 2010 at 3:37 PM, Owen DeLong wrote: > Please let me know what you think of this idea. If it receives > some positive feedback, I'll start working on turning it into policy. Hi Owen, I think that over-complicates what should be a simple process. My inclination is to give each ISP a /32 and when they -run out- give them a /28. They won't run out any time in the near future (if ever) and if need be the routing table can bear two routes each for all several thousand ISPs in ARIN territory. ARIN could even reserve the /28 containing the /32 for the next decade just to be sure. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Sat Aug 7 20:14:16 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 07 Aug 2010 17:14:16 -0700 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <4C59DA65.6050202@arin.net> References: <4C59DA65.6050202@arin.net> Message-ID: <4C5DF6D8.9060208@gmail.com> On Wed 8/4/2010 2:23 PM, ARIN wrote: > > Draft Policy 2010-13 > Permitted Uses of space reserved under NRPM 4.10 I think this proposal is moving in the right direction (and apparently toward consensus). A few questions and discussion points inline below... > Version/Date: 4 August 2010 > > Policy statement: > > Amend section 4.10 replacing "...a contiguous /10 IPv4 block..." with > "...that /8..." and replacing "...within that /10 block." with "within > this /8." > > Add the following to section 4.10 of the NRPM > > 6. Under this policy, applications must be for one of two types of > transitional uses, declared at time of application. > (a) An ISP/LIR may request a block not less than a /24 nor more than > a /18 The /18 maximum conflicts with the second paragraph of the existing 4.10 (which specifies a /24 maximum). You should probably update that paragraph as well. > to be used to provide single IPv4 /32s to their customers which > could justify a /28 or more of IPv4 under ARIN policies in effect at the > time ARIN received this reserved block from IANA. > 1. No customer may receive more than a single IPv4 /32 under this > provision. > 2. The customer must not have any other IPv4 allocations or > assignments from the provider at the time of this assignment. > 3. The customer must not have any direct assignments from ARIN at > the time of this assignment. > 4. The customer must not have more than a single IPv4 /32 from any > other provider at the time of this assignment. > 5. The customer must have IPv6 space with native IPv6 connectivity > to the ISP/LIR and must be making use of IPv6 within their network. > 6. The total of all allocations by ARIN under this provision shall > not be allowed to consume more than 3/4 of the /8 (the equivalent of a > /9 + a /10). > 7. No organization shall receive more than a total of a /16 or > equivalent under this section. > > or (b) An ISP/LIR or End user organization may request not less than a > /28 and not more than a /24 for purposes relevant to their ability > to deploy IPv6 as specified in section 4.12. > 1. No organization shall receive more than a total of a /20 or > equivalent under this section. > 2. Space issued under this policy is an assignment, not an > allocation. An LIR may not distribute this space to their customers. > > 7. For purposes of section 4.10.1, separate times shall be considered > for 4.10.6(a) vs. 4.10.6(b). An organization may make applications for > both types within 6 months. > > 8. Other than transfers under NRPM section 8, all space returned to ARIN > after IANA depletion shall either be returned to IANA or shall be added > to the reserved pool created by 4.10.1. > > Add the following to section 4 of the NRPM > > 4.11 Required utilization for subsequent allocation under section 4.10 > > No organization shall receive more than one allocation or assignment > under section 4.10 unless all prior space issued under 4.10 meets the > utilization requirements of this section: > > 1. The most recent 4.10 allocation/assignment must be at least 80% > utilized. > 2. All utilization must be permitted under section 4.12 > 3. All prior 4.10 allocation/assignments must be at least 90% utilized. Is there any reason to limit this requirement to just 4.10 allocations and assignments? If we struck 4.10 there, and require that "All prior allocation/assignments must be at least 90% utilized", would that be better? > 4. For purposes of this computation, space received under 4.10(a) shall > be considered separately from space received under 4.10(b) if an > organization has received resources of both types. > > 4.12 Permitted uses of allocations or assignments under section 4.10(b) > > No organization shall use space received under section 4.10 for any > purpose other than as specified in this section > > 1. To provide the required public IPv4 address(es) for transitional > technologies operated by the recipient organization. > a. Large scale or "Carrier Grade" NAT > b. NAT-PT > c. DS-LITE/B4/AFTeR > d. DNS64 or other transitional DNS enablers The existing 4.10 language mentions "key dual stack DNS servers", but you don't mention that here. Can you elaborate on what you think should be allowed there? Thanks, Scott > e. For other technologies of similar purpose and scope. > > 2. For other transitional technologies not envisioned at the time of > this proposal, but, in no case for general IPv4 addressing provided to > customers. > > 4.13 Quarterly Utilization Monitoring > > Allocations and assignments under section 4.10 shall be subject to > quarterly verification of utilization. > > 1. An organization which is not meeting their utilization targets may > have their allocation or assignment reduced accordingly with the > reclaimed portions going back to ARIN for distribution to other > organizations. Space reclaimed in this manner shall be exempt from any > requirement to return space to the IANA. > 2. An organization which is using space received under 4.10 in a manner > contrary to 4.10 et seq. may have their allocation or assignment reduced > or revoked with reclaimed portions going back to ARIN for distribution > to other organizations. Space reclaimed in this manner shall be exempt > from any requirement to return space to the IANA. > > Rationale: > > The current terminology in section 4.10 is vague and could allow a > variety of interpretations which could lead to allocations or > assignments being made to ISPs intending to misuse the space for general > deployment by using IPv6 overlay technologies as a "IPv6 deployments" > requiring IPv4 space for transition. For example, the current policy > could be interpreted to enable an ISP to require IPv4 addresses for all > IPv6 customers to roll IPv6 out as 6rd to customers who would be > otherwise unable to get IPv4 space. This is clearly outside of the > original intent of the proposal which created 4.10 (6rd was not yet > envisioned at the time that was written). This proposal seeks to clarify > that intent and tighten up the requirements for organizations seeking to > get space from this limited final resource so that it truly is available > to facilitate transitional technologies. > > Timetable for implementation: immediate > > For reference, here is the current text of 4.10 > > 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment > > When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous > /10 IPv4 block will be set aside and dedicated to facilitate IPv6 > deployment. Allocations and assignments from this block must be > justified by immediate IPv6 deployment requirements. Examples of such > needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT > or NAT464 translators. ARIN staff will use their discretion when > evaluating justifications. > > This block will be subject to a minimum size allocation of /28 and a > maximum size allocation of /24. ARIN should use sparse allocation when > possible within that /10 block. > > In order to receive an allocation or assignment under this policy: > 1. the applicant may not have received resources under this policy in > the preceding six months; > 2. previous allocations/assignments under this policy must continue to > meet the justification requirements of this policy; > 3. previous allocations/assignments under this policy must meet the > utilization requirements of end user assignments; > 4. the applicant must demonstrate that no other allocations or > assignments will meet this need; > 5. on subsequent allocation under this policy, ARIN staff may require > applicants to renumber out of previously allocated / assigned space > under this policy in order to minimize non-contiguous allocations. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Sat Aug 7 23:07:59 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 7 Aug 2010 20:07:59 -0700 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <4C5DF6D8.9060208@gmail.com> References: <4C59DA65.6050202@arin.net> <4C5DF6D8.9060208@gmail.com> Message-ID: On Aug 7, 2010, at 5:14 PM, Scott Leibrand wrote: > On Wed 8/4/2010 2:23 PM, ARIN wrote: >> >> Draft Policy 2010-13 >> Permitted Uses of space reserved under NRPM 4.10 > > I think this proposal is moving in the right direction (and apparently toward consensus). A few questions and discussion points inline below... > >> Version/Date: 4 August 2010 >> >> Policy statement: >> >> Amend section 4.10 replacing "...a contiguous /10 IPv4 block..." with >> "...that /8..." and replacing "...within that /10 block." with "within >> this /8." >> >> Add the following to section 4.10 of the NRPM >> >> 6. Under this policy, applications must be for one of two types of >> transitional uses, declared at time of application. >> (a) An ISP/LIR may request a block not less than a /24 nor more than >> a /18 > > The /18 maximum conflicts with the second paragraph of the existing 4.10 (which specifies a /24 maximum). You should probably update that paragraph as well. > Noted... Will incorporate that in the next rev. >> to be used to provide single IPv4 /32s to their customers which >> could justify a /28 or more of IPv4 under ARIN policies in effect at the >> time ARIN received this reserved block from IANA. >> 1. No customer may receive more than a single IPv4 /32 under this >> provision. >> 2. The customer must not have any other IPv4 allocations or >> assignments from the provider at the time of this assignment. >> 3. The customer must not have any direct assignments from ARIN at >> the time of this assignment. >> 4. The customer must not have more than a single IPv4 /32 from any >> other provider at the time of this assignment. >> 5. The customer must have IPv6 space with native IPv6 connectivity >> to the ISP/LIR and must be making use of IPv6 within their network. >> 6. The total of all allocations by ARIN under this provision shall >> not be allowed to consume more than 3/4 of the /8 (the equivalent of a >> /9 + a /10). >> 7. No organization shall receive more than a total of a /16 or >> equivalent under this section. >> >> or (b) An ISP/LIR or End user organization may request not less than a >> /28 and not more than a /24 for purposes relevant to their ability >> to deploy IPv6 as specified in section 4.12. >> 1. No organization shall receive more than a total of a /20 or >> equivalent under this section. >> 2. Space issued under this policy is an assignment, not an >> allocation. An LIR may not distribute this space to their customers. >> >> 7. For purposes of section 4.10.1, separate times shall be considered >> for 4.10.6(a) vs. 4.10.6(b). An organization may make applications for >> both types within 6 months. >> >> 8. Other than transfers under NRPM section 8, all space returned to ARIN >> after IANA depletion shall either be returned to IANA or shall be added >> to the reserved pool created by 4.10.1. >> >> Add the following to section 4 of the NRPM >> >> 4.11 Required utilization for subsequent allocation under section 4.10 >> >> No organization shall receive more than one allocation or assignment >> under section 4.10 unless all prior space issued under 4.10 meets the >> utilization requirements of this section: >> >> 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. >> 2. All utilization must be permitted under section 4.12 >> 3. All prior 4.10 allocation/assignments must be at least 90% utilized. > > Is there any reason to limit this requirement to just 4.10 allocations and assignments? If we struck 4.10 there, and require that "All prior allocation/assignments must be at least 90% utilized", would that be better? > I think it is infeasible to put a 90% requirement on pre-4.10 allocations and assignments unless we changed some of the mechanisms for counting utilization. I think this could place an undue burden on some providers as it would represent a radical ex-post-facto shift in the way they've allocated addresses to their customers prior to runout. I'm not opposed to this change personally, but, I would expect some opposition from the community and wouldn't want such opposition to reduce the consensus on the rest of this proposal. I encourage others to provide feedback (positive or negative on this idea). >> 4. For purposes of this computation, space received under 4.10(a) shall >> be considered separately from space received under 4.10(b) if an >> organization has received resources of both types. >> >> 4.12 Permitted uses of allocations or assignments under section 4.10(b) >> >> No organization shall use space received under section 4.10 for any >> purpose other than as specified in this section >> >> 1. To provide the required public IPv4 address(es) for transitional >> technologies operated by the recipient organization. >> a. Large scale or "Carrier Grade" NAT >> b. NAT-PT >> c. DS-LITE/B4/AFTeR >> d. DNS64 or other transitional DNS enablers > > The existing 4.10 language mentions "key dual stack DNS servers", but you don't mention that here. Can you elaborate on what you think should be allowed there? > I would consider those to be covered under "other transitional DNS enablers", but, I can easily add that to the list if you feel it's helpful. I've basically tried to write this section such that it gives staff the clearest possible statement of the intent of the policy and will of the community while not preventing innovation in this area or creating unnecessary limits on legitimate uses of the space for actual transitional technologies. More community guidance here would be very useful. Did you intentionally cut e off below your signature? (Note it is an important part of the intent of this section). > Thanks, > Scott > >> e. For other technologies of similar purpose and scope. >> >> 2. For other transitional technologies not envisioned at the time of >> this proposal, but, in no case for general IPv4 addressing provided to >> customers. >> >> 4.13 Quarterly Utilization Monitoring >> >> Allocations and assignments under section 4.10 shall be subject to >> quarterly verification of utilization. >> >> 1. An organization which is not meeting their utilization targets may >> have their allocation or assignment reduced accordingly with the >> reclaimed portions going back to ARIN for distribution to other >> organizations. Space reclaimed in this manner shall be exempt from any >> requirement to return space to the IANA. >> 2. An organization which is using space received under 4.10 in a manner >> contrary to 4.10 et seq. may have their allocation or assignment reduced >> or revoked with reclaimed portions going back to ARIN for distribution >> to other organizations. Space reclaimed in this manner shall be exempt >> from any requirement to return space to the IANA. Owen From bill at herrin.us Sat Aug 7 23:44:37 2010 From: bill at herrin.us (William Herrin) Date: Sat, 7 Aug 2010 23:44:37 -0400 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: References: <4C59DA65.6050202@arin.net> <4C5DF6D8.9060208@gmail.com> Message-ID: On Sat, Aug 7, 2010 at 11:07 PM, Owen DeLong wrote: > On Aug 7, 2010, at 5:14 PM, Scott Leibrand wrote > > On Wed 8/4/2010 2:23 PM, ARIN wrote: > >> 3. All prior 4.10 allocation/assignments must be at least 90% utilized. > > > > Is there any reason to limit this requirement to just 4.10 allocations > > and assignments? > > I think it is infeasible to put a 90% requirement on pre-4.10 allocations and > assignments unless we changed some of the mechanisms for counting > utilization. I think this could place an undue burden on some providers as > it would represent a radical ex-post-facto shift in the way they've allocated > addresses to their customers prior to runout. Hi Owen, I think Scott's point is: if they haven't consumed 90% of their existing allocations, do they genuinely -need- addresses from the 4.10 pool? If they do, I haven't been convinced of why. Ex post facto has to do with retroactive effect. There's no change here to folks have to do to retain, transfer, etc. any addresses outside the pool reserved for 4.10. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Sun Aug 8 00:53:34 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 07 Aug 2010 21:53:34 -0700 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: References: <4C59DA65.6050202@arin.net> <4C5DF6D8.9060208@gmail.com> Message-ID: <4C5E384E.9080007@gmail.com> On Sat 8/7/2010 8:07 PM, Owen DeLong wrote: > On Aug 7, 2010, at 5:14 PM, Scott Leibrand wrote: > > >> On Wed 8/4/2010 2:23 PM, ARIN wrote: >> >> >>> Add the following to section 4 of the NRPM >>> >>> 4.11 Required utilization for subsequent allocation under section 4.10 >>> >>> No organization shall receive more than one allocation or assignment >>> under section 4.10 unless all prior space issued under 4.10 meets the >>> utilization requirements of this section: >>> >>> 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. >>> 2. All utilization must be permitted under section 4.12 >>> 3. All prior 4.10 allocation/assignments must be at least 90% utilized. >>> >> Is there any reason to limit this requirement to just 4.10 allocations and assignments? If we struck 4.10 there, and require that "All prior allocation/assignments must be at least 90% utilized", would that be better? >> > I think it is infeasible to put a 90% requirement on pre-4.10 allocations and > assignments unless we changed some of the mechanisms for counting > utilization. I think this could place an undue burden on some providers as > it would represent a radical ex-post-facto shift in the way they've allocated > addresses to their customers prior to runout. > I agree with what Bill said: On Sat 8/7/2010 8:44 PM, William Herrin wrote: > I think Scott's point is: if they haven't consumed 90% of their > existing allocations, do they genuinely -need- addresses from the 4.10 > pool? If they do, I haven't been convinced of why. > > Ex post facto has to do with retroactive effect. There's no change > here to folks have to do to retain, transfer, etc. any addresses > outside the pool reserved for 4.10. > On Sat 8/7/2010 8:07 PM, Owen DeLong wrote: > I'm not opposed to this change personally, but, I would expect some > opposition from the community and wouldn't want such opposition to reduce > the consensus on the rest of this proposal. > > I encourage others to provide feedback (positive or negative on this idea). > Agreed. I'd also like to hear from anyone who thinks that 90% of all previous allocations is too high a bar for this kind of space. As I see it, anyone who has more than 10% of their previous allocations sitting unused and hasn't figured out a way to use it probably isn't in the situation of needing more space for transition purposes yet. >>> 4. For purposes of this computation, space received under 4.10(a) shall >>> be considered separately from space received under 4.10(b) if an >>> organization has received resources of both types. >>> >>> 4.12 Permitted uses of allocations or assignments under section 4.10(b) >>> >>> No organization shall use space received under section 4.10 for any >>> purpose other than as specified in this section >>> >>> 1. To provide the required public IPv4 address(es) for transitional >>> technologies operated by the recipient organization. >>> a. Large scale or "Carrier Grade" NAT >>> b. NAT-PT >>> c. DS-LITE/B4/AFTeR >>> d. DNS64 or other transitional DNS enablers >>> >> The existing 4.10 language mentions "key dual stack DNS servers", but you don't mention that here. Can you elaborate on what you think should be allowed there? >> > I would consider those to be covered under "other transitional DNS enablers", but, I can easily add that to the list if you feel it's helpful. > I've basically tried to write this section such that it gives staff the clearest possible statement of the intent of the policy and will of the > community while not preventing innovation in this area or creating unnecessary limits on legitimate uses of the space for actual > transitional technologies. > I think it's probably covered there, but I think including it in d would help your goal of providing the clearest possible statement of intent. > More community guidance here would be very useful. > > Did you intentionally cut e off below your signature? (Note it is an important part of the intent of this section). > I was just focusing my comments on d. I see e. and 2. as a good catch-alls, but would rather enumerate known-good technologies and strategies where appropriate, rather than rely too much on the catch-all. >>> e. For other technologies of similar purpose and scope. >>> >>> 2. For other transitional technologies not envisioned at the time of >>> this proposal, but, in no case for general IPv4 addressing provided to >>> customers. -Scott From michael.dillon at bt.com Mon Aug 9 03:40:35 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 9 Aug 2010 08:40:35 +0100 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> > 3. Multiply x*y to get the number of /48s (ISP) needed. Convert this > to a number (n) > of bits (2^n=x*y). This is unneccesarily complex. First of all, there is no need to do this at all. An ISP can just appply for a /32, and then reapply when they run out. For some ISPs this ma be the best way to go because it does not require detailed forward planning even if it ends up being inconvenient for them when they have to reapply. But any really large ISP would likely want to use whatever they already have in their database, i.e. count customers or customer sites, or customer access circuits, and then use that as justification for an appropriately large block bigger than /32. It should not really matter to us how accurate such estimates are as long as they are not outrageously pie-in-the-sky. --Michael Dillon From owen at delong.com Mon Aug 9 05:34:29 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Aug 2010 02:34:29 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> Message-ID: On Aug 9, 2010, at 12:40 AM, wrote: >> 3. Multiply x*y to get the number of /48s (ISP) needed. Convert this >> to a number (n) >> of bits (2^n=x*y). > > This is unneccesarily complex. > First of all, there is no need to do this at all. An ISP can just appply > for a /32, and then reapply when they run out. For some ISPs this ma > be the best way to go because it does not require detailed forward planning > even if it ends up being inconvenient for them when they have to reapply. > But any really large ISP would likely want to use whatever they already > have in their database, i.e. count customers or customer sites, or > customer access circuits, and then use that as justification for an > appropriately large block bigger than /32. > If I added the option to get a default /32 with no planning, would you consider it worth while? This is an attempt to head off prefix-growth by allowing ISPs to do planning if they wish. The proposal, by the way, is to do essentially what you describe, except to do it at hierarchical levels that allow the generation of sufficient space to internally aggregate the subordinate blocks... The number of customers attached to your largest POP (rounded up to a nibble boundary) times the anticipated number of POPs (also rounded up to a nibble boundary). Owen From michael.dillon at bt.com Mon Aug 9 08:20:32 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 9 Aug 2010 13:20:32 +0100 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A769@EMV01-UKBR.domain1.systemhost.net> > The number of customers attached to your largest POP (rounded up to > a nibble boundary) times the anticipated number of POPs (also rounded > up to a nibble boundary). I really don't care how ISPs project their network growth. If they have some kind of plan which they can show to a hostmaster under NDA, then that is good enough for me. Policy does not need to go there. I don't see the point of having policies get to this level of detail. --Michael Dillon From marty at akamai.com Mon Aug 9 11:27:00 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 9 Aug 2010 11:27:00 -0400 Subject: [arin-ppml] Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10 In-Reply-To: <4C5E384E.9080007@gmail.com> Message-ID: On 8/8/10 12:53 AM, "Scott Leibrand" wrote: > On Sat 8/7/2010 8:07 PM, Owen DeLong wrote: >> On Aug 7, 2010, at 5:14 PM, Scott Leibrand wrote: >> [ clip ] > > On Sat 8/7/2010 8:07 PM, Owen DeLong wrote: >> I'm not opposed to this change personally, but, I would expect some >> opposition from the community and wouldn't want such opposition to reduce >> the consensus on the rest of this proposal. >> >> I encourage others to provide feedback (positive or negative on this idea). >> > > Agreed. I'd also like to hear from anyone who thinks that 90% of all > previous allocations is too high a bar for this kind of space. As I see > it, anyone who has more than 10% of their previous allocations sitting > unused and hasn't figured out a way to use it probably isn't in the > situation of needing more space for transition purposes yet. It depends on the minimum allocation size being set correctly. If the minimum allocation unit is high enough, it should push some demand onto the providers and I would expect that the result would be an increase in utilization trying to service customers. Caveat: Transition is unlikely to be painless. From marquis at roble.com Mon Aug 9 14:09:54 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 9 Aug 2010 11:09:54 -0700 (PDT) Subject: [arin-ppml] Set aside round deux In-Reply-To: References: Message-ID: <20100809180954.915492B2119@mx5.roble.com> michael.dillon at bt.com wrote: >> but the real world stuff, where internal clients have a single IP and a >> single default route that doesn't change, without localhost >> accommodations (ie., points of failure) of any kind. > > This is just plain weird. You seem to be using "multihome" to mean something > other than BGP multihoming. An understandable confusion perhaps for network engineers with exclusively backbone experience. For the rest of us, with outside networks smaller than /23, multihoming is done via NAT rather than BGP. Small businesses do not want to add an exterior routing protocols to every internal device. They simply want to order a second hicap or DSL line, often with a dynamic external IP, and let NAT take care of the rest. We're not talking about Internet servers here, just residences and small businesses, the vast majority of end-nodes, connecting to the Internet. This population doesn't need to disrup persistent internal connections for unrelated external events and it won't deprecate simple and reliable NAT(/HSRP) solutions to accomodate IPv6's ill thought-out "GUA everywhere" proponents. Roger Marquis From marquis at roble.com Mon Aug 9 14:16:41 2010 From: marquis at roble.com (Roger Marquis) Date: Mon, 9 Aug 2010 11:16:41 -0700 (PDT) Subject: [arin-ppml] Defcon speaker calls IPv6 a 'security nightmare' In-Reply-To: References: Message-ID: <20100809181642.06A6A2B2119@mx5.roble.com> > Getting back to the technical reasons for NAT, or at least trying to, are > there no takers for these questions? More unanswered questions for IPv6 nat-o-phobes: "It is extremely important for hackers to get in here fast because IPv6 is a security nightmare," Sam Bowne, an instructor in the Computer Networking and Information Technology Department at the City College of San Francisco, said on day one of the Defcon hacker conference in Las Vegas. "We're coming into a time of crisis and no one is ready." Roger Marquis From trejrco at gmail.com Mon Aug 9 14:25:24 2010 From: trejrco at gmail.com (TJ) Date: Mon, 9 Aug 2010 14:25:24 -0400 Subject: [arin-ppml] Defcon speaker calls IPv6 a 'security nightmare' In-Reply-To: <20100809181642.06A6A2B2119@mx5.roble.com> References: <20100809181642.06A6A2B2119@mx5.roble.com> Message-ID: > > More unanswered questions for IPv6 nat-o-phobes: > > > > "It is extremely important for hackers to get in here fast because IPv6 > is a security nightmare," Sam Bowne, an instructor in the Computer > Networking and Information Technology Department at the City College of > San Francisco, said on day one of the Defcon hacker conference in Las > Vegas. "We're coming into a time of crisis and no one is ready." > Obviously there is a bit of extremism / alarmism there ... the truth is that some are ready, but many more aren't (yet?). IMHO, we should focus on getting as many of the latter moved forward as possible - rather than trying to scare everyone away from the solution. (Especially when quoted out of context; sound bites (and the written equivalent) can be rather misleading). /TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Aug 9 14:21:34 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 09 Aug 2010 11:21:34 -0700 Subject: [arin-ppml] Defcon speaker calls IPv6 a 'security nightmare' In-Reply-To: <20100809181642.06A6A2B2119@mx5.roble.com> References: <20100809181642.06A6A2B2119@mx5.roble.com> Message-ID: <4C60472E.9090608@gmail.com> Roger, Could you try to focus on the address policy implications (if any) of stuff like this? As far as I can tell, most of your arguments would support standardization of some sort of IPv6 NAT, but that's out of scope for ARIN, and IMO would be better discussed on the appropriate IETF list. I'm sure there are some policy implications of all this, but I'm having a hard time seeing them amid all the debate. Thanks, Scott On Mon 8/9/2010 11:16 AM, Roger Marquis wrote: >> Getting back to the technical reasons for NAT, or at least trying to, >> are >> there no takers for these questions? > > More unanswered questions for IPv6 nat-o-phobes: > > > > "It is extremely important for hackers to get in here fast because IPv6 > is a security nightmare," Sam Bowne, an instructor in the Computer > Networking and Information Technology Department at the City College of > San Francisco, said on day one of the Defcon hacker conference in Las > Vegas. "We're coming into a time of crisis and no one is ready." > > Roger Marquis > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Mon Aug 9 15:07:01 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Aug 2010 12:07:01 -0700 Subject: [arin-ppml] Defcon speaker calls IPv6 a 'security nightmare' In-Reply-To: <20100809181642.06A6A2B2119@mx5.roble.com> References: <20100809181642.06A6A2B2119@mx5.roble.com> Message-ID: <4C6051D5.4000702@ipinc.net> as if NAT today presents any significant problems for the crackers of the world to attack systems. Obviously an academic with no real world experience. He probably doesn't even know how to create an Avira ISO image and scan a machine with it. The local computer stores around here make a living off of people who believe NAT will protect them from getting hacked. And what about that security crack discussed at Black Hat that affects millions of CPE NAT routers? The don't even need to bother attacking the systems behind the NAT now, they just attack the NAT router and use it's CPU to do their nasty stuff Ted On 8/9/2010 11:16 AM, Roger Marquis wrote: >> Getting back to the technical reasons for NAT, or at least trying to, are >> there no takers for these questions? > > More unanswered questions for IPv6 nat-o-phobes: > > > > "It is extremely important for hackers to get in here fast because IPv6 > is a security nightmare," Sam Bowne, an instructor in the Computer > Networking and Information Technology Department at the City College of > San Francisco, said on day one of the Defcon hacker conference in Las > Vegas. "We're coming into a time of crisis and no one is ready." > > Roger Marquis > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From leo.vegoda at icann.org Mon Aug 9 16:21:26 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 9 Aug 2010 13:21:26 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> Message-ID: <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> On 9 Aug 2010, at 2:34, Owen DeLong wrote: [...] > This is an attempt to head off prefix-growth by allowing ISPs to do planning > if they wish. Why are ISPs not able to plan ahead at the moment? Regards, Leo From bill at herrin.us Mon Aug 9 17:38:25 2010 From: bill at herrin.us (William Herrin) Date: Mon, 9 Aug 2010 17:38:25 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: On Mon, Aug 9, 2010 at 4:21 PM, Leo Vegoda wrote: > On 9 Aug 2010, at 2:34, Owen DeLong wrote: >> This is an attempt to head off prefix-growth by allowing ISPs to do planning >> if they wish. > > Why are ISPs not able to plan ahead at the moment? > > Regards, > Leo Leo, You're kidding, right? The current v6 dogma is that we're going to provide ISPs with exactly one allocation to the maximum extent possible, so we want to get that one right and/or include reserve slack surrounding the allocation so that the netmask expands. That's why we haven't organized things as a slow start. One problem, of course, is that ISPs are used to planning address consumption on 6 and 12 month scales, not decades. They have no practical experience to guide them with longer range planning. Making matters worse, v6 allocation and v4 allocation have a fundamentally different basis. V4 allocation is host-centric: you assign a /32 to a host. V6 allocation is LAN-centric: you assign /64's to a LAN. ISPs have experience counting hosts. Counting lans is a little different; it confuses the numbers. More abstractly speaking, the history of long-range planning in general is littered with more failure than success. And the successes tend to focus more on positioning the entity to right-size rather than pre-determining what the right size is. And lest we forget: IPv6 is not currently a moneymaker nor anticipated to soon be a moneymaker, so the funding to support any sort of long range planning simply isn't there. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From leo.vegoda at icann.org Mon Aug 9 17:49:31 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 9 Aug 2010 14:49:31 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: <0613FDEB-E5C4-4C7F-8EAD-ADE98E150B17@icann.org> On 9 Aug 2010, at 2:38, William Herrin wrote: > On Mon, Aug 9, 2010 at 4:21 PM, Leo Vegoda wrote: >> On 9 Aug 2010, at 2:34, Owen DeLong wrote: >>> This is an attempt to head off prefix-growth by allowing ISPs to do planning >>> if they wish. >> >> Why are ISPs not able to plan ahead at the moment? [...] > You're kidding, right? > > The current v6 dogma is that we're going to provide ISPs with exactly > one allocation to the maximum extent possible, so we want to get that > one right and/or include reserve slack surrounding the allocation so > that the netmask expands. That's why we haven't organized things as a > slow start. > > One problem, of course, is that ISPs are used to planning address > consumption on 6 and 12 month scales, not decades. They have no > practical experience to guide them with longer range planning. [...] > And lest we forget: IPv6 is not currently a moneymaker nor anticipated > to soon be a moneymaker, so the funding to support any sort of long > range planning simply isn't there. Maybe I wasn't sufficiently clear. My question was intended to refer to the current allocation policy. If I understand your response, you are suggesting that the the issue is not that the policy causes problems for people who want to plan ahead but that ISPs are not sufficiently knowledgable and experienced to do so. I am not sure how changing the way we do a calculation is going to solve this problem. Regards, Leo From bill at herrin.us Mon Aug 9 18:22:14 2010 From: bill at herrin.us (William Herrin) Date: Mon, 9 Aug 2010 18:22:14 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <0613FDEB-E5C4-4C7F-8EAD-ADE98E150B17@icann.org> References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> <0613FDEB-E5C4-4C7F-8EAD-ADE98E150B17@icann.org> Message-ID: On Mon, Aug 9, 2010 at 5:49 PM, Leo Vegoda wrote: > On 9 Aug 2010, at 2:38, William Herrin wrote: >> And lest we forget: IPv6 is not currently a moneymaker nor anticipated >> to soon be a moneymaker, so the funding to support any sort of long >> range planning simply isn't there. > > Maybe I wasn't sufficiently clear. My question was intended > to refer to the current allocation policy. > > If I understand your response, you are suggesting that the the > issue is not that the policy causes problems for people who > want to plan ahead but that ISPs are not sufficiently > knowledgable and experienced to do so. Hi Leo, I think that's a fair way to put it. I think I would add a hint of unreasonableness for expecting ISPs to be sufficiently experienced and a healthy dose of skepticism aimed at anyone who claims to have enough guiding knowledge. > I am not sure > how changing the way we do a calculation is going to > solve this problem. I don't think it will. I think the shape of a solution looks more like a slow-start. Give ISPs enough to get going, and when they run out use the knowledge gained to figure out how much more to provide. With particular care given to routing table impact: * the degree to which the addressing policy enables individual ISPs to minimize their own disaggregation, * the degree to which it facilitates the policing of disaggregates by the rest of the ISPs and * are there ways we can minimize routing problems that could arise from undesirable interactions between the initial policies and whatever policies come once we know what we're doing? We may not have much experience with IPv6 consumption but we have decades of skill with how addressing policy both impacts and fails to impact disaggregation. That's the nutshell for my thinking on the subject. So far I've been outvoted. ;-) Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Aug 9 19:14:03 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Aug 2010 16:14:03 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: On Aug 9, 2010, at 2:38 PM, William Herrin wrote: > On Mon, Aug 9, 2010 at 4:21 PM, Leo Vegoda wrote: >> On 9 Aug 2010, at 2:34, Owen DeLong wrote: >>> This is an attempt to head off prefix-growth by allowing ISPs to do planning >>> if they wish. >> >> Why are ISPs not able to plan ahead at the moment? >> >> Regards, >> Leo > > Leo, > > You're kidding, right? > > The current v6 dogma is that we're going to provide ISPs with exactly > one allocation to the maximum extent possible, so we want to get that > one right and/or include reserve slack surrounding the allocation so > that the netmask expands. That's why we haven't organized things as a > slow start. > Correct. I find it very interesting that out of one side of your mouth, you talk about concern for routing table growth, yet, out of the other side, you say we should return IPv6 back to slow-start so as to maximize the need to make additional allocations to ISPs as they grow. > One problem, of course, is that ISPs are used to planning address > consumption on 6 and 12 month scales, not decades. They have no > practical experience to guide them with longer range planning. > While this is true, it's a relatively minor problem of education. Further, decades isn't a fair characterization of my proposal which stated a 5 year time horizon as a straw-man and asked for input on what people felt would be the best value. So far, the only other suggestion I've received was 3 years. > Making matters worse, v6 allocation and v4 allocation have a > fundamentally different basis. V4 allocation is host-centric: you > assign a /32 to a host. V6 allocation is LAN-centric: you assign /64's > to a LAN. ISPs have experience counting hosts. Counting lans is a > little different; it confuses the numbers. > Again, not a particularly hard problem to solve with a small amount of education. If anything, counting "network segments" (It isn't really counting LANs, this is another mischaracterization) is, if anything, a whole lot easier than counting hosts. You don't need to worry about how many things are in a given segment, just how many segments you need. It's not like you didn't have to count those before, you just had to take the additional step of sizing them to barely fit the number of hosts. > More abstractly speaking, the history of long-range planning in > general is littered with more failure than success. And the successes > tend to focus more on positioning the entity to right-size rather than > pre-determining what the right size is. > Largely because attempts to right-size were pinned against a need to conserve addresses. As things stand, moving that perception forward into IPv6 is, in my opinion, the greatest danger to good aggregation. > And lest we forget: IPv6 is not currently a moneymaker nor anticipated > to soon be a moneymaker, so the funding to support any sort of long > range planning simply isn't there. > Again, this is an area where we disagree. I know several organizations with large networks that are most definitely engaged in long-range planning for IPv6. If we make that long-range planning simpler (such as what I have attempted to propose): 1. Determine number of end sites served by largest POP 2. Round that number up to a nibble boundary. 3. Determine the number of POPs. 4. Again, round that number up to a nibble boundary. 6. Get a prefix large enough to contain the required number of POPs each of which has enough /48s for the number of end-sites determined in step 2. Perhaps this simplicity got lost in the math detail that I included in the original proposal. Here's an example exercise I hope will help: You have 200 end sites served by your largest pop. Rounding up to a nibble boundary, we get to 8-bits (256 end sites per POP). You have 100 POPs now and expect that to triple over the next 5 years. 500 rounded up to a nibble boundary is 4096 (12 bits). We need a total of 20 bits of prefix to number all of our POPs, giving 256 segments to each POP. Our own infrastructure fits well within the round-up at both levels. To provide /48s to each end-site, we will need give a /40 to each POP. To have 12 bits worth of /40s, we will need to get a /28 from the RIR. Here's a convenient table of nibble boundaries to make rounding up easier: Min Max Bits Units represented 1 12 4 16 13 240 8 256 241 3840 12 4,096 3,841 61,440 16 65,536 61,441 983,040 20 1,048,576 983,041 15,728,640 24 16,777,216 I doubt that any real deployment is likely to get beyond the 16 bit row on this table. (Remember, you do two look ups on the table and the add the number of bits required together, no real multiplication required). As you can see from the table, this really doesn't have to be hard and will create a relatively small number of prefix sizes while still allowing allocations to be liberal without being needlessly excessive. So, for example, a pretty large provider with, say, 10,000 end sites served by their largest POPs and, say, 1,000 POPs expects to have 10% growth per year for the next 5 years. 10,000 end sites/POP grows to 16,105. 1,000 POPs grows to 1,611 POPs. Using the table above, we find that we should plan on requesting 16 bits for each POP and 12 bits to represent the number of POPs. That's 28 bits needed. 48-28 is 20. We should request a /20. Quite simple, really. No actual difficult math once the table is published. If each RIR gives two /20s to EVERY active autonomous system currently on the internet, we would still only consume 161 /12s from 2000::/3. As such, I would argue this is still a relatively conservative consumption of the IP address space. To prevent this from impacting the routing system, yes, providers should be discouraged from disaggregating this space. I believe that the community is, generally, quite capable of doing this through education. It hasn't been possible in IPv4 because it wasn't possible to have this kind of allocation policy to reduce the number of opportunities to legitimately advertise disparate prefixes. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Aug 9 19:52:01 2010 From: bill at herrin.us (William Herrin) Date: Mon, 9 Aug 2010 19:52:01 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: On Mon, Aug 9, 2010 at 7:14 PM, Owen DeLong wrote: > On Aug 9, 2010, at 2:38 PM, William Herrin wrote: >> The current v6 dogma is that we're going to provide ISPs with exactly >> one allocation to the maximum extent possible, so we want to get that >> one right and/or include reserve slack surrounding the allocation so >> that the netmask expands. That's why we haven't organized things as a >> slow start. > > Correct. I find it very interesting that out of one side of your mouth, you > talk > about concern for routing table growth, yet, out of the other side, you say > we should return IPv6 back to slow-start so as to maximize the need to > make additional allocations to ISPs as they grow. Owen, I'm going to let that one slide. Consider it repayment for the last time I accused you of malfeasance. >> One problem, of course, is that ISPs are used to planning address >> consumption on 6 and 12 month scales, not decades. They have no >> practical experience to guide them with longer range planning. > > While this is true, it's a relatively minor problem of education. Let me put it to you this way: Looking forward ten years, at the IPv6 experience, knowledge and understanding you will have then, what percentage of it do you already have today? And for IPv4? I'd bet many of us are past the 80% mark for IPv4. There are refinements to learn and probably a few surprises, but we're already highly knowledgeable. If you claimed more than a single-digit percentage for IPv6 then you either overestimate your current abilities or underestimate what you'll yet learn. The events that define the shape, understanding and use of IPv6 are still more in our future than in our past. Any policy we write now will reflect that inexperience. And will necessarily change as we gain greater skill. > To prevent this from impacting the routing system, yes, providers > should be discouraged from disaggregating this space. I believe > that the community is, generally, quite capable of doing this through > education. Because "education" has been particularly effective at suppressing disaggregation in IPv4? As things stand, our policies partially usurp ISPs' ability to create and enforce disaggregation policies amongst themselves. They've asked us repeatedly to seek policy which at a technological level empowers them to set routing policies independent of our address allocation practices. In many ways it isn't even about how many routes there are in the table, it's about giving the ISPs the power over routing policy instead of keeping some of it for ourselves. We can do much better than we're doing now and the sooner we start the less of a legacy of our error they'll have to carry in their TCAMs and TRIEs. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Aug 9 20:05:59 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Aug 2010 17:05:59 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: > >>> One problem, of course, is that ISPs are used to planning address >>> consumption on 6 and 12 month scales, not decades. They have no >>> practical experience to guide them with longer range planning. >> >> While this is true, it's a relatively minor problem of education. > > Let me put it to you this way: Looking forward ten years, at the IPv6 > experience, knowledge and understanding you will have then, what > percentage of it do you already have today? > In all honesty, probably somewhere between 40 and 60%. > And for IPv4? > Probably close to 100%. > I'd bet many of us are past the 80% mark for IPv4. There are > refinements to learn and probably a few surprises, but we're already > highly knowledgeable. > Agreed... > If you claimed more than a single-digit percentage for IPv6 then you > either overestimate your current abilities or underestimate what > you'll yet learn. The events that define the shape, understanding and > use of IPv6 are still more in our future than in our past. > I think you actually underestimate my capabilities and IPv6 experience. I suppose I can consider this part of your retort for pointing out the inconsistency in your own statements. > Any policy we write now will reflect that inexperience. And will > necessarily change as we gain greater skill. > Of course... Policies are not intended to be permanent or immutable. I don't see how this makes a case against teaching providers how to make better projections for longer-periods of usage of IP address space. > >> To prevent this from impacting the routing system, yes, providers >> should be discouraged from disaggregating this space. I believe >> that the community is, generally, quite capable of doing this through >> education. > > Because "education" has been particularly effective at suppressing > disaggregation in IPv4? > Of course it hasn't, and, I pointed out many of the reasons why. Mostly they have to do with scarcity and the mentality of scarcity. Scarcity makes aggregation impossible. Scarcity doesn't apply to IPv6 unless we artificially apply it through misguided mechanisms like slow start. > As things stand, our policies partially usurp ISPs' ability to create > and enforce disaggregation policies amongst themselves. They've asked > us repeatedly to seek policy which at a technological level empowers > them to set routing policies independent of our address allocation > practices. In many ways it isn't even about how many routes there are > in the table, it's about giving the ISPs the power over routing policy > instead of keeping some of it for ourselves. > ISPs can set any routing policy they choose as things stand today. The problem is that their customers would be unhappy and they can't coordinate the changes without crossing the line of the Sherman Anti-trust act (or their local equivalent), so, they're in a catch-22. That's not about how ARIN policy is impacting them, that's about the reality of the legal framework in which they operate. > We can do much better than we're doing now and the sooner we start the > less of a legacy of our error they'll have to carry in their TCAMs and > TRIEs. > Hence my desire to produce a policy that maximizes the potential for one ISP one prefix. You're making very good arguments in favor of my proposal while claiming to oppose it. I am very confused by this. Owen From joelja at bogus.com Mon Aug 9 20:23:46 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 09 Aug 2010 17:23:46 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: <4C609C12.9090601@bogus.com> On 8/9/10 4:52 PM, William Herrin wrote: > I'd bet many of us are past the 80% mark for IPv4. There are > refinements to learn and probably a few surprises, but we're already > highly knowledgeable. > > If you claimed more than a single-digit percentage for IPv6 then you > either overestimate your current abilities or underestimate what > you'll yet learn. The events that define the shape, understanding and > use of IPv6 are still more in our future than in our past. There are quite a few people on this list who've had deployed dual stack ipv6 networks for longer than it took us to put a man on the moon. Jaded rather than inexperienced is the first thing that some to mind. Yes, a few allocation plans have been torn up in the last decade. > Any policy we write now will reflect that inexperience. And will > necessarily change as we gain greater skill. > > >> To prevent this from impacting the routing system, yes, providers >> should be discouraged from disaggregating this space. I believe >> that the community is, generally, quite capable of doing this through >> education. > > Because "education" has been particularly effective at suppressing > disaggregation in IPv4? > > As things stand, our policies partially usurp ISPs' ability to create > and enforce disaggregation policies amongst themselves. They've asked > us repeatedly to seek policy which at a technological level empowers > them to set routing policies independent of our address allocation > practices. In many ways it isn't even about how many routes there are > in the table, it's about giving the ISPs the power over routing policy > instead of keeping some of it for ourselves. > > We can do much better than we're doing now and the sooner we start the > less of a legacy of our error they'll have to carry in their TCAMs and > TRIEs. > > Regards, > Bill Herrin > From bill at herrin.us Mon Aug 9 20:54:44 2010 From: bill at herrin.us (William Herrin) Date: Mon, 9 Aug 2010 20:54:44 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> Message-ID: On Mon, Aug 9, 2010 at 8:05 PM, Owen DeLong wrote: >> Let me put it to you this way: Looking forward ten years, at the IPv6 >> experience, knowledge and understanding you will have then, what >> percentage of it do you already have today? >> And for IPv4? > > Probably close to 100%. Owen, I sincerely hope you're mistaken. There's no subject about which there's no knowledge left to gain, only minds too rigid or incurious learn. I'd like to think you're better than that. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Aug 9 22:27:37 2010 From: bill at herrin.us (William Herrin) Date: Mon, 9 Aug 2010 22:27:37 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C609C12.9090601@bogus.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> <4C609C12.9090601@bogus.com> Message-ID: On Mon, Aug 9, 2010 at 8:23 PM, Joel Jaeggli wrote: > There are quite a few people on this list who've had deployed dual stack > ipv6 networks for longer than it took us to put a man on the moon. > > Jaded rather than inexperienced is the first thing that some to mind. Hi Joel, There were plenty of jaded IPv4 gurus in 1993. Those that survived and were still acknowledged gurus were far wiser and more knowledgeable in 2003. My point is: there's a lot about IPv6 policy we can't yet predict with a high confidence. We'll do the best we can and we'll change it when we learn better, but for now there's still a lot of guesswork involved. There are, however, two routing factors related to IPv6 addressing policy we can evaluate with a high degree of confidence. Because we can accurately predict them and because the routing table continues to have scarcity issues when the IPv6 address pool doesn't, I propose that these predictable routing factors should weigh distinctly more heavily than the factors whose prediction is less certain. * We can predict the difference in the minimum number of routes in the table as a result of a given policy change. * We can predict the difference in the maximum number of routes in the table as a result of a given policy change. Owen's proposal doesn't change the minimum. It's still 1 per ISP. Owen's proposal hands out more /32's without offering any mitigation to obstruct them from being disaggregately announced as /32's. Thus is significantly increases the maximum number of routes possible in the table. Arguably the policy could reduce the total number of blocks held by any given ISP by reducing their likelihood of coming back for more. So there's the outside possibility that an ISP who would otherwise have announced two separate blocks will instead hold and announce only one. But even if we could accurately quantify that (and we can't) the ISP would still hold at least as many disaggregable /32's. No change to the one predictable routing factor (minimum). Significantly worsens the other (maximum). Everything else being equal, that makes it a bad policy change. What, then, would a good policy change look like under this evaluation process? Suppose: * Allocate or assign addresses only in standard sizes: /48, /40, /32, /28, /24. * ARIN rounds up to the smallest standard size that the application justifies. * Allocations from published blocks containing allocations of only that one standard size. The minimum routing table impact remains 1 per ISP. Maximum is limited to 1 per allocation. ISPs may choose to allow moderate disaggregation of a standard size for the purpose of traffic engineering. They may not. But that's their choice. Accepting disaggregates for any allocation is no longer an inevitable confluence of technology and ARIN policy. The policy tends towards handing out more addresses (round up) so it arguably reduces the rate at which ISPs return for more, as with Owen's idea. Still can't accurately quantify that, but we know for sure that no ISP will carry a /28 as 16 /32s unless they want to. No change to the one predictable routing factor (minimum). Distinct improvement the other (maximum). Everything else being equal, that makes it a good policy change. Now, suppose you did both standard sizes AND you also did Owen's change? Well, look at that, with both changes Owen's proposal doesn't worsen the maximum routing table impact at all. More addresses are handed out but they don't disaggregate. See my point? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Aug 9 23:57:21 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 09 Aug 2010 20:57:21 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> <4C609C12.9090601@bogus.com> Message-ID: <4C60CE21.8090009@bogus.com> On 8/9/10 7:27 PM, William Herrin wrote: > On Mon, Aug 9, 2010 at 8:23 PM, Joel Jaeggli wrote: >> There are quite a few people on this list who've had deployed dual stack >> ipv6 networks for longer than it took us to put a man on the moon. >> >> Jaded rather than inexperienced is the first thing that some to mind. > > Hi Joel, > > There were plenty of jaded IPv4 gurus in 1993. Those that survived and > were still acknowledged gurus were far wiser and more knowledgeable in > 2003. > > My point is: there's a lot about IPv6 policy we can't yet predict with > a high confidence. We'll do the best we can and we'll change it when > we learn better, but for now there's still a lot of guesswork > involved. > > There are, however, two routing factors related to IPv6 addressing > policy we can evaluate with a high degree of confidence. Because we > can accurately predict them and because the routing table continues to > have scarcity issues when the IPv6 address pool doesn't, I propose > that these predictable routing factors should weigh distinctly more > heavily than the factors whose prediction is less certain. > > * We can predict the difference in the minimum number of routes in the > table as a result of a given policy change. > > * We can predict the difference in the maximum number of routes in the > table as a result of a given policy change. > > Owen's proposal doesn't change the minimum. It's still 1 per ISP. > > Owen's proposal hands out more /32's without offering any mitigation > to obstruct them from being disaggregately announced as /32's. Thus is > significantly increases the maximum number of routes possible in the > table. In the end they're going to be deaggregated to more specifics than that for the same reason the are in ipv4. being able to glob them together when possible into something shorter than a /32 is nice but it's not going to prevent the growth of prefix length. my problem 2001:490::/32 for example has nothing to do with address span and everything to do with topology. nor is it going address other reasons entities end up with non aggregatable prefixes such as M and A, assignments from different RIRs in multiple regions operation of discontiguous networks and so on. > Arguably the policy could reduce the total number of blocks held by > any given ISP by reducing their likelihood of coming back for more. So > there's the outside possibility that an ISP who would otherwise have > announced two separate blocks will instead hold and announce only one. > But even if we could accurately quantify that (and we can't) the ISP > would still hold at least as many disaggregable /32's. > > No change to the one predictable routing factor (minimum). > Significantly worsens the other (maximum). Everything else being > equal, that makes it a bad policy change. > > > What, then, would a good policy change look like under this evaluation > process? Suppose: > > * Allocate or assign addresses only in standard sizes: /48, /40, /32, /28, /24. > * ARIN rounds up to the smallest standard size that the application justifies. > * Allocations from published blocks containing allocations of only > that one standard size. > > The minimum routing table impact remains 1 per ISP. > > Maximum is limited to 1 per allocation. ISPs may choose to allow > moderate disaggregation of a standard size for the purpose of traffic > engineering. They may not. But that's their choice. Accepting > disaggregates for any allocation is no longer an inevitable confluence > of technology and ARIN policy. > > The policy tends towards handing out more addresses (round up) so it > arguably reduces the rate at which ISPs return for more, as with > Owen's idea. Still can't accurately quantify that, but we know for > sure that no ISP will carry a /28 as 16 /32s unless they want to. > > No change to the one predictable routing factor (minimum). Distinct > improvement the other (maximum). Everything else being equal, that > makes it a good policy change. > > > Now, suppose you did both standard sizes AND you also did Owen's > change? Well, look at that, with both changes Owen's proposal doesn't > worsen the maximum routing table impact at all. More addresses are > handed out but they don't disaggregate. > > See my point? > > Regards, > Bill Herrin > > From owen at delong.com Tue Aug 10 01:42:20 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 9 Aug 2010 22:42:20 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> <4C609C12.9090601@bogus.com> Message-ID: <69E0E182-1A81-4A96-B7EE-692C0144DC29@delong.com> On Aug 9, 2010, at 7:27 PM, William Herrin wrote: > On Mon, Aug 9, 2010 at 8:23 PM, Joel Jaeggli wrote: >> There are quite a few people on this list who've had deployed dual stack >> ipv6 networks for longer than it took us to put a man on the moon. >> >> Jaded rather than inexperienced is the first thing that some to mind. > > Hi Joel, > > There were plenty of jaded IPv4 gurus in 1993. Those that survived and > were still acknowledged gurus were far wiser and more knowledgeable in > 2003. > > My point is: there's a lot about IPv6 policy we can't yet predict with > a high confidence. We'll do the best we can and we'll change it when > we learn better, but for now there's still a lot of guesswork > involved. > ARIN IPv6 policy mostly dates back to before 2004 when the NRPM was first introduced. Much of it, I suspect, goes back nearly to the beginning of ARIN over 10 years ago. The following are the changes since 2004: 2003-4 8/3/04 section 6.5.1.1.d modified Expand ISP planning horizon to 5 years (from 2) Clarify qualifying LIRs. 2005-5 2/12/06 sections 6.5.2.2 and 6.7 modified Revise HD ratio requirement from .8 to .94 2005-1 5/9/06 sections 6.5.4 modified, 6.5.8 created Introduction of PI end-user assignments for IPv6 2005-8 5/9/06 Sections 6.1.1, 6.2.7, 6.5.1-5, 6.7, 6.8.3, and 6.9 modified End site from /48 in policy to LIR or ISP internal decision -- Editorial update to 6.6 on 7/27/06 2006-2 1/6/07 Section 6.10 created Microallocations for internal infrastructure 2007-4 6/14/07 Section 6.1.1 modified Removal of the term "INTERIM" from IPv6 policy 2007-25 12/11/07 Sections 6.5.1.1.d, 6.5.3, 6.5.4.4, 6.5.8.2, and 6.5.8.3 modified Proposal titled literally "IPv6 Policy housekeeping". Mostly editorial changes and no real policy modifications Entirely stuff that would be handled today by staff with a consent decree from the Advisory Council. 2007-21 7/8/08 Section 6.5.8.1 modified IPv6 for Legacy Holders with RSA and Efficient Use -- 9/23/09 Editorial updates to sections 6 and 6.2 2008-3 12/18/09 Section 6.5.9 created Community Networks IPv6 Assignment 2009-5 12/18/09 Section 6.11 created IPv6 Multiple Discreet Networks 2009-7 12/18/09 Section 6.5.1.1 modified Remove routing advice from IPv6 policy --1/13/10 Editorial updates to 6.1.1, 6.2, 6.5.4, 6.5.5, 6.6, and 6.8 So, with the exception of those 11 policy changes, our IPv6 policy is now probably close to 10 years old. I'd say we should be applying what we have learned in the interim to policy today with an eye towards applying more knowledge to policy in the more distant future. Certainly, I think we can do better than current IPv6 policy with the knowledge and experience gained over the last 10 years. Some lessons include: Humans are not good at math. Humans are really not good at bit-math. Putting things on nibble boundaries reduces human mistakes. Giving out large prefixes early allows greater aggregation than giving out small prefixes often. Giving out large prefixes early will not create an addressing shortage for any foreseeable (and many unforeseeable) definitions of later. Owen From bill at herrin.us Tue Aug 10 02:24:43 2010 From: bill at herrin.us (William Herrin) Date: Tue, 10 Aug 2010 02:24:43 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C60CE21.8090009@bogus.com> References: <0F29D1BA57992E4CAB5AD2C9AE7B423919B4A4EE@EMV01-UKBR.domain1.systemhost.net> <2B1172AA-CAB1-4DAB-9348-B279321E3DAD@icann.org> <4C609C12.9090601@bogus.com> <4C60CE21.8090009@bogus.com> Message-ID: On Mon, Aug 9, 2010 at 11:57 PM, Joel Jaeggli wrote: > In the end they're going to be deaggregated to more specifics than that > for the same reason the are in ipv4. ?being able to glob them together > when possible into something shorter than a /32 is nice but it's not > going to prevent the growth of prefix length. Of course. But on whose terms? Theirs? Or ours? I'd rather it be theirs; routing policy should be controlled by the people who pay for the routers. But that's only possible if we don't fumble the relevant components of the address allocation practices. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Tue Aug 10 02:51:41 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 09 Aug 2010 23:51:41 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <4C60F6FD.4020405@ipinc.net> On 8/6/2010 12:37 PM, Owen DeLong wrote: > In thinking about address planning and deployment, I've been doing > some various math. > > It seems to me that we have more than enough addresses to use the > following methodology without any concern for exhaustion or shortage > for a very long time. It also seems to me that the advantages in > terms of human factors and network planning simplicity are large > enough to be worthy of consideration. > > As such, I'd like to get community input on whether they would > support policy that would allow ARIN to issue ISP allocations on this > basis: > > 1. Take your number of end-sites attached to each pop. Round up to > the nearest value of x such that x = 2^n where n % 4 = 0 (in other > words, round up your POP size to a nibble boundary). > > 2. Take your expected number of POPs, say a Z-year plan (I seek > community input on the desired value of Z, I'm thinking 5 years). > Again, round up to a nibble boundary. Let's call this value y. > > 3. Multiply x*y to get the number of /48s (ISP) needed. Convert this > to a number (n) of bits (2^n=x*y). > > 4. ARIN should approve you for a 48-n prefix or a /32, whichever is > larger. > > Examples: > > 3000 end sites per POP 154 POPs > > 3000 rounds up to 4096 (12 bits). 154 rounds up to 256 (8 bits). > Total need: 1,048,076 end sites (20 bits) > > 48-20 = 28 -- This provider should receive a /28. > > -- > > 53,000 users per POP 350 POPs > > 53000 -> 65536 (16 bits) 350 -> 4096 (12 bits) Total need: > 268,435,456 /48s (28 bits) > > 48-28 = 20 -- This provider should receive a /20. > > -- > > 300 End sites per POP 10 POPs > > 300 -> 4096 (12 bits) 10 -> 16 (4 bits) > > 48 - 16 = 32 -- This provider should receive a /32. > > I think the above examples are a reasonably representative set of > values for medium, large, and small providers. > > I realize that the resulting values result in a tremendous amount of > extra space being issued as a result of the double rounding, but, I > believe it is worth while for the likely gains in aggregation. > > To put it in perspective, if we took twice as many ISPs in each > region as there are active ASNs in the entire IPv4 internet today, > and gave them all /28s, we would barely use up the first /12 in each > region. We would still have tremendous room to grow within the first > 11 /12s out of 512 that are contained within 2000::/3. > > In my estimation, the average allocation under this scheme would > likely work out very close to that, but, even if I'm off by a factor > of 16, we'd still only use most of 176 /12s and we'd have 336 /12s > untouched in 2000::/3 with the internet being more than double its > current size. > > Please let me know what you think of this idea. If it receives some > positive feedback, I'll start working on turning it into policy. > I would not support something like that. I do agree that the philosophy of an IP addressing shortage should not apply for IPv6 allocations and we should be much more generous for initial IPv6 allocations than for IPv4 allocations. But, my concern is that the justifications your proposing are too specific and seem to fix the idea of an Internet organized around POPs and carriers and the current idea of what it is today. Like William I feel the RIR should merely require a reasonably logical business plan for any allocation over a /32 and be done with it. I would suggest if you want to mod policy to encourage large initial allocations that you look at section 6.5.1.1 and rewrite that - you could start by changing 5 years to 10 years, for example. It has also been my observation that orgs have multiple AS numbers, and many times will subnet their allocations and advertise them under multiple routing slots anyway so as to load balance, thus I think the logic of if orgs all have contiguous allocations organized in a single subnet that it will slow routing table growth to not be believable. My personal belief is that the global BGP table will continue to grow and the bulk of the growth will be driven by increasing fragmentation of the IPv4 space. I have very little faith that the Internet is going to switch to IPv6 right after IPv4-runout, because the Internet is large enough now that people will make decisions on switching to that which is most favorable to -them- and screw everyone else. It is like the use of fossil fuels and global warming on a planetary scale. We all know that collectively, our use of fossil fuels is raising the planet's temperature and we are going to have melted polar icecaps and increased sea levels and all of that as a result of it, and so we should curtail use of fossil fuels to below the level where the planet's natural processes can sequester the carbon produced. However, most of us on an individual basis, every day decide to continue using fossil fuels because the decision to do this benefits us on an individual basis. When I use a quart of gasoline in a lawnmower that cost me $20 at a garage sale to mow my lawn, I save $480 over the guy who buys the new $500 electric lawnmower and pays the power company extra money for the wind power, to mow his lawn. That's why there's only 1 of that guy for every 500 of me out there. After IPv4 runout, for every 1 admin who runs IPv6 and pushes their customers to use it, there will be 500 who will just go buy more IPv4 on the "transfer" market, or offer IPv4 NAT solutions, because this will benefit their individual company. It is going to take increasing infrastructure costs to drive IPv6. It will take a huge rise in tech support costs in delivering RFC1918 to customers, or huge rises in the cost of buying IPv4 on the transfer markets, or huge rises in the costs of new cards for routers because the old ones have too little ram, before ISPs will finally start passing those costs along to customers, and until that happens we won't see change to IPv6. And those costs won't rise until every last scrap of IPv4 is in play, which means hauling a lot of small assignments out of the swamp that they have gone into. Ted > Thanks, > > Owen > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From Wesley.E.George at sprint.com Tue Aug 10 09:21:22 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 10 Aug 2010 08:21:22 -0500 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: As a representative of a company that successfully justified an ARIN IPv6 allocation larger than /32 several years ago, I would pose this question - what problem with the current justification/allocation process are you trying to solve with this? Are you just trying to reduce the instances where people would have to go back to the well for more (possibly non-contiguous) blocks because they either weren't forward thinking enough or good enough at spinning a believable story to justify a bigger chunk of address space? Or am I missing something else? I am not sure I follow your assertion about aggregation benefits, so I think your rationale would have to be more specific about how that might work, perhaps as others have said with more stringent requirements around block allocation and aggregation. Also, how do you see this interacting with something like 2010-12 and 2010-9? Thanks, Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, August 06, 2010 3:38 PM To: arin-ppml at arin.net List Subject: [arin-ppml] IPv6 Allocation Planning In thinking about address planning and deployment, I've been doing some various math. It seems to me that we have more than enough addresses to use the following methodology without any concern for exhaustion or shortage for a very long time. It also seems to me that the advantages in terms of human factors and network planning simplicity are large enough to be worthy of consideration. [snip] Thanks, Owen This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From thomas.x.grasso at ugov.gov Tue Aug 10 09:47:05 2010 From: thomas.x.grasso at ugov.gov (Tom Grasso) Date: Tue, 10 Aug 2010 09:47:05 -0400 Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP Reassignment Registration Requirements In-Reply-To: <4C49FC2F.5050206@arin.net> References: <4C49FC2F.5050206@arin.net> Message-ID: <037401cb3892$8a162980$9e427c80$@x.grasso@ugov.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I support the petition/proposal 109. Thanks. --Tom Thomas X. Grasso, Jr. Supervisory Special Agent Federal Bureau of Investigation National Cyber-Forensics and Training Alliance Direct: +1 412 802-8000 x258 Mobile: +1 412 475-1875 -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: us-ascii wj4DBQFMYVhi3BAi+VrdEsURAuJkAJjRl5k/YvlH/yHgUNR/phmc2U8sAKCETd87 tF31yK4ynjB+xi81GycWZg== =eTTL -----END PGP SIGNATURE----- From terry.l.davis at boeing.com Tue Aug 10 10:11:38 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 10 Aug 2010 07:11:38 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516E41B28@XCH-NW-05V.nw.nos.boeing.com> The current "slow start" philosophy of keeping IPv6 addresses away from entrepreneurs, small businesses, individuals, etc, seems to have been highly effective. - It has kept IPv6 from being deployed in any sizable way until we now face the wall with the end of IPv4 allocations probably next year. - We now face a forced rollout of IPv6 without enough experience in it, especially in large scale IPv6 network operations and security. - We avoided fixing or replacing a conceptually broken protocol like BGP for twenty years. - And every day more IPv4 based apps have come online which inevitably increases the conversion costs for the end user. Excellent long range planning! Take care Terry From bill at herrin.us Tue Aug 10 10:34:12 2010 From: bill at herrin.us (William Herrin) Date: Tue, 10 Aug 2010 10:34:12 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516E41B28@XCH-NW-05V.nw.nos.boeing.com> References: <0267B5481DCC474D8088BF4A25C7F1DF5516E41B28@XCH-NW-05V.nw.nos.boeing.com> Message-ID: On Tue, Aug 10, 2010 at 10:11 AM, Davis, Terry L wrote: > The current "slow start" philosophy of keeping IPv6 addresses >away from entrepreneurs, small businesses, individuals, etc, >seems to have been highly effective. Actually, that would be the "no start" philosophy. In the slow start philosophy, you actually do give addresses to folks just because they want to employ IPv6. We're not entirely there yet... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcr at sandelman.ca Tue Aug 10 11:26:01 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 10 Aug 2010 11:26:01 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516E41B28@XCH-NW-05V.nw.nos.boeing.com> References: <0267B5481DCC474D8088BF4A25C7F1DF5516E41B28@XCH-NW-05V.nw.nos.boeing.com> Message-ID: <31630.1281453961@marajade.sandelman.ca> >>>>> "Terry" == Terry L Davis writes: Terry> The current "slow start" philosophy of keeping IPv6 addresses Terry> away from entrepreneurs, small businesses, individuals, etc, Terry> seems to have been highly effective. Terry> - It has kept IPv6 from being deployed in any sizable way Terry> until we now face the wall with the end of IPv4 allocations Terry> probably next year. +1 -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From cengel at sponsordirect.com Tue Aug 10 12:05:50 2010 From: cengel at sponsordirect.com (Chris Engel) Date: Tue, 10 Aug 2010 12:05:50 -0400 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: Message-ID: > The current "slow start" philosophy of keeping IPv6 addresses > away from entrepreneurs, small businesses, individuals, etc, > seems to have been highly effective. > > - It has kept IPv6 from being deployed in any sizable way > until we now face the wall with the end of IPv4 allocations > probably next year. > > - We now face a forced rollout of IPv6 without enough > experience in it, especially in large scale IPv6 network > operations and security. > > - We avoided fixing or replacing a conceptually broken > protocol like BGP for twenty years. > > - And every day more IPv4 based apps have come online which > inevitably increases the conversion costs for the end user. > > Excellent long range planning! > > Take care > Terry >From my perspective, I don't see that lack of adoption has very much to do with the inability to get address space. The cost/ability to get sufficient IPv6 address space is so far down the list of factors that weigh against deploying it that it doesn't even register on the scale. It's the protocol itself, how different it is from the existing protocol and the lack of support for the tools I need to use on a daily basis that are major factors. If the designers had just stuck 4 more octets on IPv4...kept everything else the same....and called it a day...we'd probably be done and not having this conversation by now...... At least from the end Enterprise end...can't really speak to how things look from the backbone/transit guys. Christopher Engel From aaron at wholesaleinternet.net Tue Aug 10 14:02:35 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Tue, 10 Aug 2010 13:02:35 -0500 Subject: [arin-ppml] Proposal 109 Petition Message-ID: <0ac901cb38b6$37b5dd60$a7219820$@net> This petition was started on the 23rd of July. The PDP process allows for 5 business days to voice support. As far as I can tell those 5 days ended on 7/30. Even allowing an extra day since it was late on the 23rd that puts the end of the petition at 8/2. I count 6 supportive posts to the list between 7/23 and 8/2. Far below the 10 needed. Has the policy changed that we leave this open indefinitely? I notice that 116 was left open a couple extra days as well. I dug through the archive since I seem to miss some of the mailings but couldn't find anything killing this petition. Is it being left open or did someone drop the ball? Aaron From marty at akamai.com Tue Aug 10 14:20:42 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 10 Aug 2010 14:20:42 -0400 Subject: [arin-ppml] Proposal 109 Petition In-Reply-To: <0ac901cb38b6$37b5dd60$a7219820$@net> Message-ID: On 8/10/10 2:02 PM, "Aaron Wendel" wrote: > > I count 6 supportive posts to the list between 7/23 and 8/2. Far below the > 10 needed. > My direct submission to the petition address sans cc: ppml would make 8. Best, -M< From owen at delong.com Tue Aug 10 14:36:29 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Aug 2010 11:36:29 -0700 Subject: [arin-ppml] Proposal 109 Petition In-Reply-To: <0ac901cb38b6$37b5dd60$a7219820$@net> References: <0ac901cb38b6$37b5dd60$a7219820$@net> Message-ID: <6B76C3B7-7473-444F-9786-278C80868413@delong.com> On Aug 10, 2010, at 11:02 AM, Aaron Wendel wrote: > This petition was started on the 23rd of July. The PDP process allows for 5 > business days to voice support. As far as I can tell those 5 days ended on > 7/30. Even allowing an extra day since it was late on the 23rd that puts > the end of the petition at 8/2. > The 5 day clock does not start until publication of the AC meeting minutes. > I count 6 supportive posts to the list between 7/23 and 8/2. Far below the > 10 needed. > > Has the policy changed that we leave this open indefinitely? I notice that > 116 was left open a couple extra days as well. > No. The policy was changed to start the 5 day count down upon publication of the AC meeting minutes in which the action being petitioned was decided. This was done in order to allow the community to have time to consider the petition with the full public facts of the AC decision. > I dug through the archive since I seem to miss some of the mailings but > couldn't find anything killing this petition. Is it being left open or did > someone drop the ball? > If I'm not mistaken, the minutes of the AC meeting in July have not been published yet. Owen From aaron at wholesaleinternet.net Tue Aug 10 14:49:38 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Tue, 10 Aug 2010 13:49:38 -0500 Subject: [arin-ppml] Proposal 109 Petition In-Reply-To: <6B76C3B7-7473-444F-9786-278C80868413@delong.com> References: <0ac901cb38b6$37b5dd60$a7219820$@net> <6B76C3B7-7473-444F-9786-278C80868413@delong.com> Message-ID: <0adb01cb38bc$c9d556c0$5d800440$@net> Thank you for that clarification Owen. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, August 10, 2010 1:36 PM To: Aaron Wendel Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Proposal 109 Petition On Aug 10, 2010, at 11:02 AM, Aaron Wendel wrote: > This petition was started on the 23rd of July. The PDP process allows for 5 > business days to voice support. As far as I can tell those 5 days ended on > 7/30. Even allowing an extra day since it was late on the 23rd that puts > the end of the petition at 8/2. > The 5 day clock does not start until publication of the AC meeting minutes. > I count 6 supportive posts to the list between 7/23 and 8/2. Far below the > 10 needed. > > Has the policy changed that we leave this open indefinitely? I notice that > 116 was left open a couple extra days as well. > No. The policy was changed to start the 5 day count down upon publication of the AC meeting minutes in which the action being petitioned was decided. This was done in order to allow the community to have time to consider the petition with the full public facts of the AC decision. > I dug through the archive since I seem to miss some of the mailings but > couldn't find anything killing this petition. Is it being left open or did > someone drop the ball? > If I'm not mistaken, the minutes of the AC meeting in July have not been published yet. Owen No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3045 - Release Date: 08/10/10 01:35:00 From tedm at ipinc.net Tue Aug 10 14:58:09 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 10 Aug 2010 11:58:09 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <4C61A141.9080707@ipinc.net> On 8/10/2010 9:05 AM, Chris Engel wrote: > >> The current "slow start" philosophy of keeping IPv6 addresses away >> from entrepreneurs, small businesses, individuals, etc, seems to >> have been highly effective. >> What good is the RIR handing a small business an IPv6 block when there's nobody that that small business can plug into that will route it? Tunnelling and 6to4 are not answers. They were kludges and it is a good thing that not a lot of folks implemented them. If they had it would have set back native dual-stacking on the Internet by decades because most ISP's would have had end users tunnelling over their IPv4 networks to IPv6 gateways. >> - It has kept IPv6 from being deployed in any sizable way until we >> now face the wall with the end of IPv4 allocations probably next >> year. >> >> - We now face a forced rollout of IPv6 without enough experience in >> it, especially in large scale IPv6 network operations and >> security. >> This is Chicken Little talk. IPv6 is like complaining about the US Post Office going to a new form of alphanumeric zip codes. A letter is still a letter it just has a different zip code on it, it's still carried and delivered the same way. If you have experience in IPv4 networks then most of that will carry over to IPv6 networks. Frankly i feel talk like this hinders IPv6 deployments because it gives the false impression to people with no IPv6 experience that IPv6 is more difficult than it really is, and is a disincentive to those folks to spend the time to learn about IPv6. >> - We avoided fixing or replacing a conceptually broken protocol >> like BGP for twenty years. >> >> - And every day more IPv4 based apps have come online which >> inevitably increases the conversion costs for the end user. >> >> Excellent long range planning! >> >> Take care Terry > >> From my perspective, I don't see that lack of adoption has very >> much to do with the inability to get address space. The >> cost/ability to get sufficient IPv6 address space is so far down >> the list of factors that weigh against deploying it that it doesn't >> even register on the scale. > > It's the protocol itself, how different it is from the existing > protocol and the lack of support for the tools I need to use on a > daily basis that are major factors. > I agree. > If the designers had just stuck 4 more octets on IPv4...kept > everything else the same....and called it a day...we'd probably be > done and not having this conversation by now...... > I kind of doubt that. IMHO the two biggest impediments to earlier IPv6 deployment in the corporate enterprise sphere have been Cisco and Microsoft. Cisco because Cisco did not release a usable IPv6 in IOS until IOS 12.3 - and 12.3 IOS is too large to run on just about every "edge" router of the 1600 series and earlier. It also is officially unsupported on the NPE300 and earlier 7200 series processors and those series are also widely deployed in the enterprise as "mini" backbone routers. Microsoft because it did not have a usable implementation until Vista. Yes it was an add-on for XP but not fully functional. If we had just tacked on more octets then both of those companies would likely have still dragged their feet. I realize the economics here and that both companies used IPv6 to force their userbase to upgrade. However while I can excuse Microsoft barely, Cisco promised IPv6 support over 15 years ago "when the routing standards were done" and then repeatedly claimed "they weren't done" of course that didn't stop them from implementing many draft standards in other areas than IPv6. > > At least from the end Enterprise end...can't really speak to how > things look from the backbone/transit guys. > The problem is that so much of this deployment is dependent on other people getting their work done. The backbone/transit guys were dependent on Juniper releasing complete IPv6 support and I kind of suspect that wouldn't have happened until Cisco had done it and Juniper perceived the lack of such support as a competitive threat. And Cisco would undoubtedly blame the IETF for not finalizing IPv6. The root nameservers were dependent on the backbone/transit guys being able to route IPv6. And so on and so on. In any of these large projects you always have a "key" or "single point of failure" or some single issue that everything else piles up behind like a logjam. Once that issue is cleared then everything starts happening at once. The IPv6 deployment is like this. We finally have the infrastructure problems taken care of and now the next logjam are getting the large networks to start routing it natively, when that happens then all the rest of the networks will start routing it. When that happens then the next stop point will be the large retail ISPs like Comcast starting to offer native IPv6 to their customers, that will force all the rest of the retail ISPs to offer it. Then last will be the content providers & end users. This is just how large deployments of any project work. If you look at the US Interstate Highway system deployment for example, there is no surprise that seat belts, crush bumpers, airbags and so on all came into automobiles AFTER that system was deployed - because before that system was deployed, vehicle speeds were low enough that most crashes were survivable without that safety gear. Even though, the first seat belt patent was issued in 1885 - by those "small businesses and inventors" Ted > Christopher Engel > > _______________________________________________ PPML You are > receiving this message because you are subscribed to the ARIN Public > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact > info at arin.net if you experience any issues. From charles at office.tcsn.net Tue Aug 10 15:49:57 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Tue, 10 Aug 2010 12:49:57 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61A141.9080707@ipinc.net> References: <4C61A141.9080707@ipinc.net> Message-ID: <4C61AD65.20601@office.tcsn.net> Ted Mittelstaedt wrote: > > > On 8/10/2010 9:05 AM, Chris Engel wrote: >> >>> The current "slow start" philosophy of keeping IPv6 addresses away >>> from entrepreneurs, small businesses, individuals, etc, seems to >>> have been highly effective. >>> > > What good is the RIR handing a small business an IPv6 block when > there's nobody that that small business can plug into that will > route it? > Snipped the rest as I had no disagreement with it. But in response to the above: Why would I bother spending time pressuring my upstreams to transport and BGP advertise IPv6 if I can't get an allocation from ARIN in the first place? -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From rflaim at stas.fbi.gov Tue Aug 10 15:52:37 2010 From: rflaim at stas.fbi.gov (Bobby Flaim) Date: Tue, 10 Aug 2010 15:52:37 -0400 Subject: [arin-ppml] Proposal 109 Message-ID: I support the petition for draft proposal 109. Robert Flaim -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles at office.tcsn.net Tue Aug 10 15:54:49 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Tue, 10 Aug 2010 12:54:49 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <4C61AE89.2090509@office.tcsn.net> Chris Engel wrote: > >From my perspective, I don't see that lack of adoption has very much to do with the inability to get address space. The cost/ability to get sufficient IPv6 address space is so far down the list of factors that weigh against deploying it that it doesn't even register on the scale. > > It's the protocol itself, how different it is from the existing protocol and the lack of support for the tools I need to use on a daily basis that are major factors. > > If the designers had just stuck 4 more octets on IPv4...kept everything else the same....and called it a day...we'd probably be done and not having this conversation by now...... > > > At least from the end Enterprise end...can't really speak to how things look from the backbone/transit guys. > > Christopher Engel > This perspective I can directly dispute from the perspective of what is probably one of the smallest 'transit guys' on the list. The one and only reason the company I represent has not initiated adoption of IPv6 is the cost increase in fees to ARIN. I understand that PPML is not the place to discuss ARIN's fee structure, so this is not intended as an appeal. But as a statement of what is barring our IPv6 adoption: As long as the minimum allocation of IPv6 for ISPs costs double what we pay now for a /21 of IPv4 (the minimum allocation for multihomed ISPs), my company will not be deploying IPv6. Deploying IPv6 using FD00:: addresses in dual stack with preexisting IPv4 address has worked well in our internal testing thus far. So at the moment our opinion is that the protocol itself is not an issue. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From charles at office.tcsn.net Tue Aug 10 15:41:50 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Tue, 10 Aug 2010 12:41:50 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: Message-ID: <4C61AB7E.60305@office.tcsn.net> Chris Engel wrote: > >From my perspective, I don't see that lack of adoption has very much to do with the inability to get address space. The cost/ability to get sufficient IPv6 address space is so far down the list of factors that weigh against deploying it that it doesn't even register on the scale. > > It's the protocol itself, how different it is from the existing protocol and the lack of support for the tools I need to use on a daily basis that are major factors. > > If the designers had just stuck 4 more octets on IPv4...kept everything else the same....and called it a day...we'd probably be done and not having this conversation by now...... > > > At least from the end Enterprise end...can't really speak to how things look from the backbone/transit guys. > > Christopher Engel > > This perspective I can directly dispute from the perspective of what is probably one of the smallest 'transit guys' on the list. The one and only reason the company I represent has not initiated adoption of IPv6 is the cost increase in fees to ARIN. I understand that PPML is not the place to discuss ARIN's fee structure, so this is not intended as an appeal. But as a statement of what is barring our IPv6 adoption: As long as the minimum allocation of IPv6 for ISPs costs double what we pay now for a /21 of IPv4 (the minimum allocation for multihomed ISPs), my company will not be deploying IPv6. Deploying IPv6 using FD00:: addresses in dual stack with preexisting IPv4 address has worked well in our internal testing thus far. So at the moment our opinion is that the protocol itself is not an issue. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From scottleibrand at gmail.com Tue Aug 10 16:29:57 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 10 Aug 2010 13:29:57 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61AE89.2090509@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> Message-ID: <4C61B6C5.6080103@gmail.com> On Tue 8/10/2010 12:54 PM, Charles O'Hern wrote: > The one and > only reason the company I represent has not initiated adoption of IPv6 > is the cost increase in fees to ARIN. I understand that PPML is not the > place to discuss ARIN's fee structure, so this is not intended as an > appeal. > > But as a statement of what is barring our IPv6 adoption: As long as the > minimum allocation of IPv6 for ISPs costs double what we pay now for a > /21 of IPv4 (the minimum allocation for multihomed ISPs), my company > will not be deploying IPv6. > Would it help to change the minimum allocation for ISPs to /36? Would that be sufficient for your 10-year needs, or do you really need a /32? > Deploying IPv6 using FD00:: addresses in dual stack with preexisting > IPv4 address has worked well in our internal testing thus far. So at > the moment our opinion is that the protocol itself is not an issue. > Good to hear. When your upstream makes v6 available, will you be getting a /48 from them and deploying with that? -Scott From sethm at rollernet.us Tue Aug 10 16:38:42 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 10 Aug 2010 13:38:42 -0700 Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP Reassignment Registration Requirements In-Reply-To: <4C49FC2F.5050206@arin.net> References: <4C49FC2F.5050206@arin.net> Message-ID: <4C61B8D2.6070807@rollernet.us> On 7/23/2010 13:31, ARIN wrote: > The message below started a petition regarding the ARIN Advisory > Council's decision not to select "Policy Proposal 109. Standardize IP > Reassignment Registration Requirements" as a draft policy at this time. > The AC's decision was posted by ARIN staff to PPML on 20 July 2010. > I support the petition of proposal 109. ~Seth From cgrundemann at gmail.com Tue Aug 10 16:46:01 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 10 Aug 2010 14:46:01 -0600 Subject: [arin-ppml] Discussion Petition for Proposal 109 - Standardize IP Reassignment Registration Requirements In-Reply-To: <4C61B8D2.6070807@rollernet.us> References: <4C49FC2F.5050206@arin.net> <4C61B8D2.6070807@rollernet.us> Message-ID: Thanks for speaking up Seth! ~Chris On Tue, Aug 10, 2010 at 14:38, Seth Mattinen wrote: > On 7/23/2010 13:31, ARIN wrote: >> The message below started a petition regarding the ARIN Advisory >> Council's decision not to select "Policy Proposal 109. Standardize IP >> Reassignment Registration Requirements" as a draft policy at this time. >> The AC's decision was posted by ARIN staff to PPML on 20 July 2010. >> > > > I support the petition of proposal 109. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From bensons at queuefull.net Tue Aug 10 17:06:03 2010 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 10 Aug 2010 16:06:03 -0500 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61B6C5.6080103@gmail.com> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> Message-ID: On 10 Aug 10, at 3:29 PM, Scott Leibrand wrote: > Would it help to change the minimum allocation for ISPs to /36? Would that be sufficient for your 10-year needs, or do you really need a /32? Why stop at /36? Why not /40 or /48? Not that block size is proportional to fee size, but I'm curious about relationship. Cheers, -Benson From scottleibrand at gmail.com Tue Aug 10 17:13:18 2010 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 10 Aug 2010 14:13:18 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> Message-ID: <4C61C0EE.6070004@gmail.com> On Tue 8/10/2010 2:06 PM, Benson Schliesser wrote: > On 10 Aug 10, at 3:29 PM, Scott Leibrand wrote: > > >> Would it help to change the minimum allocation for ISPs to /36? Would that be sufficient for your 10-year needs, or do you really need a /32? >> > Why stop at /36? Why not /40 or /48? > We want ISPs to give out /48s to any of their customers who ask for one. A /36 is enough to allocate 4000 /48s, whereas a /40 only gives you 256. IMO /36 could be reasonable for small ISPs, but /40 or smaller is too constraining and too likely to get used up. > Not that block size is proportional to fee size, but I'm curious about relationship. I understand that ARIN is considering changes to the fee structure (https://www.arin.net/fees/fee_schedule.html). Not sure what they're considering, but one option may be to charge less for a /36 than for a /32. Without some way of differentiating small ISPs from medium-sized ISPs in the v6 world, it's hard to stick with the fees-based-on-block-size model we have now. Of course, fees aren't policy. -Scott From charles at office.tcsn.net Tue Aug 10 17:25:43 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Tue, 10 Aug 2010 14:25:43 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61B6C5.6080103@gmail.com> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> Message-ID: <4C61C3D7.2090004@office.tcsn.net> Scott Leibrand wrote: > On Tue 8/10/2010 12:54 PM, Charles O'Hern wrote: >> The one and >> only reason the company I represent has not initiated adoption of IPv6 >> is the cost increase in fees to ARIN. I understand that PPML is not the >> place to discuss ARIN's fee structure, so this is not intended as an >> appeal. >> >> But as a statement of what is barring our IPv6 adoption: As long as the >> minimum allocation of IPv6 for ISPs costs double what we pay now for a >> /21 of IPv4 (the minimum allocation for multihomed ISPs), my company >> will not be deploying IPv6. >> > > Would it help to change the minimum allocation for ISPs to /36? Would > that be sufficient for your 10-year needs, or do you really need a /32? We don't really need a /32. If we calculate need based on allocating /56's to our residential and small business customers given our growth over the last 10 years, a very liberal estimate would be that we'd need no more than a /40 by 2020 (and probably far beyond). > >> Deploying IPv6 using FD00:: addresses in dual stack with preexisting >> IPv4 address has worked well in our internal testing thus far. So at >> the moment our opinion is that the protocol itself is not an issue. >> > > Good to hear. When your upstream makes v6 available, will you be > getting a /48 from them and deploying with that? > > -Scott > Yes, as soon as either of our upstreams has it available, and if we are still unable to obtain an ARIN allocation, we'll be requesting at least two /48's. The problem then will be getting upstream A to advertise and transport the traffic for destination addresses allocated to us from upstream B, and visa versa. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From info at arin.net Tue Aug 10 17:25:59 2010 From: info at arin.net (ARIN) Date: Tue, 10 Aug 2010 17:25:59 -0400 Subject: [arin-ppml] Petition Successful - 109. Standardize IP Reassignment Registration Requirements Message-ID: <4C61C3E7.5050305@arin.net> The petition received 10 statements of support and is therefore successful. The proposal will be posted shortly as a Draft Policy for discussion and review by the community on the Public Policy Mailing List and at the Public Policy Meeting in October. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Aug 10 17:27:36 2010 From: info at arin.net (ARIN) Date: Tue, 10 Aug 2010 17:27:36 -0400 Subject: [arin-ppml] Draft Policy 2010-14: Standardize IP Reassignment Registration Requirements Message-ID: <4C61C448.7090403@arin.net> Draft Policy 2010-14 Standardize IP Reassignment Registration Requirements Draft Policy 2010-14 comes from the successful petition of "Policy Proposal 109. Standardize IP Reassignment Registration Requirements." The draft policy is being posted for adoption discussion on the PPML and at the Public Policy Meeting in October. The text of this draft policy is under the control of the petitioner, Chris Grundemann, until the conclusion of the Public Policy Meeting. Draft Policy 2010-14 is below and can be found at: https://www.arin.net/policy/proposals/2010_14.html You are encouraged to discuss Draft Policy 2010-14 on the PPML prior to the Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2010-14 Standardize IP Reassignment Registration Requirements Version/Date: 10 August 2010 Policy statement: ## Definitions ## - Add: 2.3. Organizational Information When required, organization Information must include at a minimum: Legal name, street address, city, state, zip code equivalent and at least one valid technical and one valid abuse POC. Each POC shall be designated by the organization and must include at least a verifiable email address and phone number. 2.12. Residential Customer End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only are considered residential customers. ## IPv4 ## - Rename 4.2.3.7. "Reassignment information" to "Registration" and add text: ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. - Rename 4.2.3.7.1. "Customer organization information" to "Reassignment Information" and replace text with: Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5. - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments visible within 7 days" and replace text with: All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with: 4.2.3.7.3. Residential Subscribers 4.2.3.7.3.1. Residential Market Area ISPs that assign address space to the infrastructure to which their customers connect rather than to individual subscribers must register assignment information regarding each market area holding such an address block. Market area reassignments shall be registered with the network name used to identify each market area. Any assignment to specific end-users holding /29 and larger blocks still requires registration. A >50% utilization rate shall be considered efficient for market area reassignments from the ISPs most recent allocation. 4.2.3.7.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. - Strike section 4.2.6. "Cable Address Space Policy" ## IPv6 ## - Replace Section 6.5.5. with: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. 6.5.5.1. Reassignment information Each IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Market Area ISPs that assign address space to the infrastructure to which their customers connect rather than to individual subscribers must register assignment information regarding each market area holding such an address block. Market area reassignments shall be registered with the network name used to identify each market area. Any assignment to specific end-users holding /64 and larger blocks still requires registration. A >50% utilization rate shall be considered efficient for market area reassignments from the ISPs most recent allocation. 6.5.5.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. ## Resource Review ## - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert the following: c. whenever ARIN has reason to believe that an organization is not complying with reassignment policies, or -- Rationale: #Changes in this version: After many conversations both at and following the last public policy meeting in Toronto, some revisions have been made. These all address specific concerns raised by multiple interested parties: 1) Organizational Information ? Phone number, street address and abuse POC now required. 2) Residential Customer ? Added ?for personal use only? to the definition. 3) Registration (4.2.3.7 & 6.5.5) ? Added ?but not limited to? WRT assignment histories. 4) IPv6 ? Requires all /64 and larger blocks to be registered. 5) Resource Review ? Added this section. #Short Rational: This proposal intends to do several things: 1) Bring IPv4 and IPv6 policy more in line with each other to make the NRPM easier to understand and comply with - at least as it relates to reassignment information. 2) Specifically define what organizational information is required to be added to WHOIS when reassignments are made to client organizations. 3) To specifically state that a client organization may designate the POC of their choice for any/all WHOIS entries in policy. This includes designating an upstream POC as their own preferred POC (which allows for simple reassignments). 4) Expands the privileges previously reserved solely for IPv4 cable ISPs to all ISPs/LIRs with residential/dhcp-type subscribers. 5) Specifically define the term "residential customer." 6) Allow ARIN to conduct resource reviews based on failure to comply with registration / reassignment policies. #Expanded Rational: 1) This policy restructures the reassignment and registration sections of the IPv4 and IPv6 policies. a) The IPv4 section is renamed "registration." b) The IPv4 policy is shortened and rewritten for clarity. c) The IPv6 policy is totally rewritten in a format that matches the IPv4 policy. * These structural changes are meant to make it easier to compare the two sections. I believe that having the IPv6 and IPv4 policies written in completely different formats and structures (as they are in many cases now) confuses the issues and makes it very hard to understand what is different and what is the same across the two sections. Bringing them into a similar format should help ease the migration to IPv6 as folks can quickly and easily understand the differences and the similarities. d) The IPv6 policy is altered from a /56 minimum needing to be registered to a /64. A /64 is a single IPv6 subnet where as a /56 contains many subnets (that should all be recorded in the WHOIS directory if handed out to other organizations). 2) This policy adds a definition of "organizational information" which is used in the existing policy but not currently defined anywhere in the NRPM. a) The definition states that legal name and physical address are required for client organizations. b) The definition states that POCs are required but can be designated by the client organization - it spells out that the client org can choose to use their upstream as a POC. c) The definition requires that each POC have a valid email address and phone number. 3) This policy takes the privileges granted specifically to IPv4 cable operators in section 4.2.6. "Cable Address Space Policy" and grants them to all ISPs who serve residential areas. a) It allows all ISPs with residential coverage to register/swip/rwhois an entire market area. b) It retains the existing residential customer privacy policy for all customers with larger IP blocks. * This change removes the need for any ISP to enter residential customers into whois at all. 4) This policy also extends the >50% utilization rate, currently granted only to IPv4 cable operators, to all ISPs with a residential footprint. * This change offsets the ability to register/swip/rwhois market areas. For all other allocation types, efficient utilization is based on SWIPs, not on actual utilization. When an organization is able to SWIP an entire market area, this must be checked against actual utilization. This policy maintains the current line set at >50%. **The 50% mark on the most recent allocation is because you can quickly distribute most of your address space across your provisioning footprint, leaving nothing left for growth while the lease count of the provisioned customers catches up to the blocks allocated. (Dan Alexander's words) 5) Current policy references "residential customers" but there is no current definition of residential customers in the NRPM. This has reportedly been an on-going problem for ARIN and it?s customers. 6) Not properly registering reassignment information could be a sign of other improper or illicit behavior and should justify a resource review (audit) by ARIN when necessary, regardless of when the last review took place. From owen at delong.com Tue Aug 10 22:03:06 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Aug 2010 19:03:06 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61C3D7.2090004@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> Message-ID: <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> On Aug 10, 2010, at 2:25 PM, Charles O'Hern wrote: > Scott Leibrand wrote: >> On Tue 8/10/2010 12:54 PM, Charles O'Hern wrote: >>> The one and >>> only reason the company I represent has not initiated adoption of IPv6 >>> is the cost increase in fees to ARIN. I understand that PPML is not the >>> place to discuss ARIN's fee structure, so this is not intended as an >>> appeal. >>> >>> But as a statement of what is barring our IPv6 adoption: As long as the >>> minimum allocation of IPv6 for ISPs costs double what we pay now for a >>> /21 of IPv4 (the minimum allocation for multihomed ISPs), my company >>> will not be deploying IPv6. >>> >> >> Would it help to change the minimum allocation for ISPs to /36? Would >> that be sufficient for your 10-year needs, or do you really need a /32? > We don't really need a /32. If we calculate need based on allocating > /56's to our residential and small business customers given our growth > over the last 10 years, a very liberal estimate would be that we'd need > no more than a /40 by 2020 (and probably far beyond). What if you properly gave them /48s? If a /40 works for you at /56, then, a /36 works for you at /48s. >> >>> Deploying IPv6 using FD00:: addresses in dual stack with preexisting >>> IPv4 address has worked well in our internal testing thus far. So at >>> the moment our opinion is that the protocol itself is not an issue. >>> >> >> Good to hear. When your upstream makes v6 available, will you be >> getting a /48 from them and deploying with that? >> >> -Scott >> > Yes, as soon as either of our upstreams has it available, and if we are > still unable to obtain an ARIN allocation, we'll be requesting at least > two /48's. The problem then will be getting upstream A to advertise > and transport the traffic for destination addresses allocated to us from > upstream B, and visa versa. Yeah, that's ugly and best avoided. I think we can improve policy to make it possible for you to: 1. Get /36s 2. For others to get even larger blocks if they want them. 3. To have ARIN round allocations up to nibble boundaries. That way we can make it easier for those that choose to to avoid disaggregation. Might not be the perfect solution, but, I think it is an improvement on the current situation. Owen From Wesley.E.George at sprint.com Wed Aug 11 10:23:01 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 11 Aug 2010 09:23:01 -0500 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61C3D7.2090004@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Charles O'Hern Sent: Tuesday, August 10, 2010 5:26 PM To: Scott Leibrand Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 Allocation Planning > Good to hear. When your upstream makes v6 available, will you be > getting a /48 from them and deploying with that? > > -Scott > Yes, as soon as either of our upstreams has it available, and if we are still unable to obtain an ARIN allocation, we'll be requesting at least two /48's. The problem then will be getting upstream A to advertise and transport the traffic for destination addresses allocated to us from upstream B, and visa versa. [[WEG]] Let's be clear - you appear to be able to obtain (justify) space, but cost is the issue. Not trying to minimize that, I understand that the bottom line is that you still have no IPv6 PI space, but since we're trying to discuss changes in allocation justification, I want to make sure I'm understanding the issue you're raising. It appears to go back to the overarching discussion of whether PA space is actually going to meet the needs of some portion of the internet community or not. Speaking for my own employer, we'll accept announcements of IPv6 PA space that isn't ours as long as it's at least a /48, and I think most other ISPs will end up doing the same since that's more or less status quo on IPv4. Thanks Wes George This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From tedm at ipinc.net Wed Aug 11 12:54:23 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Aug 2010 09:54:23 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61AD65.20601@office.tcsn.net> References: <4C61A141.9080707@ipinc.net> <4C61AD65.20601@office.tcsn.net> Message-ID: <4C62D5BF.9060904@ipinc.net> On 8/10/2010 12:49 PM, Charles O'Hern wrote: > > Ted Mittelstaedt wrote: >> >> >> On 8/10/2010 9:05 AM, Chris Engel wrote: >>> >>>> The current "slow start" philosophy of keeping IPv6 addresses away >>>> from entrepreneurs, small businesses, individuals, etc, seems to >>>> have been highly effective. >>>> >> >> What good is the RIR handing a small business an IPv6 block when >> there's nobody that that small business can plug into that will >> route it? >> > Snipped the rest as I had no disagreement with it. But in response to > the above: Why would I bother spending time pressuring my upstreams to > transport and BGP advertise IPv6 if I can't get an allocation from ARIN > in the first place? > Because if you can't get an allocation from ARIN then the ONLY place else you can get it from is your upstreams. We WANT you to be spending time pressuring your upstreams to transport and advertise IPv6 - if you don't, who will? And if nobody does, when will they start doing it? you want IPv67 for what? For expected eventual demand from customers, because your ahead of the curve. Your upstreams are not ahead of the curve, they war waiting for ACTUAL demand from customers - that means you - before they start looking at it. So, you want IPv6 - you go to ARIN can can't get it - you then go to the next best place - your upstreams - you pressure them - they start routing IPv6 - mission accomplished. Ted From tedm at ipinc.net Wed Aug 11 13:25:51 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Aug 2010 10:25:51 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C61C3D7.2090004@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> Message-ID: <4C62DD1F.7020401@ipinc.net> On 8/10/2010 2:25 PM, Charles O'Hern wrote: > We don't really need a /32. Another wonderful statement right up there with: "We believe OS/2 is the operating system of the 1990's" --bill gates, comdex "The Macintosh uses an experimental pointing device called a ?mouse?. There is no evidence that people want to use these things. I don't want one of these new fangled devices" --John C Dvorak "There is no reason for any individual to have a computer in his home" --Ken Olsen Ted From charles at office.tcsn.net Wed Aug 11 14:13:53 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 11 Aug 2010 11:13:53 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> Message-ID: <4C62E861.8090000@office.tcsn.net> Owen DeLong wrote: > On Aug 10, 2010, at 2:25 PM, Charles O'Hern wrote > What if you properly gave them /48s? If a /40 works for you at /56, then, > a /36 works for you at /48s. > > I was simplifying a bit. About a third of our customers are dynamic 802.11 hotspot customers. Since those are each single hosts, I can't foresee allocating more than a /64 per hotspot with each host getting a single dynamic address. But this perception could be based on a great deal of ignorance of the future of these types of connections. (maybe a vlan per customer with each vlan using a /64, but the still only gets its one host address.) For static connections to residences I'd need at most 2000 /48's. A /36 would be plenty. >> Yes, as soon as either of our upstreams has it available, and if we are >> still unable to obtain an ARIN allocation, we'll be requesting at least >> two /48's. The problem then will be getting upstream A to advertise >> and transport the traffic for destination addresses allocated to us from >> upstream B, and visa versa. >> > > Yeah, that's ugly and best avoided. I think we can improve policy to > make it possible for you to: > > 1. Get /36s > 2. For others to get even larger blocks if they want them. > 3. To have ARIN round allocations up to nibble boundaries. > > That way we can make it easier for those that choose to to avoid > disaggregation. Might not be the perfect solution, but, I think it is an > improvement on the current situation. > > Owen > > Yes, that would be great. I'm hoping that ARIN does revise their fee schedule. Frankly I don't care if we get a /36 or a /32. I'd just like a IPv6 allocation of 'equivalent' size of our current IPv4 allocation, whatever that equivalent size is, without increasing our fees. Ideally I want to be able to assign each end user a /48, have enough /48 networks available in a continguous block for forseeable customer growth and advertise one aggregate route to each of our upstream AS's. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From charles at office.tcsn.net Wed Aug 11 14:28:03 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 11 Aug 2010 11:28:03 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> Message-ID: <4C62EBB3.6000506@office.tcsn.net> George, Wes E [NTK] wrote: > [[WEG]] Let's be clear - you appear to be able to obtain (justify) space, but cost is the issue. Not trying to minimize that, I understand that the bottom line is that you still have no IPv6 PI space, but since we're trying to discuss changes in allocation justification, I want to make sure I'm understanding the issue you're raising. It appears to go back to the overarching discussion of whether PA space is actually going to meet the needs of some portion of the internet community or not. Speaking for my own employer, we'll accept announcements of IPv6 PA space that isn't ours as long as it's at least a /48, and I think most other ISPs will end up doing the same since that's more or less status quo on IPv4. > > Thanks > Wes George > > > This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. > > This is refreshing to hear. Its been quite a number of years since we attempted to get our upstreams to accept and re-advertise PA space. Oru worries in this regard are based on the refusal to do so on the part of all of our previous providers. This includes your own employer Sprint (prior to M&A with Nextel), but this was many years ago. If policies have changed, this is great news. The next hurdle with PA space is keeping an allocation after changing upstreams. Our upstreams change almost everytime our contracts expire. How acceptable is it in the current environment to maintain PA space from a company that is no longer an upstream provider? -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From charles at office.tcsn.net Wed Aug 11 14:34:40 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 11 Aug 2010 11:34:40 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C62D5BF.9060904@ipinc.net> References: <4C61A141.9080707@ipinc.net> <4C61AD65.20601@office.tcsn.net> <4C62D5BF.9060904@ipinc.net> Message-ID: <4C62ED40.1020509@office.tcsn.net> Ted Mittelstaedt wrote: > > > On 8/10/2010 12:49 PM, Charles O'Hern wrote: >> >> Snipped the rest as I had no disagreement with it. But in response to >> the above: Why would I bother spending time pressuring my upstreams to >> transport and BGP advertise IPv6 if I can't get an allocation from ARIN >> in the first place? >> > > Because if you can't get an allocation from ARIN then the ONLY place > else you can get it from is your upstreams. > > We WANT you to be spending time pressuring your upstreams to transport > and advertise IPv6 - if you don't, who will? And if nobody does, when > will they start doing it? > > you want IPv67 for what? For expected eventual demand from customers, > because your ahead of the curve. Your upstreams are not ahead of the > curve, they war waiting for ACTUAL demand from customers - that means > you - before they start looking at it. > > So, you want IPv6 - you go to ARIN can can't get it - you then go to > the next best place - your upstreams - you pressure them - they start > routing IPv6 - mission accomplished. > > Ted You are absolutely right, I should pressure them to deploy IPv6 in my area no matter my plans. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From owen at delong.com Wed Aug 11 14:41:08 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Aug 2010 11:41:08 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C62E861.8090000@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> Message-ID: <863F03C1-BB01-4E18-9B04-E81C41ACB0BB@delong.com> On Aug 11, 2010, at 11:13 AM, Charles O'Hern wrote: > Owen DeLong wrote: >> On Aug 10, 2010, at 2:25 PM, Charles O'Hern wrote >> What if you properly gave them /48s? If a /40 works for you at /56, then, >> a /36 works for you at /48s. >> >> > I was simplifying a bit. About a third of our customers are dynamic > 802.11 hotspot customers. Since those are each single hosts, I can't > foresee allocating more than a /64 per hotspot with each host getting a > single dynamic address. But this perception could be based on a great > deal of ignorance of the future of these types of connections. (maybe a > vlan per customer with each vlan using a /64, but the still only gets > its one host address.) > Then you lack imagination. Why not give a /48 (or more) per hot spot and let the hotspots do DHCP-PD to devices that want to act as routers giving them /56s (if they need multiple nets) or /64s (if they only have one collection of devices behind them)? > For static connections to residences I'd need at most 2000 /48's. A > /36 would be plenty. Exactly. >>> Yes, as soon as either of our upstreams has it available, and if we are >>> still unable to obtain an ARIN allocation, we'll be requesting at least >>> two /48's. The problem then will be getting upstream A to advertise >>> and transport the traffic for destination addresses allocated to us from >>> upstream B, and visa versa. >>> >> >> Yeah, that's ugly and best avoided. I think we can improve policy to >> make it possible for you to: >> >> 1. Get /36s >> 2. For others to get even larger blocks if they want them. >> 3. To have ARIN round allocations up to nibble boundaries. >> >> That way we can make it easier for those that choose to to avoid >> disaggregation. Might not be the perfect solution, but, I think it is an >> improvement on the current situation. >> >> Owen >> >> > Yes, that would be great. I'm hoping that ARIN does revise their fee > schedule. > Actually, no need to revise the fee schedule. If we make it possible for you to get a /36, the existing fee schedule meets your requirements. Simple policy change. Look for a draft shortly after the October meeting, if not before. > Frankly I don't care if we get a /36 or a /32. I'd just like a IPv6 > allocation of 'equivalent' size of our current IPv4 allocation, whatever > that equivalent size is, without increasing our fees. Ideally I want to > be able to assign each end user a /48, have enough /48 networks > available in a continguous block for forseeable customer growth and > advertise one aggregate route to each of our upstream AS's. > There isn't an equivalent. IPv4 allocations are based on host counts and dense assignment with host density efficiency being the primary goal and aggregation coming in second due to address scarcity. IPv6 allocations are based on network counts and sparse assignment with aggregation being the primary goal and network density efficiency being a distant second. Host density efficiency is actually meaningless in IPv6. (Note: Host density efficiency in this context is the Nhosts/Naddresses, this is not related to the "Host Density Ratio" mentioned in policy which has nothing to do with hosts and is unfortunately poorly named IMHO). Owen From owen at delong.com Wed Aug 11 15:40:57 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Aug 2010 12:40:57 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C62EBB3.6000506@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <4C62EBB3.6000506@office.tcsn.net> Message-ID: <4FCE5ED9-5847-4225-9C34-F0157D62BA69@delong.com> On Aug 11, 2010, at 11:28 AM, Charles O'Hern wrote: > George, Wes E [NTK] wrote: >> [[WEG]] Let's be clear - you appear to be able to obtain (justify) space, but cost is the issue. Not trying to minimize that, I understand that the bottom line is that you still have no IPv6 PI space, but since we're trying to discuss changes in allocation justification, I want to make sure I'm understanding the issue you're raising. It appears to go back to the overarching discussion of whether PA space is actually going to meet the needs of some portion of the internet community or not. Speaking for my own employer, we'll accept announcements of IPv6 PA space that isn't ours as long as it's at least a /48, and I think most other ISPs will end up doing the same since that's more or less status quo on IPv4. >> >> Thanks >> Wes George >> >> >> This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >> >> > This is refreshing to hear. Its been quite a number of years since we > attempted to get our upstreams to accept and re-advertise PA space. Oru > worries in this regard are based on the refusal to do so on the part of > all of our previous providers. This includes your own employer Sprint > (prior to M&A with Nextel), but this was many years ago. If policies > have changed, this is great news. > > The next hurdle with PA space is keeping an allocation after changing > upstreams. Our upstreams change almost everytime our contracts expire. > How acceptable is it in the current environment to maintain PA space > from a company that is no longer an upstream provider? > I don't think that will ever happen. I think if you want to keep your addresses the same when changing providers, you need to plan on getting PI space from an RIR. Owen From tedm at ipinc.net Wed Aug 11 15:51:14 2010 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 11 Aug 2010 12:51:14 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4FCE5ED9-5847-4225-9C34-F0157D62BA69@delong.com> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <4C62EBB3.6000506@office.tcsn.net> <4FCE5ED9-5847-4225-9C34-F0157D62BA69@delong.com> Message-ID: <4C62FF32.3000909@ipinc.net> On 8/11/2010 12:40 PM, Owen DeLong wrote: > > On Aug 11, 2010, at 11:28 AM, Charles O'Hern wrote: > >> George, Wes E [NTK] wrote: >>> [[WEG]] Let's be clear - you appear to be able to obtain (justify) space, but cost is the issue. Not trying to minimize that, I understand that the bottom line is that you still have no IPv6 PI space, but since we're trying to discuss changes in allocation justification, I want to make sure I'm understanding the issue you're raising. It appears to go back to the overarching discussion of whether PA space is actually going to meet the needs of some portion of the internet community or not. Speaking for my own employer, we'll accept announcements of IPv6 PA space that isn't ours as long as it's at least a /48, and I think most other ISPs will end up doing the same since that's more or less status quo on IPv4. >>> >>> Thanks >>> Wes George >>> >>> >>> This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. >>> >>> >> This is refreshing to hear. Its been quite a number of years since we >> attempted to get our upstreams to accept and re-advertise PA space. Oru >> worries in this regard are based on the refusal to do so on the part of >> all of our previous providers. This includes your own employer Sprint >> (prior to M&A with Nextel), but this was many years ago. If policies >> have changed, this is great news. We used Sprint for 3 years back in 1999-2002 as I recall and they had no problem advertising IPv4 space assigned by Cable & Wireless. This must have been MANY, MANY years ago that they didn't do it. Ted From owen at delong.com Wed Aug 11 16:45:34 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 11 Aug 2010 13:45:34 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <863F03C1-BB01-4E18-9B04-E81C41ACB0BB@delong.com> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> <863F03C1-BB01-4E18-9B04-E81C41ACB0BB@delong.com> Message-ID: <13FF389B-97EC-4779-9C98-46DCE2FE7D46@delong.com> On Aug 11, 2010, at 11:41 AM, Owen DeLong wrote: > > On Aug 11, 2010, at 11:13 AM, Charles O'Hern wrote: > >> Owen DeLong wrote: >>> On Aug 10, 2010, at 2:25 PM, Charles O'Hern wrote >>> What if you properly gave them /48s? If a /40 works for you at /56, then, >>> a /36 works for you at /48s. >>> >>> >> I was simplifying a bit. About a third of our customers are dynamic >> 802.11 hotspot customers. Since those are each single hosts, I can't >> foresee allocating more than a /64 per hotspot with each host getting a >> single dynamic address. But this perception could be based on a great >> deal of ignorance of the future of these types of connections. (maybe a >> vlan per customer with each vlan using a /64, but the still only gets >> its one host address.) >> > Then you lack imagination. Why not give a /48 (or more) per hot spot > and let the hotspots do DHCP-PD to devices that want to act as routers > giving them /56s (if they need multiple nets) or /64s (if they only have > one collection of devices behind them)? It has been rightly pointed out to me that my statement above is an inappropriate personal attack. While I did not intend to attack Mr. O'Hern personally, but merely a pithy reply in opposition of the idea of unnecessary user limitation, nonetheless, my words actually did. As such, they were inappropriate to this list and I apologize to Mr. O'Hern and to the list in general. Owen From charles at office.tcsn.net Wed Aug 11 19:20:38 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 11 Aug 2010 16:20:38 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> <863F03C1-BB01-4E18-9B04-E81C41ACB0BB@delong.com> <4C62FA68.50606@office.tcsn.net> Message-ID: <4C633046.4020202@office.tcsn.net> Owen DeLong wrote: > On Aug 11, 2010, at 12:30 PM, Charles O'Hern wrote: > > >> Owen DeLong wrote: >> >>> Then you lack imagination. Why not give a /48 (or more) per hot spot >>> and let the hotspots do DHCP-PD to devices that want to act as routers >>> giving them /56s (if they need multiple nets) or /64s (if they only have >>> one collection of devices behind them)? >>> >>> >>> >> That's a bit ad hominem... Lets just say that the intended purpose of a >> network is whatever my bosses tell me. My imagination is only exercised >> in the implementation. >> > > You are correct and I apologize. (And have done so publicly as well) > > Again, thank you, sir. > However, IPv6 is intended to facilitate innovative things like being able > to bring multiple devices in their own network on your person into a > public wireless environment and have one of the devices act as the > designated router for the rest of the network. Assigning /64s or worse > /128s in such an environment is harmful to that design and unnecessarily > limiting on the end users. > > I'm aiming at baby steps at this point, although I don't want to make any plan that prevents being able to implement this kind of functionality. My immediate purpose implementing IPv6 is imitation of the functions of the IPv4 network. Customer Premises Equipment connects at layer2, gets addresses (v4 and v6, CPE interface and any subnets assigned/routed to them), authenticates with us in some manner, and gets throughput to the 'world-at-large'. While I have started testing using FD00::/32 addresses, I know that i have a lot to learn. Imitation itself is probably a poor term, but a prime goal is transparent functionality to the EU. Your example is inspiring, and convinces me that I should have the address resources available for such uses, but I feel I need to keep my focus on the mundane here and now wherein I just need things to appear work as they have for years when the customer says 'go'. > > Yeah, Scott also pointed that out. I bet if we get a /36 policy in place, > the ACSP for getting the x-small boundary moved up to meet it would > be possible. I don't think that we want to facilitate ISPs going smaller > than /36, but, I agree we do need to facilitate smaller ISPs having > similar fees to their current structure. > > as I was still not seeing why you were pushing the /36 policy addition, until I read more. > Yep... The problem here is that the /32 is a remaining vestige of a day when > the IETF thought that they could allow router vendors and very large ISPs > to set addressing policy through the IETF process. > > If you look back on the history to proposal 2002-3, you'll see that I actually > pioneered the idea of the RIRs being able to tell the IETF to stuff it, go back > to protocol design and leave those that administer the addressing to the > policies thereof. > > ARIN is in a bit of a tough spot in that fewer ISPs will be coming back to the > well every year (which is actually a good thing for the internet), but, that means > ARIN has the same customer base facing in the vast majority of cases, > reduced fees and ARIN facing significantly reduced revenues while still > trying to operate many of the same functions for the community. > > With so many organizations that previously got allocations in larger > categories being able to fit in to a /32, it will make life interesting. > > So because many orgs which had larger-than-small allocations (and multiple allocations) of IPv4 fit into the Small IPv6 category, ARIN is drawing in less fees. To keep the books balanced they can't reduce the fee for the Small category. AH-HA This makes sense. > Nonetheless, I don't think that issue should be solved on the backs > of those least able to absorb sudden fee increases. Reducing the > price of a /32 would be too detrimental to ARIN (and by extension > the community that ARIN supports). I think that the majority of the > larger providers that can fit within a /32 will not choose to fit within > a /36 while smaller organizations can do so easily. > > I think it is also important where possible to avoid financial incentives > for bad addressing practices (such as making /36s so cheap that > they make it attractive to give end users /96s if that's what it takes > to cram all your addressing into a /36 no matter how large you are). > I'm not certain how ARIN can prevent bad addressing policies without intrusive audits. The best pressure IMO on the ISP practices will come from the EU's that pay them and the firmware implementations of the hardware vendors that sell their products to the same EU. This may be a bit out of the ballpark, but do we (anyone) have an idea if the soho cpe vendors will set their firmware to allow a subnet size smaller than /64? With our customer base we haven't yet been seeing soho devices with IPv6 capabilities to know how they are going to work. How do we make sure EU's know that they are supposed to get at least 18 billion billion addresses from their connection? If the EU's have it in their minds that they have a 'right' to a /64, or /48 or whatever, they will demand it of their ISP. *pauses to envision the torches and pitchforks* > I think that having a policy that allows an ISP with fewer than > 200 customers to obtain a /36 and realigning the x-small > fee boundary to /36 would solve that problem without undue > harm to ARIN revenues in the process. > > Owen > > (You are welcome to post this to the list, but, since you emailed me > privately, I will not post your email to the list without permission.) > Thank you sir. I think I will. Your points about the effects of IPv6 allocation on ARIN's financials are enlightening. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From michael.dillon at bt.com Thu Aug 12 05:40:57 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 12 Aug 2010 10:40:57 +0100 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C62E861.8090000@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423919D63024@EMV01-UKBR.domain1.systemhost.net> > I was simplifying a bit. About a third of our customers are dynamic > 802.11 hotspot customers. Since those are each single hosts, You've got to be joking. Have you never heard of tethering? This is where one device with a wireless connection, allows a second device to transport traffic over that connection. I did it back in 2000 with a Nokia mobile phone tethered to a Palm V over infrared to run a web browser and check my email at yahoo.com. Nowadays it is more often a 3G cellphone tethered via wifi to a netbook or iPad, but there are many variations, some of which involve so-called mifi where a wifi device acts as a router for a bunch of other devices. That means that many of your customers have 2 hosts and some of them have entire subnets connected. On IPv6 you should not give a wifi customer less than a /64, and it may even make sense to assign a /56 given the march of miniaturization and device proliferation. > I can't > foresee allocating more than a /64 per hotspot Even if you assign /64s to the customers on the hotspot, it still makes sense to allocate a /48 to the hotspot. Here is a rule of thumb. Write up your IPv6 addressing plan. Now look at each level of the aggregation hierarchy and ask yourself, "am I being wasteful?". If the answer is no, then you got it wrong and should increase the allocation size at that layer and probably all layers above it. If you don't do that you are just shooting yourself in the foot and will need to redo your network architecture in 3 years while your competitors are laughing at you because they understood the fundamental ACCORDION principle of IPv6 addressing. You have to be able to expand each level in the hierarchy without affecting higher or lower levels in the hierarchy. For instance, a customer signs up for Internet access for their laptop at home. You assign them a /48. You never hear from them again except to buy bigger bandwidth every do often and one day you are driving by and see that this customer now has a medical clinic with 10 people working there and a special radiology clinic with a scanner that sends multi gigabyte scans to the local hospital several times a day. You walk in and there are network connected devices everywhere. The TV in the waiting room is showing Hulu programs, the phones are all Cisco VoIP devices, the medical personnel are all carrying iPadv7 tablets and there are three closets full of cables and server racks which the chief doctor uses to serve up his lectures via the Open University on the Internet. And that /48 allocation still has space to spare. That is what IPv6 addressing is meant to bring us. --Michael Dillon From charles at office.tcsn.net Thu Aug 12 16:01:44 2010 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 12 Aug 2010 13:01:44 -0700 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <0F29D1BA57992E4CAB5AD2C9AE7B423919D63024@EMV01-UKBR.domain1.systemhost.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> <0F29D1BA57992E4CAB5AD2C9AE7B423919D63024@EMV01-UKBR.domain1.systemhost.net> Message-ID: <4C645328.4050004@office.tcsn.net> michael.dillon at bt.com wrote: >> I was simplifying a bit. About a third of our customers are dynamic >> 802.11 hotspot customers. Since those are each single hosts, >> > > You've got to be joking. I wasn't at the time, but have since become aware of how narrow my view and thought process have been. We are learning. > Have you never heard of tethering? This is > where one device with a wireless connection, allows a second device > to transport traffic over that connection. I did it back in 2000 > with a Nokia mobile phone tethered to a Palm V over infrared to run > a web browser and check my email at yahoo.com. Nowadays it is more > often a 3G cellphone tethered via wifi to a netbook or iPad, but > there are many variations, some of which involve so-called mifi > where a wifi device acts as a router for a bunch of other > devices. > > That means that many of your customers have 2 hosts and some > of them have entire subnets connected. On IPv6 you should not > give a wifi customer less than a /64, and it may even make sense > to assign a /56 given the march of miniaturization and device > proliferation. > > >> I can't >> foresee allocating more than a /64 per hotspot >> > > Even if you assign /64s to the customers on the hotspot, it still > makes sense to allocate a /48 to the hotspot. > > Here is a rule of thumb. Write up your IPv6 addressing plan. > Now look at each level of the aggregation hierarchy and ask > yourself, "am I being wasteful?". If the answer is no, then > you got it wrong and should increase the allocation size at > that layer and probably all layers above it. > I sat down this morning and tried this. Its quite difficult to overcome the ingrained habits that were natural to IPv4. It will be more difficult to convince the bosses to change their thinking. But we will be trying to do so. > If you don't do that you are just shooting yourself in the foot > and will need to redo your network architecture in 3 years > while your competitors are laughing at you because they understood > the fundamental ACCORDION principle of IPv6 addressing. You have to > be able to expand each level in the hierarchy without affecting > higher or lower levels in the hierarchy. > > For instance, a customer signs up for Internet access for their > laptop at home. You assign them a /48. You never hear from > them again except to buy bigger bandwidth every do often > we'll hear from them... guaranteed. But I see your point... they'll never have to request more addresses and/or renumber. (Unless we're on PA, of course) > and one day you are driving by and see that this > customer now has a medical clinic with 10 people working > there and a special radiology clinic with a scanner that > sends multi gigabyte scans to the local hospital several > times a day. You walk in and there are network connected > devices everywhere. The TV in the waiting room is showing > Hulu programs, the phones are all Cisco VoIP devices, > the medical personnel are all carrying iPadv7 tablets > and there are three closets full of cables and server racks > which the chief doctor uses to serve up his lectures > via the Open University on the Internet. And that /48 > allocation still has space to spare. > > Yes I can see this happening. > That is what IPv6 addressing is meant to bring us. > > --Michael Dillon > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From michael.dillon at bt.com Fri Aug 13 04:42:02 2010 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 13 Aug 2010 09:42:02 +0100 Subject: [arin-ppml] IPv6 Allocation Planning In-Reply-To: <4C645328.4050004@office.tcsn.net> References: <4C61AE89.2090509@office.tcsn.net> <4C61B6C5.6080103@gmail.com> <4C61C3D7.2090004@office.tcsn.net> <9242403D-539D-4646-B73F-0DBE18D39B6E@delong.com> <4C62E861.8090000@office.tcsn.net> <0F29D1BA57992E4CAB5AD2C9AE7B423919D63024@EMV01-UKBR.domain1.systemhost.net> <4C645328.4050004@office.tcsn.net> Message-ID: <0F29D1BA57992E4CAB5AD2C9AE7B423919D63539@EMV01-UKBR.domain1.systemhost.net> > I sat down this morning and tried this. Its quite difficult to > overcome > the ingrained habits that were natural to IPv4. It will be more > difficult to convince the bosses to change their thinking. But we will > be trying to do so. You said "bosses". That means that there will be three people at the meeting. Offer to bring coffee or coke or whatever for that meeting. Then take your one small coffee, or one can of coke, and three cups and carefully pour it out, not too fast, and if they say something to you wave them off and say it's important that you don't spill a drop because we can't afford to waste beverages. That's what you are doing when you try to not waste IPv6 addresses. In fact, there is no shortage of beverages, nor is there a shortage of IPv6 addresses. This so-called waste, is not waste, it is investment in painless future network expansion. Every part of the network has spare addresses so it can expand like an accordion. If you decide to focus on cloud services in one PoP, then that PoP already has enough address space to expand into a data center with 120 virtual machines on every 1U of rack space. This is why the designers of IPv6 did not just add a few bits to the 32-bit IPv4 address, they expanded it to 128 bits making it so outrageously huge that network designers could afford to completely ignore address conservation and concentrate on simple functional and expandable network architectures. --Michael Dillon From owen at delong.com Thu Aug 19 08:36:32 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Aug 2010 05:36:32 -0700 Subject: [arin-ppml] Latest version of 2010-13 Message-ID: <4374360C-B5A3-4C2B-B0A7-D783B7787534@delong.com> A number of edits to 2010-13 have been made as a result of community feedback. I am posting the most recent revision to PPML and welcome additional community feedback on the revised text. Owen Draft Policy: 2010-13: Permitted Uses of Space Reserved under 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.9 Date: 18 June 2010 Proposal type: modify Policy term: permanent Policy statement: Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" Amend section 4.10 replacing "When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment." with "When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will form a dedicated pool to facilitate IPv6 Deployment." and replacing "...when possible within that /10 block." with "...when possible within this pool, particularly within the last /8 block. Following IANA depletion, all IPv4 address space returned directly to ARIN except space to be reissued under an 8.3 directed transfer will be added to this pool." . and Strike "This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24." from section 4.10. Amend 4.10.1 replacing "...under this policy in the preceding..." with "...under each provision of this policy (as detailed in section 4.10.6) in the preceding..." Add the following to section 4.10 of the NRPM 6. Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /24 nor larger than a /18 to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 addresses with IPv6 connectivity to the ISP/LIR (must be dual-stacked). 6. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing customer for each /32 requested, up to 90% of their total customer base. 7. No organization shall receive more than a total of a /16 or equivalent under this section. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /22 to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may recieve more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The recieving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing server in addition to the server for which each /32 is requested, up to 100% of their total server base. (organizations which can show 100% dual stack are exempt from this requirement). 5. The recieving organization must enable all of their content on the following schedule: 25% of content IPv6 reachable within six months of receiving their first addresses under this policy 50% of content IPv6 reachable within one year of receiving their first addresses under this policy 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. No organization shall receive more than a total of a /14 or equivalent under this section. (c) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for purposes relevant to their ability to deploy IPv6 as specified in section 4.12. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. DNS64 or other transitional DNS enablers e. For other technologies of similar purpose and scope. (d) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for other transitional technologies not envisioned at the time of this proposal, but, in no case for general IPv4 addressing provided to customers. (e) A /10 from the final /8 shall be reserved for issuance under 4.10.6(c) and 4.10.6(d). In no case shall any addresses from this /10 be issued under 4.10.6(a) and 4.10.6(b). Add the following to section 4 of the NRPM 4.11 Required utilization for subsequent allocation under section 4.10 No organization shall receive more than one allocation or assignment under section 4.10 unless all prior space issued under 4.10 meets the utilization requirements of this section: 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. 2. All utilization must be permitted under section 4.10 3. All prior 4.10 allocation/assignments must be at least 90% utilized. 4. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. 4.12 Quarterly Utilization Monitoring Allocations and assignments under section 4.10 shall be subject to quarterly verification of utilization. 1. An organization which is not meeting their utilization targets may have their allocation or assignment reduced accordingly with the reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. 2. An organization which is using space received under 4.10 in a manner contrary to 4.10 et seq. may have their allocation or assignment reduced or revoked with reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. It also expands the scope of 4.10 to include more address space to be given out in manners that facilitate transition, but, are not directly transitional technologies per se. These allocatios and assignments require specific IPv6 deployment targets to be met and have much stricter limitations on the utilization of IPv4 addresses issued from this pool. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. From owen at delong.com Thu Aug 19 08:47:12 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 19 Aug 2010 05:47:12 -0700 Subject: [arin-ppml] Correction to 2010-13 Message-ID: The version sent out a few minutes ago contained an edit which was misapplied. 4.10.6(a) should be limited to /14. 4.10.6(b) should be limited to /16. The corrected text appears below: Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.9 Date: 18 June 2010 Proposal type: modify Policy term: permanent Policy statement: Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" Amend section 4.10 replacing "When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment." with "When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will form a dedicated pool to facilitate IPv6 Deployment." and replacing "...when possible within that /10 block." with "...when possible within this pool, particularly within the last /8 block. Following IANA depletion, all IPv4 address space returned directly to ARIN except space to be reissued under an 8.3 directed transfer will be added to this pool." . and Strike "This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24." from section 4.10. Amend 4.10.1 replacing "...under this policy in the preceding..." with "...under each provision of this policy (as detailed in section 4.10.6) in the preceding..." Add the following to section 4.10 of the NRPM 6. Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /24 nor larger than a /18 to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 addresses with IPv6 connectivity to the ISP/LIR (must be dual-stacked). 6. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing customer for each /32 requested, up to 90% of their total customer base. 7. No organization shall receive more than a total of a /14 or equivalent under this section. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /22 to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may recieve more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The recieving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing server in addition to the server for which each /32 is requested, up to 100% of their total server base. (organizations which can show 100% dual stack are exempt from this requirement). 5. The recieving organization must enable all of their content on the following schedule: 25% of content IPv6 reachable within six months of receiving their first addresses under this policy 50% of content IPv6 reachable within one year of receiving their first addresses under this policy 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. No organization shall receive more than a total of a /16 or equivalent under this section. (c) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for purposes relevant to their ability to deploy IPv6 as specified in section 4.12. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. DNS64 or other transitional DNS enablers e. For other technologies of similar purpose and scope. (d) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for other transitional technologies not envisioned at the time of this proposal, but, in no case for general IPv4 addressing provided to customers. (e) A /10 from the final /8 shall be reserved for issuance under 4.10.6(c) and 4.10.6(d). In no case shall any addresses from this /10 be issued under 4.10.6(a) and 4.10.6(b). Add the following to section 4 of the NRPM 4.11 Required utilization for subsequent allocation under section 4.10 No organization shall receive more than one allocation or assignment under section 4.10 unless all prior space issued under 4.10 meets the utilization requirements of this section: 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. 2. All utilization must be permitted under section 4.10 3. All prior 4.10 allocation/assignments must be at least 90% utilized. 4. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. 4.12 Quarterly Utilization Monitoring Allocations and assignments under section 4.10 shall be subject to quarterly verification of utilization. 1. An organization which is not meeting their utilization targets may have their allocation or assignment reduced accordingly with the reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. 2. An organization which is using space received under 4.10 in a manner contrary to 4.10 et seq. may have their allocation or assignment reduced or revoked with reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. It also expands the scope of 4.10 to include more address space to be given out in manners that facilitate transition, but, are not directly transitional technologies per se. These allocatios and assignments require specific IPv6 deployment targets to be met and have much stricter limitations on the utilization of IPv4 addresses issued from this pool. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at ipv6canada.com Thu Aug 19 19:53:01 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Thu, 19 Aug 2010 19:53:01 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program Message-ID: <4C6DC3DD.8060202@ipv6canada.com> This post is designed for -discuss, but I thought I'd get more exposure here. iiuc, The Fellowship Program has been extended until tomorrow, 2010-08-20 I learnt today that there has not been a *single* applicant for the program from within Canada. I must say that I am quite disappointed in my fellow citizens. There must be at least *one* company that has at least *one* staff member who is interested in going to the meeting _*all expenses paid*_, that wouldn't be able to afford it otherwise. I was the Canadian Fellow last year, and it was an experience that I will never forget. At first, I was hesitant to apply, as I am someone who does not like 'freebies'. However, I submitted, and got accepted. I'm not going to say that the company I work for likely won't finance a trip this year... but what I can say, is that if nobody else within Canada steps up, I'd gladly take the honour of being the Fellow again, and be humble about taking ARIN's generosity. Come on, there has to be other people who work for small orgs in Canada that have the same level of interest, and the same financial constraints as I do. Steve From steve at ipv6canada.com Thu Aug 19 20:45:10 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Thu, 19 Aug 2010 20:45:10 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: <4C6DC3DD.8060202@ipv6canada.com> References: <4C6DC3DD.8060202@ipv6canada.com> Message-ID: <4C6DD016.7010600@ipv6canada.com> On 2010.08.19 19:53, Steve Bertrand wrote: > This post is designed for -discuss, but I thought I'd get more exposure > here. > > iiuc, The Fellowship Program has been extended until tomorrow, 2010-08-20 > > I learnt today that there has not been a *single* applicant for the > program from within Canada. I must say that I am quite disappointed in > my fellow citizens. > > There must be at least *one* company that has at least *one* staff > member who is interested in going to the meeting _*all expenses paid*_, > that wouldn't be able to afford it otherwise. > > I was the Canadian Fellow last year, and it was an experience that I > will never forget. At first, I was hesitant to apply, as I am someone > who does not like 'freebies'. However, I submitted, and got accepted. > > I'm not going to say that the company I work for likely won't finance a > trip this year... but what I can say, is that if nobody else within > Canada steps up, I'd gladly take the honour of being the Fellow again, > and be humble about taking ARIN's generosity. > > Come on, there has to be other people who work for small orgs in Canada > that have the same level of interest, and the same financial constraints > as I do. Note: I've had a couple people mail me off-list, and I want to clarify: The objective of the Fellowship Program is to provide an opportunity for ARIN members who: - have not previously been to an ARIN meeting - is an individual, or an employee of a company that otherwise wouldn't be able to afford the travel expenses otherwise - entice members who actively participate to step up to the plate, and provide them an opportunity to meet face-to-face their fellow industry colleagues (be that ops, legal, pr, senior execs, whatever) I *know* that the Fellowship Program is for 'First Timers', and hence, I wouldn't accept it again even if it were offered to me. My comment in my OP was just that... a comment ;) I truly felt like I was 'begging' when I applied, but after it was all said and done and I was on my way back home, I did not regret a thing. Apply Canadians, seriously. In less than four days, I met some of the most intelligent, loyal, trustworthy people within our industry. Even ARIN staff is willing to mingle. Before the ARIN meeting, the only opportunity to meet with a CEO/President and the Chair of the Board was in a serious, stressful meeting. Not with ARIN... Steve ps. ffs, damn me and my trying to save ARIN money by sending me to Toronto. I should have saved my application for this: https://www.arin.net/participate/meetings/ARIN-XXVII/index.html From steve at ipv6canada.com Thu Aug 19 21:21:41 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Thu, 19 Aug 2010 21:21:41 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: <4C6DC3DD.8060202@ipv6canada.com> References: <4C6DC3DD.8060202@ipv6canada.com> Message-ID: <4C6DD8A5.9000904@ipv6canada.com> On 2010.08.19 19:53, Steve Bertrand wrote: > This post is designed for -discuss, but I thought I'd get more exposure > here. I apologize for repeatedly responding to myself, but it's the only medium I have to reply to numerous off-list questions in one fell-swoop, while I get caught up with other issues. This'll be the last post... Being a person from a small org that doesn't get much exposure to the big world, I know: a) people in Canada that are going to Atlanta b) people in Canada who don't give a rats ass about IP addressing, IPv6, or anything of the like. Hence, I truthfully and regrettably don't have anybody that I would *personally* recommend for this wonderful opportunity. Even my colleagues, as in-tune and awesome as they are for what they do, just wouldn't fit the bill. Nobody I know has the interest... Steve From mcr at sandelman.ca Fri Aug 20 10:58:30 2010 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 20 Aug 2010 10:58:30 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: <4C6DC3DD.8060202@ipv6canada.com> References: <4C6DC3DD.8060202@ipv6canada.com> Message-ID: <7304.1282316310@marajade.sandelman.ca> >>>>> "Steve" == Steve Bertrand writes: Steve> This post is designed for -discuss, but I thought I'd get Steve> more exposure here. Steve> iiuc, The Fellowship Program has been extended until Steve> tomorrow, 2010-08-20 Steve> I learnt today that there has not been a *single* applicant Steve> for the program from within Canada. I must say that I am Steve> quite disappointed in my fellow citizens. But, maybe there just isn't anyone who: 1) have not previously been to an ARIN meeting 2) is an individual, or an employee of a company that otherwise wouldn't be able to afford the travel expenses otherwise 3) is actively involved. As far as I can tell, you'd have to be a relatively young person (<35) such that you'd not worked anywhere during the .com boom days, and you'd have to be working for a small company. While in 1990, when I started building ISPs, everyone doing so was ~23... I don't think that there are many people starting new ISPs today. Steve> There must be at least *one* company that has at least *one* Steve> staff member who is interested in going to the meeting _*all Steve> expenses paid*_, that wouldn't be able to afford it Steve> otherwise. I'll forward your message to some people. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mnaser at vexxhost.com Fri Aug 20 11:16:09 2010 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 20 Aug 2010 11:16:09 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: <7304.1282316310@marajade.sandelman.ca> References: <4C6DC3DD.8060202@ipv6canada.com> <7304.1282316310@marajade.sandelman.ca> Message-ID: Hello everyone, I live in Canada. I am currently a student studying and operating a full web hosting company at the moment. I started as small as leasing a server and now I have grown to have operated my own full BGP network and my 2 own /22's.. In 4 years. In the process, I learned everything on my own, did all ARIN applications, etc. I found out about the fellowship program today, can I still register or is it too late? I am greatly interested in bringing my hosting services to the IPv6 platform. Please let me know. Regards, Mohammed On Fri, Aug 20, 2010 at 10:58 AM, Michael Richardson wrote: > > >>>>> "Steve" == Steve Bertrand writes: > Steve> This post is designed for -discuss, but I thought I'd get > Steve> more exposure here. > > Steve> iiuc, The Fellowship Program has been extended until > Steve> tomorrow, 2010-08-20 > > Steve> I learnt today that there has not been a *single* applicant > Steve> for the program from within Canada. I must say that I am > Steve> quite disappointed in my fellow citizens. > > But, maybe there just isn't anyone who: > > 1) have not previously been to an ARIN meeting > 2) is an individual, or an employee of a company that otherwise wouldn't > be able to afford the travel expenses otherwise > 3) is actively involved. > > As far as I can tell, you'd have to be a relatively young person (<35) > such that you'd not worked anywhere during the .com boom days, and you'd > have to be working for a small company. While in 1990, when I started > building ISPs, everyone doing so was ~23... I don't think that there are > many people starting new ISPs today. > > Steve> There must be at least *one* company that has at least *one* > Steve> staff member who is interested in going to the meeting _*all > Steve> expenses paid*_, that wouldn't be able to afford it > Steve> otherwise. > > I'll forward your message to some people. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at telnetcommunications.com Fri Aug 20 12:08:15 2010 From: bill at telnetcommunications.com (Bill Sandiford) Date: Fri, 20 Aug 2010 12:08:15 -0400 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: References: <4C6DC3DD.8060202@ipv6canada.com> <7304.1282316310@marajade.sandelman.ca> Message-ID: <654C2189-081F-4469-ACAC-1459DA065D0C@telnetcommunications.com> It is my belief that the application deadline was extended until today. Bill Sent from iPad On 2010-08-20, at 11:13 AM, "Mohammed Naser" > wrote: Hello everyone, I live in Canada. I am currently a student studying and operating a full web hosting company at the moment. I started as small as leasing a server and now I have grown to have operated my own full BGP network and my 2 own /22's.. In 4 years. In the process, I learned everything on my own, did all ARIN applications, etc. I found out about the fellowship program today, can I still register or is it too late? I am greatly interested in bringing my hosting services to the IPv6 platform. Please let me know. Regards, Mohammed On Fri, Aug 20, 2010 at 10:58 AM, Michael Richardson <mcr at sandelman.ca> wrote: >>>>> "Steve" == Steve Bertrand <steve at ipv6canada.com> writes: Steve> This post is designed for -discuss, but I thought I'd get Steve> more exposure here. Steve> iiuc, The Fellowship Program has been extended until Steve> tomorrow, 2010-08-20 Steve> I learnt today that there has not been a *single* applicant Steve> for the program from within Canada. I must say that I am Steve> quite disappointed in my fellow citizens. But, maybe there just isn't anyone who: 1) have not previously been to an ARIN meeting 2) is an individual, or an employee of a company that otherwise wouldn't be able to afford the travel expenses otherwise 3) is actively involved. As far as I can tell, you'd have to be a relatively young person (<35) such that you'd not worked anywhere during the .com boom days, and you'd have to be working for a small company. While in 1990, when I started building ISPs, everyone doing so was ~23... I don't think that there are many people starting new ISPs today. Steve> There must be at least *one* company that has at least *one* Steve> staff member who is interested in going to the meeting _*all Steve> expenses paid*_, that wouldn't be able to afford it Steve> otherwise. I'll forward your message to some people. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the petition. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From packetgrrl at gmail.com Fri Aug 20 12:09:29 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 20 Aug 2010 10:09:29 -0600 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: <654C2189-081F-4469-ACAC-1459DA065D0C@telnetcommunications.com> References: <4C6DC3DD.8060202@ipv6canada.com> <7304.1282316310@marajade.sandelman.ca> <654C2189-081F-4469-ACAC-1459DA065D0C@telnetcommunications.com> Message-ID: Yes it has the URL is here https://www.arin.net/participate/meetings/fellowship.html#calendar On Fri, Aug 20, 2010 at 10:08 AM, Bill Sandiford < bill at telnetcommunications.com> wrote: > It is my belief that the application deadline was extended until today. > > Bill > > Sent from iPad > > > On 2010-08-20, at 11:13 AM, "Mohammed Naser" wrote: > > Hello everyone, > > I live in Canada. > > I am currently a student studying and operating a full web hosting company > at the moment. I started as small as leasing a server and now I have grown > to have operated my own full BGP network and my 2 own /22's.. In 4 years. > > In the process, I learned everything on my own, did all ARIN applications, > etc. > > I found out about the fellowship program today, can I still register or is > it too late? > > I am greatly interested in bringing my hosting services to the IPv6 > platform. > > Please let me know. > > Regards, > Mohammed > > On Fri, Aug 20, 2010 at 10:58 AM, Michael Richardson < > mcr at sandelman.ca> wrote: > >> >> >>>>> "Steve" == Steve Bertrand < >> steve at ipv6canada.com> writes: >> Steve> This post is designed for -discuss, but I thought I'd get >> Steve> more exposure here. >> >> Steve> iiuc, The Fellowship Program has been extended until >> Steve> tomorrow, 2010-08-20 >> >> Steve> I learnt today that there has not been a *single* applicant >> Steve> for the program from within Canada. I must say that I am >> Steve> quite disappointed in my fellow citizens. >> >> But, maybe there just isn't anyone who: >> >> 1) have not previously been to an ARIN meeting >> 2) is an individual, or an employee of a company that otherwise wouldn't >> be able to afford the travel expenses otherwise >> 3) is actively involved. >> >> As far as I can tell, you'd have to be a relatively young person (<35) >> such that you'd not worked anywhere during the .com boom days, and you'd >> have to be working for a small company. While in 1990, when I started >> building ISPs, everyone doing so was ~23... I don't think that there are >> many people starting new ISPs today. >> >> Steve> There must be at least *one* company that has at least *one* >> Steve> staff member who is interested in going to the meeting _*all >> Steve> expenses paid*_, that wouldn't be able to afford it >> Steve> otherwise. >> >> I'll forward your message to some people. >> >> -- >> ] He who is tired of Weird Al is tired of life! | >> firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >> architect[ >> ] mcr at sandelman.ottawa.on.ca >> http://www.sandelman.ottawa.on.ca/|device driver[ >> Kyoto Plus: watch the video < >> http://www.youtube.com/watch?v=kzx1ycLXQSE> >> then sign the petition. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( >> ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Fri Aug 20 12:13:08 2010 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 20 Aug 2010 16:13:08 +0000 Subject: [arin-ppml] Atlanta meeting -- Fellowship Program In-Reply-To: References: <4C6DC3DD.8060202@ipv6canada.com><7304.1282316310@marajade.sandelman.ca><654C2189-081F-4469-ACAC-1459DA065D0C@telnetcommunications.com> Message-ID: <1895366636-1282320790-cardhu_decombobulator_blackberry.rim.net-1107109779-@bda895.bisx.prod.on.blackberry> Thanks everyone. I submitted my application :) Regards, Mohammed Naser Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: "cja at daydream.com" Date: Fri, 20 Aug 2010 10:09:29 To: Bill Sandiford Reply-To: cja at daydream.com Cc: Mohammed Naser; arin-ppml at arin.net Subject: Re: [arin-ppml] Atlanta meeting -- Fellowship Program Yes it has the URL is here https://www.arin.net/participate/meetings/fellowship.html#calendar On Fri, Aug 20, 2010 at 10:08 AM, Bill Sandiford < bill at telnetcommunications.com> wrote: > It is my belief that the application deadline was extended until today. > > Bill > > Sent from iPad > > > On 2010-08-20, at 11:13 AM, "Mohammed Naser" wrote: > > Hello everyone, > > I live in Canada. > > I am currently a student studying and operating a full web hosting company > at the moment. I started as small as leasing a server and now I have grown > to have operated my own full BGP network and my 2 own /22's.. In 4 years. > > In the process, I learned everything on my own, did all ARIN applications, > etc. > > I found out about the fellowship program today, can I still register or is > it too late? > > I am greatly interested in bringing my hosting services to the IPv6 > platform. > > Please let me know. > > Regards, > Mohammed > > On Fri, Aug 20, 2010 at 10:58 AM, Michael Richardson < > mcr at sandelman.ca> wrote: > >> >> >>>>> "Steve" == Steve Bertrand < >> steve at ipv6canada.com> writes: >> Steve> This post is designed for -discuss, but I thought I'd get >> Steve> more exposure here. >> >> Steve> iiuc, The Fellowship Program has been extended until >> Steve> tomorrow, 2010-08-20 >> >> Steve> I learnt today that there has not been a *single* applicant >> Steve> for the program from within Canada. I must say that I am >> Steve> quite disappointed in my fellow citizens. >> >> But, maybe there just isn't anyone who: >> >> 1) have not previously been to an ARIN meeting >> 2) is an individual, or an employee of a company that otherwise wouldn't >> be able to afford the travel expenses otherwise >> 3) is actively involved. >> >> As far as I can tell, you'd have to be a relatively young person (<35) >> such that you'd not worked anywhere during the .com boom days, and you'd >> have to be working for a small company. While in 1990, when I started >> building ISPs, everyone doing so was ~23... I don't think that there are >> many people starting new ISPs today. >> >> Steve> There must be at least *one* company that has at least *one* >> Steve> staff member who is interested in going to the meeting _*all >> Steve> expenses paid*_, that wouldn't be able to afford it >> Steve> otherwise. >> >> I'll forward your message to some people. >> >> -- >> ] He who is tired of Weird Al is tired of life! | >> firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >> architect[ >> ] mcr at sandelman.ottawa.on.ca >> http://www.sandelman.ottawa.on.ca/|device driver[ >> Kyoto Plus: watch the video < >> http://www.youtube.com/watch?v=kzx1ycLXQSE> >> then sign the petition. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( >> ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Aug 20 16:07:58 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 20 Aug 2010 15:07:58 -0500 Subject: [arin-ppml] Critical Infrastructure post run-out Message-ID: <4C6EE09E.4030003@umn.edu> APNIC has been discussing prop-085: Eligibility for critical infrastructure assignments from the final /8, on their policy list in preparation for APNIC 30 next week. The policy deals with some side effects of how APNIC's last /8 policy is implemented, ARIN doesn't have the same specific issue. http://www.apnic.net/policy/proposals/prop-085 However, thinking about it, we do have the same general issue, what happens to Critical Infrastructure and Exchange Points after IANA and ARIN IPv4 run-out. I read Owen's update for 2010-13, one way to go might to include Critical Infrastructure and Exchange Point in it allowing for CI and EPs to get IPv4 from those resources, if and only if they are supporting IPv6. Another way to go could be to reserved a small pool for CI and EP long-term. I believe the burn rate for CI and EP is pretty low, so a reserving something like a /16 for CI and EP would probably last a fairly long time, and might be prudent. Currently there is a little less than the equivalent of /16 of IPv4 CI, and just over a the equivalent of /18 for EP space. https://www.arin.net/knowledge/micro_allocations.html So if we reserved another /16 for CI and EP, that is close to double what is there now, I would hope that should last more than a little while. But, I think I like the idea of allowing CI and EP out of a last /8 transition block of 2010-13 best. That way we could require that they are also doing IPv6, and by allowing it out of that block it might be able to have a smaller minimum allocation size too. I believe the primary reason for the /24 minimum allocation size in CI and EP is /24 route filtering, If we end up with a smaller minimum allocation size for the last /8 then a lot of CI could be done with a better address usage efficiency. Or maybe we do both; Thoughts. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Fri Aug 20 17:12:52 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 20 Aug 2010 14:12:52 -0700 Subject: [arin-ppml] Critical Infrastructure post run-out In-Reply-To: <4C6EE09E.4030003@umn.edu> References: <4C6EE09E.4030003@umn.edu> Message-ID: 2010-13 has been revised to accommodate this as follows: Specifically, I refer you to 4.10.6(f) below... Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.10 Proposal Originator: Owen DeLong Proposal Version: 1.29 Date: 18 June 2010 Proposal type: modify Policy term: permanent Policy statement: Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" Amend section 4.10 replacing "When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment." with "When ARIN receives its last /8 IPv4 allocation from IANA, that /8 will form a dedicated pool to facilitate IPv6 Deployment." and replacing "...when possible within that /10 block." with "...when possible within this pool, particularly within the last /8 block. Following IANA depletion, all IPv4 address space returned directly to ARIN except space to be reissued under an 8.3 directed transfer will be added to this pool." . and Strike "This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24." from section 4.10. Amend 4.10.1 replacing "...under this policy in the preceding..." with "...under each provision of this policy (as detailed in section 4.10.6) in the preceding..." Add the following to section 4.10 of the NRPM 6. Specific types of transitional uses have specific requirements: (a) An ISP/LIR may request a block no smaller than a /24 nor larger than a /18 to be used to provide single IPv4 /32s to their customers which could justify a /28 or more of IPv4 under ARIN policies in effect at the time of IANA depletion. 1. No customer may receive more than a single IPv4 /32 under this provision. 2. The customer must not have any other IPv4 allocations or assignments from the provider at the time of this assignment. 3. The customer must not have any direct assignments from ARIN at the time of this assignment. 4. The customer must not have more than a single IPv4 /32 from any other provider at the time of this assignment. 5. The customer must have IPv6 addresses with IPv6 connectivity to the ISP/LIR (must be dual-stacked). 6. The ISP/LIR must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing customer for each /32 requested, up to 90% of their total customer base. 7. No organization shall receive more than a total of a /14 or equivalent under this section. (b) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /22 to provide single IPv4 /32s to each physical server used to provide Internet reachable content. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. No server may recieve more than a single IPv4 /32 under this provision. 3. The server must have IPv6 addresses with IPv6 connectivity (must be dual-stacked). 4. The recieving organization must demonstrate that it already provides IPv6 addressing and connectivity to at least one existing server in addition to the server for which each /32 is requested, up to 100% of their total server base. (organizations which can show 100% dual stack are exempt from this requirement). 5. The recieving organization must enable all of their content on the following schedule: 25% of content IPv6 reachable within six months of receiving their first addresses under this policy 50% of content IPv6 reachable within one year of receiving their first addresses under this policy 75% of content IPv6 reachable within 18 months of receiving their first addresses under this policy 90% of content IPv6 reachable within 24 months of receiving their first addresses under this policy 6. No organization shall receive more than a total of a /16 or equivalent under this section. (c) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for purposes relevant to their ability to deploy IPv6 as specified in section 4.12. 1. Space issued under this provision is an assignment, not an allocation. An LIR may not distribute this space to their customers. 2. Space issued under this provision must be used to provide the required public IPv4 address(es) for transitional technologies operated by the recipient organization. Specific examples of permitted uses are: a. Large scale or "Carrier Grade" NAT b. NAT-PT c. DS-LITE/B4/AFTeR d. DNS64 or other transitional DNS enablers e. For other technologies of similar purpose and scope. (d) An ISP/LIR or End user organization may request a block no smaller than a /28 and no larger than a /24 for other transitional technologies not envisioned at the time of this proposal, but, in no case for general IPv4 addressing provided to customers. (e) A /10 from the final /8 shall be reserved for issuance under 4.10.6(c) and 4.10.6(d). In no case shall any addresses from this /10 be issued under 4.10.6(a) and 4.10.6(b). (f) Applications which would qualify for IPv4 under section 4.4 of the NRPM (critical infrastructure) may qualify for IPv4 space under this policy if they meet the following criteria: 1. The critical infrastructure to be numbered must also have IPv6 addresses and must provide all services provided on IPv4 over IPv6 on the same time table. 2. Assignments under this provision shall be the smallest technically feasible size for the critical infrastructure in question. 3. The total space assigned under this provision shall not exceed the equivalent of a /14. Add the following to section 4 of the NRPM 4.11 Required utilization for subsequent allocation under section 4.10 No organization shall receive more than one allocation or assignment under section 4.10 unless all prior space issued under 4.10 meets the utilization requirements of this section: 1. The most recent 4.10 allocation/assignment must be at least 80% utilized. 2. All utilization must be permitted under section 4.10 3. All prior 4.10 allocation/assignments must be at least 90% utilized. 4. For purposes of this computation, space received under each provision shall be considered separately if an organization has received resources through multiple provisions. 4.12 Quarterly Utilization Monitoring Allocations and assignments under section 4.10 shall be subject to quarterly verification of utilization. 1. An organization which is not meeting their utilization targets may have their allocation or assignment reduced accordingly with the reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. 2. An organization which is using space received under 4.10 in a manner contrary to 4.10 et seq. may have their allocation or assignment reduced or revoked with reclaimed portions going back to ARIN for distribution to other organizations. Space reclaimed in this manner shall be exempt from any requirement to return space to the IANA. Rationale: The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies. It also expands the scope of 4.10 to include more address space to be given out in manners that facilitate transition, but, are not directly transitional technologies per se. These allocatios and assignments require specific IPv6 deployment targets to be met and have much stricter limitations on the utilization of IPv4 addresses issued from this pool. Timetable for implementation: immediate For reference, here is the current text of 4.10 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Aug 20 17:25:14 2010 From: farmer at umn.edu (David Farmer) Date: Fri, 20 Aug 2010 16:25:14 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria Message-ID: <4C6EF2BA.207@umn.edu> The following is a major rewrite of 2010-8: Rework of IPv6 assignment criteria, based on input received at the last ARIN meeting and other discussions; I'm interested in feedback Thanks ------------- 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1 Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network consisting of a total of 1000 or more hosts, or; d. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: ? An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc? ? Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 1000 or more individuals either internal or external to the organization. ? An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). ? An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. 6.5.8.2. Initial assignment size Organizations that meet at least one of the initial assignment criteria above are eligible to receive a minimum assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites and the number of subnets needed to support a site. Organizations may request up to a /48 for each site in their network. If an organization elects for smaller prefixes for some sites, these will be aggregated into an equivalent number of whole /48 prefixes. In the rare case where more than a /48 is justified for an individual site, ARIN will evaluate such requests using the 0.94 HD-Ratio metric of the number of /64 subnets to determine a justified number of equivalent /48 prefixes. Example: it is necessary to justify 33,689 subnets to receive a second /48 for an individual site. The overall initial assignment size will be rounded up to the next nibble boundary using the following table, based on the number of /48 equivalents justified above: One and only one /48 equivalent justified, receives a /48 initial assignment; More than 1 but less than or equal to 10 /48 equivalents justified, receives a /44 initial assignment; More than 10 but less than or equal to 100 /48 equivalents justified, receives a /40 initial assignment; More than 100 but less than or equal to 1,500 /48 equivalents justified, receives a /36 initial assignment; More than 1,500 /48 equivalents justified, receives a /32 initial assignment or larger. In cases where more than 1,500 /48 equivalents are justified an initial assignment of /32 will be made, unless a larger initial assignment is justified using the 0.94 HD-Ratio of the number of /48 equivalents rounded up to the next nibble boundary. Each initial assignment, up to at least /40, will receive a reservation for growth of at least the next nibble boundary beyond the initial assignment. Such reservations are not guaranteed and ARIN, in its sole discretion, may assign them to other organizations at any time. ARIN, in its sole discretion, may make larger reservation based on an organization?s growth projections. 6.5.8.3 Subsequent assignments For organizations with a /48 assignment, a subsequent assignment is justified when the utilization of 33,689 /64 subnets can be demonstrated for a single site, or when additional sties are added to an organization?s network. For organizations with larger assignments, a subsequent assignment is justified when the 0.94 HD-Ratio of the number of /48 equivalents is exceeded: For an assignment of /44, a utilization of 14 or more /48 equivalents is necessary to justify a subsequent assignment; For an assignment of /40, a utilization of 184 or more /48 equivalents is necessary to justify a subsequent assignment; For an assignment of /36, a utilization of 2487 or more /48 equivalents is necessary to justify a subsequent assignment. When possible, subsequent assignments will be made from contiguous adjacent address blocks. If the current assignment is within an available contiguous reservation, then the new assignment will be made from within the reservation with the total assignment sized at the next nibble boundary. If a contiguous reservation is not available, then a separate new assignment sized at the next nibble boundary will be made. When a new non-contiguous assignment is made, ARIN, in its sole discretion, may make a reservation for growth of at least the next nibble boundary. Such reservations are not guaranteed and ARIN, in its sole discretion, may assign them to other organizations at any time. Rationale: This proposal provides a complete rework of the IPv6 end-user assignment criteria, removing the dependency on IPv4 policy, and providing clear guidance in requesting larger initial assignments. The following general concepts are included: ? Previously justified IPv4 resources may be used to justify the need for IPv6 resources. ? Internet multihoming is sufficient justification for an ipv6 end-user assignment in and of itself. ? Other end-users must justify why an ISP or LIR assignment is not sufficient for their needs. ? Organizations with multiple sites are allowed to request a /48 for each site. ? Providing a sufficiently large initial assignments and reservations will reduce route table growth caused by subsequent assignments. ? While HD-Ratio is not eliminated, it is not necessary for most end-users to understand the details of the HD-Ratio. From rbf+arin-ppml at panix.com Sat Aug 21 13:09:27 2010 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Sat, 21 Aug 2010 12:09:27 -0500 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C6EF2BA.207@umn.edu> References: <4C6EF2BA.207@umn.edu> Message-ID: <20100821170927.GA15061@panix.com> On Fri, Aug 20, 2010 at 04:25:14PM -0500, David Farmer wrote: > The following is a major rewrite of 2010-8: Rework of IPv6 assignment > criteria, based on input received at the last ARIN meeting and other > discussions; I'm interested in feedback What is the definition of site? Any building/campus in the network? For example, is every large (1501 stores or more) retail company in the ARIN region entitled to a /32? They'd all meet requirement 6.5.8.1(c) below; most or all would meet 6.5.8.1(a), so that gets them in the door for an IPv6 assignmnet of some size. Then, if they have at least 1501 stores, is each one a site. for the purposes of entitling them to a /48 for each? (Obviosuly they don't need that and might not request that. But if they did, the policy below would seem to allow it. Assuming they're allowed to define each store as a site.) This isn't necessarily a problem -- IPv6 space isn't scarce the way IPv4 is -- I'm just asking what you intended the definition of "site" to be. > ------------- [ Lot sof snippage in what follows ] > 6.5.8. Direct assignments from ARIN to end-user organizations > > 6.5.8.1 Criteria > > a. Having a previously justified IPv4 end-user assignment from ARIN or > one of its predecessor registries, or; > > c. By having a network consisting of a total of 1000 or more hosts, or; > > 6.5.8.2. Initial assignment size > > Organizations that meet at least one of the initial assignment criteria > above are eligible to receive a minimum assignment of /48. Requests for > larger initial assignments, reasonably justified with supporting > documentation, will be evaluated based on the number of sites and the > number of subnets needed to support a site. > > Organizations may request up to a /48 for each site in their network. If > an organization elects for smaller prefixes for some sites, these will > be aggregated into an equivalent number of whole /48 prefixes. > > One and only one /48 equivalent justified, receives a /48 initial > assignment; > More than 1 but less than or equal to 10 /48 equivalents justified, > receives a /44 initial assignment; > More than 10 but less than or equal to 100 /48 equivalents justified, > receives a /40 initial assignment; > More than 100 but less than or equal to 1,500 /48 equivalents justified, > receives a /36 initial assignment; > More than 1,500 /48 equivalents justified, receives a /32 initial > assignment or larger. -- Brett From joelja at bogus.com Sat Aug 21 14:43:45 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 21 Aug 2010 11:43:45 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <20100821170927.GA15061@panix.com> References: <4C6EF2BA.207@umn.edu> <20100821170927.GA15061@panix.com> Message-ID: <4C701E61.1020908@bogus.com> On 8/21/10 10:09 AM, Brett Frankenberger wrote: > On Fri, Aug 20, 2010 at 04:25:14PM -0500, David Farmer wrote: >> The following is a major rewrite of 2010-8: Rework of IPv6 assignment >> criteria, based on input received at the last ARIN meeting and other >> discussions; I'm interested in feedback > > What is the definition of site? Any building/campus in the network? > > For example, is every large (1501 stores or more) retail company in the > ARIN region entitled to a /32? A company like (sorry I'm just picking an entity with a fairly large ip network and a lot of retail outlets) office depot may well consider itslef an LIR in ipv6 and might therefore not apply under 6.5.8 at all e.g. 6.5.1... Although the direct assignment policy had not been estalished in 2001, nokia certainly considered itself an LIR for the purposes of it's /32 allocation. > They'd all meet requirement 6.5.8.1(c) > below; most or all would meet 6.5.8.1(a), so that gets them in the door > for an IPv6 assignmnet of some size. Then, if they have at least 1501 > stores, is each one a site. for the purposes of entitling them to a /48 > for each? (Obviosuly they don't need that and might not request that. > But if they did, the policy below would seem to allow it. Assuming > they're allowed to define each store as a site.) > > This isn't necessarily a problem -- IPv6 space isn't scarce the way > IPv4 is -- I'm just asking what you intended the definition of "site" > to be. > >> ------------- > > [ Lot sof snippage in what follows ] > >> 6.5.8. Direct assignments from ARIN to end-user organizations >> >> 6.5.8.1 Criteria >> >> a. Having a previously justified IPv4 end-user assignment from ARIN or >> one of its predecessor registries, or; >> >> c. By having a network consisting of a total of 1000 or more hosts, or; >> >> 6.5.8.2. Initial assignment size >> >> Organizations that meet at least one of the initial assignment criteria >> above are eligible to receive a minimum assignment of /48. Requests for >> larger initial assignments, reasonably justified with supporting >> documentation, will be evaluated based on the number of sites and the >> number of subnets needed to support a site. >> >> Organizations may request up to a /48 for each site in their network. If >> an organization elects for smaller prefixes for some sites, these will >> be aggregated into an equivalent number of whole /48 prefixes. >> >> One and only one /48 equivalent justified, receives a /48 initial >> assignment; >> More than 1 but less than or equal to 10 /48 equivalents justified, >> receives a /44 initial assignment; >> More than 10 but less than or equal to 100 /48 equivalents justified, >> receives a /40 initial assignment; >> More than 100 but less than or equal to 1,500 /48 equivalents justified, >> receives a /36 initial assignment; >> More than 1,500 /48 equivalents justified, receives a /32 initial >> assignment or larger. > > -- Brett > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Sat Aug 21 17:09:05 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 21 Aug 2010 14:09:05 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <20100821170927.GA15061@panix.com> References: <4C6EF2BA.207@umn.edu> <20100821170927.GA15061@panix.com> Message-ID: <762B68EF-BD15-400E-AEEC-A3403E632C27@delong.com> Sent from my iPad On Aug 21, 2010, at 10:09 AM, Brett Frankenberger wrote: > On Fri, Aug 20, 2010 at 04:25:14PM -0500, David Farmer wrote: >> The following is a major rewrite of 2010-8: Rework of IPv6 assignment >> criteria, based on input received at the last ARIN meeting and other >> discussions; I'm interested in feedback > > What is the definition of site? Any building/campus in the network? > I think that is as good a definition as any. > For example, is every large (1501 stores or more) retail company in the > ARIN region entitled to a /32? They'd all meet requirement 6.5.8.1(c) > below; most or all would meet 6.5.8.1(a), so that gets them in the door > for an IPv6 assignmnet of some size. Then, if they have at least 1501 > stores, is each one a site. for the purposes of entitling them to a /48 > for each? (Obviosuly they don't need that and might not request that. > But if they did, the policy below would seem to allow it. Assuming > they're allowed to define each store as a site.) > I'm not sure they should get a /32 for 1501 sites, but giving each site a /48 makes a lot of sense to me. The current numbers in the proposal are based on 0.94 HD ratio. I am not convinced that is the right metric, but I'm not convinced it is wrong. > This isn't necessarily a problem -- IPv6 space isn't scarce the way > IPv4 is -- I'm just asking what you intended the definition of "site" > to be. > Correct. It is definitely not a problem. My tendency would be to lean towards a next nibble boundary if you use enough /48s for 3/4 of the lower one. E.g. 12 sites would get a /40 instead of a /44, 192 to get a /36, etc. Numbering every building on the planet like this, twice, would still barely make a perceptible dent in IPv6 address space. Owen >> ------------- > > [ Lot sof snippage in what follows ] > >> 6.5.8. Direct assignments from ARIN to end-user organizations >> >> 6.5.8.1 Criteria >> >> a. Having a previously justified IPv4 end-user assignment from ARIN or >> one of its predecessor registries, or; >> >> c. By having a network consisting of a total of 1000 or more hosts, or; >> >> 6.5.8.2. Initial assignment size >> >> Organizations that meet at least one of the initial assignment criteria >> above are eligible to receive a minimum assignment of /48. Requests for >> larger initial assignments, reasonably justified with supporting >> documentation, will be evaluated based on the number of sites and the >> number of subnets needed to support a site. >> >> Organizations may request up to a /48 for each site in their network. If >> an organization elects for smaller prefixes for some sites, these will >> be aggregated into an equivalent number of whole /48 prefixes. >> >> One and only one /48 equivalent justified, receives a /48 initial >> assignment; >> More than 1 but less than or equal to 10 /48 equivalents justified, >> receives a /44 initial assignment; >> More than 10 but less than or equal to 100 /48 equivalents justified, >> receives a /40 initial assignment; >> More than 100 but less than or equal to 1,500 /48 equivalents justified, >> receives a /36 initial assignment; >> More than 1,500 /48 equivalents justified, receives a /32 initial >> assignment or larger. > > -- Brett > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From terry.l.davis at boeing.com Tue Aug 24 12:46:13 2010 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Tue, 24 Aug 2010 09:46:13 -0700 Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria In-Reply-To: <4C6EF2BA.207@umn.edu> References: <4C6EF2BA.207@umn.edu> Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516E41BB4@XCH-NW-05V.nw.nos.boeing.com> David Excellent! I support this and was very glad to see that it also acknowledges the needs of critical infrastructure and critical service providers. I believe this change would also help accelerate IPv6 rollout. Take care Terry > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Friday, August 20, 2010 2:25 PM > To: 'arin-ppml at arin.net' > Subject: [arin-ppml] 2010-8: Rework of IPv6 assignment criteria > > The following is a major rewrite of 2010-8: Rework of IPv6 assignment > criteria, based on input received at the last ARIN meeting and other > discussions; I'm interested in feedback > > Thanks > > ------------- > > 6.5.8. Direct assignments from ARIN to end-user organizations > > 6.5.8.1 Criteria > > Organizations may justify an initial assignment for > addressing devices > directly attached to their own network infrastructure, with an intent > for the addresses to begin operational use within 12 months, > by meeting > one of the following criteria: > > a. Having a previously justified IPv4 end-user assignment > from ARIN or > one of its predecessor registries, or; > > b. Currently being IPv6 Multihomed or immediately becoming IPv6 > Multihomed and using an assigned valid global AS number, or; > > c. By having a network consisting of a total of 1000 or more > hosts, or; > > d. By providing a reasonable technical justification > indicating why IPv6 > addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR > may be unsuitable include, but are not limited to: > > * An organization that operates infrastructure critical to > life safety > or the functioning of society can justify the need for an assignment > based on the fact that renumbering would have a broader than expected > impact than simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency > response, power or > energy distribution, water or waste treatment, traffic management and > control, etc... > * Regardless of the number of hosts directly involved, an > organization > can justify the need for an assignment if renumbering would > affect 1000 > or more individuals either internal or external to the organization. > * An organization with a network not connected to the Internet can > justify the need for an assignment by documenting a need for > guaranteed > uniqueness, beyond the statistical uniqueness provided by ULA > (see RFC > 4193). > * An organization with a network not connected to the > Internet, such as > a VPN overlay network, can justify the need for an assignment if they > require authoritative delegation of reverse DNS. > > 6.5.8.2. Initial assignment size > > Organizations that meet at least one of the initial > assignment criteria > above are eligible to receive a minimum assignment of /48. > Requests for > larger initial assignments, reasonably justified with supporting > documentation, will be evaluated based on the number of sites and the > number of subnets needed to support a site. > > Organizations may request up to a /48 for each site in their > network. If > an organization elects for smaller prefixes for some sites, > these will > be aggregated into an equivalent number of whole /48 prefixes. > > In the rare case where more than a /48 is justified for an individual > site, ARIN will evaluate such requests using the 0.94 > HD-Ratio metric of > the number of /64 subnets to determine a justified number of > equivalent > /48 prefixes. Example: it is necessary to justify 33,689 subnets to > receive a second /48 for an individual site. > > The overall initial assignment size will be rounded up to the next > nibble boundary using the following table, based on the number of /48 > equivalents justified above: > > One and only one /48 equivalent justified, receives a /48 initial > assignment; > More than 1 but less than or equal to 10 /48 equivalents justified, > receives a /44 initial assignment; > More than 10 but less than or equal to 100 /48 equivalents justified, > receives a /40 initial assignment; > More than 100 but less than or equal to 1,500 /48 equivalents > justified, > receives a /36 initial assignment; > More than 1,500 /48 equivalents justified, receives a /32 initial > assignment or larger. > > In cases where more than 1,500 /48 equivalents are justified > an initial > assignment of /32 will be made, unless a larger initial assignment is > justified using the 0.94 HD-Ratio of the number of /48 equivalents > rounded up to the next nibble boundary. > > Each initial assignment, up to at least /40, will receive a > reservation > for growth of at least the next nibble boundary beyond the initial > assignment. Such reservations are not guaranteed and ARIN, in > its sole > discretion, may assign them to other organizations at any > time. ARIN, in > its sole discretion, may make larger reservation based on an > organization's growth projections. > > 6.5.8.3 Subsequent assignments > > For organizations with a /48 assignment, a subsequent assignment is > justified when the utilization of 33,689 /64 subnets can be > demonstrated > for a single site, or when additional sties are added to an > organization's network. > > For organizations with larger assignments, a subsequent assignment is > justified when the 0.94 HD-Ratio of the number of /48 equivalents is > exceeded: > > For an assignment of /44, a utilization of 14 or more /48 > equivalents is > necessary to justify a subsequent assignment; > For an assignment of /40, a utilization of 184 or more /48 > equivalents > is necessary to justify a subsequent assignment; > For an assignment of /36, a utilization of 2487 or more /48 > equivalents > is necessary to justify a subsequent assignment. > > When possible, subsequent assignments will be made from contiguous > adjacent address blocks. If the current assignment is within an > available contiguous reservation, then the new assignment > will be made > from within the reservation with the total assignment sized > at the next > nibble boundary. If a contiguous reservation is not available, then a > separate new assignment sized at the next nibble boundary > will be made. > > When a new non-contiguous assignment is made, ARIN, in its sole > discretion, may make a reservation for growth of at least the next > nibble boundary. Such reservations are not guaranteed and > ARIN, in its > sole discretion, may assign them to other organizations at any time. > > Rationale: > > This proposal provides a complete rework of the IPv6 end-user > assignment > criteria, removing the dependency on IPv4 policy, and providing clear > guidance in requesting larger initial assignments. > > The following general concepts are included: > > * Previously justified IPv4 resources may be used to justify the need > for IPv6 resources. > * Internet multihoming is sufficient justification for an > ipv6 end-user > assignment in and of itself. > * Other end-users must justify why an ISP or LIR assignment is not > sufficient for their needs. > * Organizations with multiple sites are allowed to request a /48 for > each site. > * Providing a sufficiently large initial assignments and reservations > will reduce route table growth caused by subsequent assignments. > * While HD-Ratio is not eliminated, it is not necessary for most > end-users to understand the details of the HD-Ratio. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From BillD at cait.wustl.edu Mon Aug 30 10:59:34 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 30 Aug 2010 09:59:34 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion Message-ID: PPML Participants.... Below is the most current language for PP 2010-10. The language will be 'frozen' September 24 for the upcoming Public Policy Meeting discussion in Atlanta...Oct 6-8 . As such, your opportunity to influence language or provide formal input to the Advisory Council which may result in wording changes, must be received by September 23. All previous comments and suggestions from the PPML, private correspondence, converstations, etc. have been captured. Input from the other RIR communities where this 'Global Policy' is being considered will similarly be captured. Those inputs plus whatever we receive between now and the Atlanta meeting will be brought to the meeting for discussion. Thanks for your participation in the ARIN Policy Development Process and in this forum. Bill Darte ARIN Advisory Council Primary Shepherd for PP 2010-10 ******* begin policy language ******* Global Policy for IPv4 Allocations by the IANA Post Exhaustion Version/Date: 20 July 2010 Policy statement: 1. Reclamation Pool Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool will initially contain any fragments that may be left over in IANA inventory. As soon as the first RIR exhausts its inventory of IP address space, this Reclamation Pool will be declared active. When the Reclamation Pool is declared active, the Global Policy for the Allocation of the Remaining IPv4 Address Space[3] and Policy for Allocation of IPv4 Blocks to Regional Internet Registries[4] will be formally deprecated. 2. Returning Address Space to the IANA The IANA will accept into the Reclamation Pool all eligible IPv4 address space that are offered for return. Eligible address space includes addresses that are not designated as "special use" by an IETF RFC or addresses allocated to RIR's unless they are being returned by the RIR that they were orignally allocated to. Legacy address holders may return address space directly to the IANA if they so choose. 3. Address Allocations from the Reclamation Pool by the IANA Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool will be allocated on a CIDR boundary equal to or shorter than the longest minimum allocation unit of all RIRs in order to complete these allocations.The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIR's. Any remainder not evenly divisible by the number of eligible RIR's based on a CIDR boundary equal to or shorter than the longest minimum allocation unit of all RIRs will remain in the Reclamation Pool. Addresses that are left over will be held in the Reclamation Pool until additional IP addresses can be returned to rejoin addresses on CIDR boundaries to the Reclamation Pool or a minumum allocation unit is set to allow allocation from existing inventory. 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA. 5. Reporting Requirements The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by whom and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public notice confirming RIR eligibility subsequent to Section 4. 6. No Transfer Rights Address space assigned from the Reclamation Pool may be transferred if there is either an ICANN Board ratified global policy or globally coordinated RIR policy specifically written to deal with transfers whether inter-RIR or from one entity to another. Transfers must meet the requirements of such a policy. In the absence of such a policy, no transfers of any kind related to address space allocated or assigned from the reclamation pool is allowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Aug 30 17:29:21 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 30 Aug 2010 16:29:21 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: <4C7C22B1.2050500@umn.edu> This isn't going to fly in APNIC. APNIC will not agree to the no transfer provision. Furthermore, as currently written it sets up a winner take all race to the bottom, a maximum allocation size would be an easy to fix this without making things to complicated. During the afternoon tea break on Friday, Owen and had a conversation with, Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip Smith, and Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit too. Leslie did not comment on policy, but it was very helpful to have someone who had actually interacted with IANA involved in the conversation. The consensus of those gathered was that a very simple policy was needed, focusing on IANA. It should allow IANA to accept returns of /24 or large blocks. (no requirements for return by RIRs or anyone else for that matter). Then allow IANA to allocate on a needs basis to the RIRs with a minimum block size /24 and no more than the equilivant of a /10 at one time. The /10 at a time limit is intended to prevent a winner takes all race to the bottom and allow some possibility that a larger block could be shared between multiple RIRs without having addresses set idle if an RIR needs them. So my question to the rest of the AC, how should we proceed, keep text that we know will not succeed as global policy or change text? What would it take to make a radical change to the Draft Policy? Otherwise, we would need to come to the next meeting with new text which likely be past IANA run-out. Comments, rotten fruit, etc... On 8/30/10 09:59 CDT, Bill Darte wrote: > PPML Participants.... > > Below is the most current language for PP 2010-10. The language will be > 'frozen' September 24 for the upcoming Public Policy Meeting discussion > in Atlanta...Oct 6-8 . > > As such, your opportunity to influence language or provide formal input > to the Advisory Council which may result in wording changes, must be > received by September 23. All previous comments and suggestions from the > PPML, private correspondence, converstations, etc. have been captured. > Input from the other RIR communities where this 'Global Policy' is being > considered will similarly be captured. Those inputs plus whatever we > receive between now and the Atlanta meeting will be brought to the > meeting for discussion. > > Thanks for your participation in the ARIN Policy Development Process > and in this forum. > > Bill Darte > ARIN Advisory Council > Primary Shepherd for PP 2010-10 > > ******* begin policy language ******* > > Global Policy for IPv4 Allocations by the IANA Post Exhaustion > Version/Date: 20 July 2010 > > Policy statement: > > 1. Reclamation Pool > Upon adoption of this IPv4 address policy by the ICANN Board of > Directors, the IANA shall establish a Reclamation Pool to be utilized > post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool > will initially contain any fragments that may be left over in IANA > inventory. As soon as the first RIR exhausts its inventory of IP address > space, this Reclamation Pool will be declared active. When the > Reclamation Pool is declared active, the Global Policy for the > Allocation of the Remaining IPv4 Address Space[3] and Policy for > Allocation of IPv4 Blocks to Regional Internet Registries[4] will be > formally deprecated. > > 2. Returning Address Space to the IANA > The IANA will accept into the Reclamation Pool all eligible IPv4 address > space that are offered for return. Eligible address space includes > addresses that are not designated as "special use" by an IETF RFC or > addresses allocated to RIR's unless they are being returned by the RIR > that they were orignally allocated to. Legacy address holders may return > address space directly to the IANA if they so choose. > > 3. Address Allocations from the Reclamation Pool by the IANA > Allocations from the Reclamation Pool may begin once the pool is > declared active. Addresses in the Reclamation Pool will be allocated on > a CIDR boundary equal to or shorter than the longest minimum allocation > unit of all RIRs in order to complete these allocations.The Reclamation > Pool will be divided on CIDR boundaries and distributed evenly to all > eligible RIR's. Any remainder not evenly divisible by the number of > eligible RIR's based on a CIDR boundary equal to or shorter than the > longest minimum allocation unit of all RIRs will remain in the > Reclamation Pool. Addresses that are left over will be held in the > Reclamation Pool until additional IP addresses can be returned to rejoin > addresses on CIDR boundaries to the Reclamation Pool or a minumum > allocation unit is set to allow allocation from existing inventory. > > 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool > Upon the exhaustion of an RIR's free space pool and after receiving > their final /8 from the IANA[3], an RIR will become eligible to request > address space from the IANA Reclamation Pool when it publicly announces > via its respective global announcements email list and by posting a > notice on its website that it has exhausted its supply of IPv4 address > space. Exhaustion is defined as an inventory of less than the equivalent > of a single /8 and the inability to further assign address space to its > customers in units equal to or shorter than the longest of any RIR's > policy defined minimum allocation unit. Any RIR that is formed after the > ICANN Board of Directors has ratified this policy is not eligible to > utilize this policy to obtain IPv4 address space from the IANA. > > 5. Reporting Requirements > The IANA shall publish on at least a weekly basis a report that is > publicly available which at a minimum details all address space that has > been received and that has been allocated. The IANA shall publish a > Returned Address Space Report which indicates what resources were > returned, by whom and when. The IANA shall publish an Allocations Report > on at least a weekly basis which at a minimum indicates what IPv4 > address space has been allocated, which RIR received the allocation and > when. The IANA shall publish a public notice confirming RIR eligibility > subsequent to Section 4. > > 6. No Transfer Rights > Address space assigned from the Reclamation Pool may be transferred if > there is either an ICANN Board ratified global policy or globally > coordinated RIR policy specifically written to deal with transfers > whether inter-RIR or from one entity to another. Transfers must meet the > requirements of such a policy. In the absence of such a policy, no > transfers of any kind related to address space allocated or assigned > from the reclamation pool is allowed. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From dylan.ebner at crlmed.com Mon Aug 30 17:52:58 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Mon, 30 Aug 2010 21:52:58 +0000 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: <2cb2257e-1c01-4648-9449-b3e205e167e9@blur> Pppp Dylan Ebner, Network Engineer Consulting Radiologists, Ltd. 1221 Nicollet Mall, Mpls, MN 55403 Ph. 612-573-2236 Fax 612-573-2250 dylan.ebner at crlmed.com www.consultingradiologists.com -----Original message----- From: David Farmer To: Bill Darte , "arin-ppml at arin.net" Sent: Mon, Aug 30, 2010 21:30:22 GMT+00:00 Subject: Re: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion This isn't going to fly in APNIC. APNIC will not agree to the no transfer provision. Furthermore, as currently written it sets up a winner take all race to the bottom, a maximum allocation size would be an easy to fix this without making things to complicated. During the afternoon tea break on Friday, Owen and had a conversation with, Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip Smith, and Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit too. Leslie did not comment on policy, but it was very helpful to have someone who had actually interacted with IANA involved in the conversation. The consensus of those gathered was that a very simple policy was needed, focusing on IANA. It should allow IANA to accept returns of /24 or large blocks. (no requirements for return by RIRs or anyone else for that matter). Then allow IANA to allocate on a needs basis to the RIRs with a minimum block size /24 and no more than the equilivant of a /10 at one time. The /10 at a time limit is intended to prevent a winner takes all race to the bottom and allow some possibility that a larger block could be shared between multiple RIRs without having addresses set idle if an RIR needs them. So my question to the rest of the AC, how should we proceed, keep text that we know will not succeed as global policy or change text? What would it take to make a radical change to the Draft Policy? Otherwise, we would need to come to the next meeting with new text which likely be past IANA run-out. Comments, rotten fruit, etc... On 8/30/10 09:59 CDT, Bill Darte wrote: > PPML Participants.... > > Below is the most current language for PP 2010-10. The language will be > 'frozen' September 24 for the upcoming Public Policy Meeting discussion > in Atlanta...Oct 6-8 . > > As such, your opportunity to influence language or provide formal input > to the Advisory Council which may result in wording changes, must be > received by September 23. All previous comments and suggestions from the > PPML, private correspondence, converstations, etc. have been captured. > Input from the other RIR communities where this 'Global Policy' is being > considered will similarly be captured. Those inputs plus whatever we > receive between now and the Atlanta meeting will be brought to the > meeting for discussion. > > Thanks for your participation in the ARIN Policy Development Process > and in this forum. > > Bill Darte > ARIN Advisory Council > Primary Shepherd for PP 2010-10 > > ******* begin policy language ******* > > Global Policy for IPv4 Allocations by the IANA Post Exhaustion > Version/Date: 20 July 2010 > > Policy statement: > > 1. Reclamation Pool > Upon adoption of this IPv4 address policy by the ICANN Board of > Directors, the IANA shall establish a Reclamation Pool to be utilized > post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool > will initially contain any fragments that may be left over in IANA > inventory. As soon as the first RIR exhausts its inventory of IP address > space, this Reclamation Pool will be declared active. When the > Reclamation Pool is declared active, the Global Policy for the > Allocation of the Remaining IPv4 Address Space[3] and Policy for > Allocation of IPv4 Blocks to Regional Internet Registries[4] will be > formally deprecated. > > 2. Returning Address Space to the IANA > The IANA will accept into the Reclamation Pool all eligible IPv4 address > space that are offered for return. Eligible address space includes > addresses that are not designated as "special use" by an IETF RFC or > addresses allocated to RIR's unless they are being returned by the RIR > that they were orignally allocated to. Legacy address holders may return > address space directly to the IANA if they so choose. > > 3. Address Allocations from the Reclamation Pool by the IANA > Allocations from the Reclamation Pool may begin once the pool is > declared active. Addresses in the Reclamation Pool will be allocated on > a CIDR boundary equal to or shorter than the longest minimum allocation > unit of all RIRs in order to complete these allocations.The Reclamation > Pool will be divided on CIDR boundaries and distributed evenly to all > eligible RIR's. Any remainder not evenly divisible by the number of > eligible RIR's based on a CIDR boundary equal to or shorter than the > longest minimum allocation unit of all RIRs will remain in the > Reclamation Pool. Addresses that are left over will be held in the > Reclamation Pool until additional IP addresses can be returned to rejoin > addresses on CIDR boundaries to the Reclamation Pool or a minumum > allocation unit is set to allow allocation from existing inventory. > > 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool > Upon the exhaustion of an RIR's free space pool and after receiving > their final /8 from the IANA[3], an RIR will become eligible to request > address space from the IANA Reclamation Pool when it publicly announces > via its respective global announcements email list and by posting a > notice on its website that it has exhausted its supply of IPv4 address > space. Exhaustion is defined as an inventory of less than the equivalent > of a single /8 and the inability to further assign address space to its > customers in units equal to or shorter than the longest of any RIR's > policy defined minimum allocation unit. Any RIR that is formed after the > ICANN Board of Directors has ratified this policy is not eligible to > utilize this policy to obtain IPv4 address space from the IANA. > > 5. Reporting Requirements > The IANA shall publish on at least a weekly basis a report that is > publicly available which at a minimum details all address space that has > been received and that has been allocated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Mon Aug 30 17:54:31 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 30 Aug 2010 15:54:31 -0600 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <4C7C22B1.2050500@umn.edu> References: <4C7C22B1.2050500@umn.edu> Message-ID: On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: > This isn't going to fly in APNIC. ?APNIC will not agree to the no transfer > provision. ?Furthermore, as currently written it sets up a winner take all > race to the bottom, a maximum allocation size would be an easy to fix this > without making things to complicated. The no-transfer provision is essential. Without it, a region with a very liberal / non-needs-based transfer policy can potentially suck all of the remnants into their region and sell them off. As one of the authors of this proposal I can say without a doubt that I would withdraw my support for (and vehemently oppose) it sans that provision. > During the afternoon tea break on Friday, Owen and had a conversation with, > Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip Smith, and > Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit too. Leslie did > not comment on policy, but it was very helpful to have someone who had > actually interacted with IANA involved in the conversation. > > The consensus of those gathered was that a very simple policy was needed, > focusing on IANA. ?It should allow IANA to accept returns of /24 or large > blocks. (no requirements for return by RIRs or anyone else for that matter). > ?Then allow IANA to allocate on a needs basis to the RIRs with a minimum > block size /24 and no more than the equilivant of a /10 at one time. > > The /10 at a time limit is intended to prevent a winner takes all race to > the bottom and allow some possibility that a larger block could be shared > between multiple RIRs without having addresses set idle if an RIR needs > them. > > So my question to the rest of the AC, how should we proceed, keep text that > we know will not succeed as global policy or change text? ?What would it > take to make a radical change to the Draft Policy? ?Otherwise, we would need > to come to the next meeting with new text which likely be past IANA run-out. I disagree that radical changes are needed. Simply adding a maximum allocation to the existing proposal would accomplish this. > > Comments, rotten fruit, etc... I can tell you that the group of co-authors who introduced this policy are actively reviewing and discussing all feedback from APNIC and plan to work with the AC Shepherds to make any edits necessary before the text is frozen. Cheers, ~Chris > -- > =============================================== > David Farmer ? ? ? ? ? ? ? Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE ? ? ?Phone: 612-626-0815 > Minneapolis, MN 55414-3029 ? Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From marty at akamai.com Mon Aug 30 18:37:50 2010 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 30 Aug 2010 18:37:50 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: Message-ID: On 8/30/10 5:54 PM, "Chris Grundemann" wrote: > On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: >> This isn't going to fly in APNIC. ?APNIC will not agree to the no transfer >> provision. ?Furthermore, as currently written it sets up a winner take all >> race to the bottom, a maximum allocation size would be an easy to fix this >> without making things to complicated. > > The no-transfer provision is essential. Without it, a region with a > very liberal / non-needs-based transfer policy can potentially suck > all of the remnants into their region and sell them off. I don't think that this is the intention of the transfer policy in APNIC, but this is an unfortunate effect of it and one that is a rather large, real, risk and which contributed to the demise of the previous discussion. [ clip ] >> So my question to the rest of the AC, how should we proceed, keep text that >> we know will not succeed as global policy or change text? ?What would it >> take to make a radical change to the Draft Policy? ?Otherwise, we would need >> to come to the next meeting with new text which likely be past IANA run-out. > > I disagree that radical changes are needed. Simply adding a maximum > allocation to the existing proposal would accomplish this. I do too. This is part of the process. The operation of the allocation method does not match the stated intent of the proposal. >From the proposal: "Defines "need" as the basis for further IPv4 allocations by the IANA." The feedback from the APNIC region pointed out a mechanical problem. While need is intact in the definition of exhaustion and use, fairness was lost. Minor revision. If there's something to focus on it would be how to make this work if the transfer section will not work. [ clip ] From farmer at umn.edu Mon Aug 30 19:01:03 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 30 Aug 2010 18:01:03 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <4C7C22B1.2050500@umn.edu> References: <4C7C22B1.2050500@umn.edu> Message-ID: <4C7C382F.7000100@umn.edu> I want to apologize to everyone on PPML. I'm still in Australia after the APNIC meeting, helping out the world's tourist economy a little bit, and broke the cardinal rule of not replying to email until after having caffeine in the morning. This email was intended for the Advisory Council email list. However, it accurately reflects my impression on how things went for this policy at the meeting, and my best recommendations on how this should more forward. I have corrected my previous mistake and I am well caffeinated now, and had some breakfast too. Again sorry for my sleep haze induced mistake. On 8/30/10 16:29 CDT, David Farmer wrote: > This isn't going to fly in APNIC. APNIC will not agree to the no > transfer provision. Furthermore, as currently written it sets up a > winner take all race to the bottom, a maximum allocation size would be > an easy to fix this without making things to complicated. > > During the afternoon tea break on Friday, Owen and had a conversation > with, Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip > Smith, and Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit > too. Leslie did not comment on policy, but it was very helpful to have > someone who had actually interacted with IANA involved in the conversation. > > The consensus of those gathered was that a very simple policy was > needed, focusing on IANA. It should allow IANA to accept returns of /24 > or large blocks. (no requirements for return by RIRs or anyone else for > that matter). Then allow IANA to allocate on a needs basis to the RIRs > with a minimum block size /24 and no more than the equilivant of a /10 > at one time. > > The /10 at a time limit is intended to prevent a winner takes all race > to the bottom and allow some possibility that a larger block could be > shared between multiple RIRs without having addresses set idle if an RIR > needs them. > > So my question to the rest of the AC, how should we proceed, keep text > that we know will not succeed as global policy or change text? What > would it take to make a radical change to the Draft Policy? Otherwise, > we would need to come to the next meeting with new text which likely be > past IANA run-out. > > Comments, rotten fruit, etc... > > > On 8/30/10 09:59 CDT, Bill Darte wrote: >> PPML Participants.... >> >> Below is the most current language for PP 2010-10. The language will be >> 'frozen' September 24 for the upcoming Public Policy Meeting discussion >> in Atlanta...Oct 6-8 >> . >> >> As such, your opportunity to influence language or provide formal input >> to the Advisory Council which may result in wording changes, must be >> received by September 23. All previous comments and suggestions from the >> PPML, private correspondence, converstations, etc. have been captured. >> Input from the other RIR communities where this 'Global Policy' is being >> considered will similarly be captured. Those inputs plus whatever we >> receive between now and the Atlanta meeting will be brought to the >> meeting for discussion. >> >> Thanks for your participation in the ARIN Policy Development Process >> and in this forum. >> >> Bill Darte >> ARIN Advisory Council >> Primary Shepherd for PP 2010-10 >> >> ******* begin policy language ******* >> >> Global Policy for IPv4 Allocations by the IANA Post Exhaustion >> Version/Date: 20 July 2010 >> >> Policy statement: >> >> 1. Reclamation Pool >> Upon adoption of this IPv4 address policy by the ICANN Board of >> Directors, the IANA shall establish a Reclamation Pool to be utilized >> post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool >> will initially contain any fragments that may be left over in IANA >> inventory. As soon as the first RIR exhausts its inventory of IP address >> space, this Reclamation Pool will be declared active. When the >> Reclamation Pool is declared active, the Global Policy for the >> Allocation of the Remaining IPv4 Address Space[3] and Policy for >> Allocation of IPv4 Blocks to Regional Internet Registries[4] will be >> formally deprecated. >> >> 2. Returning Address Space to the IANA >> The IANA will accept into the Reclamation Pool all eligible IPv4 address >> space that are offered for return. Eligible address space includes >> addresses that are not designated as "special use" by an IETF RFC or >> addresses allocated to RIR's unless they are being returned by the RIR >> that they were orignally allocated to. Legacy address holders may return >> address space directly to the IANA if they so choose. >> >> 3. Address Allocations from the Reclamation Pool by the IANA >> Allocations from the Reclamation Pool may begin once the pool is >> declared active. Addresses in the Reclamation Pool will be allocated on >> a CIDR boundary equal to or shorter than the longest minimum allocation >> unit of all RIRs in order to complete these allocations.The Reclamation >> Pool will be divided on CIDR boundaries and distributed evenly to all >> eligible RIR's. Any remainder not evenly divisible by the number of >> eligible RIR's based on a CIDR boundary equal to or shorter than the >> longest minimum allocation unit of all RIRs will remain in the >> Reclamation Pool. Addresses that are left over will be held in the >> Reclamation Pool until additional IP addresses can be returned to rejoin >> addresses on CIDR boundaries to the Reclamation Pool or a minumum >> allocation unit is set to allow allocation from existing inventory. >> >> 4. RIR Eligibility for Receiving Allocations from the Reclamation Pool >> Upon the exhaustion of an RIR's free space pool and after receiving >> their final /8 from the IANA[3], an RIR will become eligible to request >> address space from the IANA Reclamation Pool when it publicly announces >> via its respective global announcements email list and by posting a >> notice on its website that it has exhausted its supply of IPv4 address >> space. Exhaustion is defined as an inventory of less than the equivalent >> of a single /8 and the inability to further assign address space to its >> customers in units equal to or shorter than the longest of any RIR's >> policy defined minimum allocation unit. Any RIR that is formed after the >> ICANN Board of Directors has ratified this policy is not eligible to >> utilize this policy to obtain IPv4 address space from the IANA. >> >> 5. Reporting Requirements >> The IANA shall publish on at least a weekly basis a report that is >> publicly available which at a minimum details all address space that has >> been received and that has been allocated. The IANA shall publish a >> Returned Address Space Report which indicates what resources were >> returned, by whom and when. The IANA shall publish an Allocations Report >> on at least a weekly basis which at a minimum indicates what IPv4 >> address space has been allocated, which RIR received the allocation and >> when. The IANA shall publish a public notice confirming RIR eligibility >> subsequent to Section 4. >> >> 6. No Transfer Rights >> Address space assigned from the Reclamation Pool may be transferred if >> there is either an ICANN Board ratified global policy or globally >> coordinated RIR policy specifically written to deal with transfers >> whether inter-RIR or from one entity to another. Transfers must meet the >> requirements of such a policy. In the absence of such a policy, no >> transfers of any kind related to address space allocated or assigned >> from the reclamation pool is allowed. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Mon Aug 30 19:25:40 2010 From: farmer at umn.edu (David Farmer) Date: Mon, 30 Aug 2010 18:25:40 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: <4C7C22B1.2050500@umn.edu> Message-ID: <4C7C3DF4.8020201@umn.edu> On 8/30/10 16:54 CDT, Chris Grundemann wrote: > On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: >> This isn't going to fly in APNIC. APNIC will not agree to the no transfer >> provision. Furthermore, as currently written it sets up a winner take all >> race to the bottom, a maximum allocation size would be an easy to fix this >> without making things to complicated. > > The no-transfer provision is essential. Without it, a region with a > very liberal / non-needs-based transfer policy can potentially suck > all of the remnants into their region and sell them off. > > As one of the authors of this proposal I can say without a doubt that > I would withdraw my support for (and vehemently oppose) it sans that > provision. Chris, I can appreciate you position on this. However, I can assure that a number of the authors of the previous global policy proposal thought that a mandatory requirement for return was equally important. I believe the essential portion of this policy is for IANA to have the ability to allocate any address space that is returned to it, not just /8s. What address space an RIR returns, if any, or placing restrictions on what can be done with the space once it is allocated to an RIR is and should be a local policy concern. I must admit that I would prefer that APNIC transfer policy was needs based, but that is and should be the APNIC community's choice. Just as how ARIN should deal with address space returned to it should be the ARIN community's choice. If we can focus on the essential functions of IANA and stay out of all local policy issues, I think we might have a policy that can be passed globally. >> During the afternoon tea break on Friday, Owen and had a conversation with, >> Gaurab Raj Upadhaya (the new sig-policy chair for APNIC), Philip Smith, and >> Filiz Yilmaz (from RIPE), and Leslie stopped by for a bit too. Leslie did >> not comment on policy, but it was very helpful to have someone who had >> actually interacted with IANA involved in the conversation. >> >> The consensus of those gathered was that a very simple policy was needed, >> focusing on IANA. It should allow IANA to accept returns of /24 or large >> blocks. (no requirements for return by RIRs or anyone else for that matter). >> Then allow IANA to allocate on a needs basis to the RIRs with a minimum >> block size /24 and no more than the equilivant of a /10 at one time. >> >> The /10 at a time limit is intended to prevent a winner takes all race to >> the bottom and allow some possibility that a larger block could be shared >> between multiple RIRs without having addresses set idle if an RIR needs >> them. >> >> So my question to the rest of the AC, how should we proceed, keep text that >> we know will not succeed as global policy or change text? What would it >> take to make a radical change to the Draft Policy? Otherwise, we would need >> to come to the next meeting with new text which likely be past IANA run-out. > > I disagree that radical changes are needed. Simply adding a maximum > allocation to the existing proposal would accomplish this. > >> >> Comments, rotten fruit, etc... > > I can tell you that the group of co-authors who introduced this policy > are actively reviewing and discussing all feedback from APNIC and plan > to work with the AC Shepherds to make any edits necessary before the > text is frozen. Please do revise the text -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Mon Aug 30 22:27:37 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Aug 2010 12:27:37 +1000 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: Just drop the transfer restriction in my opinion. The other RIRs can choose not to return space until the transfer issue is rectified, but at least we would have enabling policy at IANA. Owen Sent from my iPad On Aug 31, 2010, at 8:37 AM, "Hannigan, Martin" wrote: > > > > On 8/30/10 5:54 PM, "Chris Grundemann" wrote: > >> On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: >>> This isn't going to fly in APNIC. APNIC will not agree to the no transfer >>> provision. Furthermore, as currently written it sets up a winner take all >>> race to the bottom, a maximum allocation size would be an easy to fix this >>> without making things to complicated. >> >> The no-transfer provision is essential. Without it, a region with a >> very liberal / non-needs-based transfer policy can potentially suck >> all of the remnants into their region and sell them off. > > I don't think that this is the intention of the transfer policy in APNIC, > but this is an unfortunate effect of it and one that is a rather large, > real, risk and which contributed to the demise of the previous discussion. > > > [ clip ] > >>> So my question to the rest of the AC, how should we proceed, keep text that >>> we know will not succeed as global policy or change text? What would it >>> take to make a radical change to the Draft Policy? Otherwise, we would need >>> to come to the next meeting with new text which likely be past IANA run-out. >> >> I disagree that radical changes are needed. Simply adding a maximum >> allocation to the existing proposal would accomplish this. > > I do too. This is part of the process. The operation of the allocation > method does not match the stated intent of the proposal. > >> From the proposal: > > "Defines "need" as the basis for further IPv4 allocations by the IANA." > > The feedback from the APNIC region pointed out a mechanical problem. While > need is intact in the definition of exhaustion and use, fairness was lost. > Minor revision. If there's something to focus on it would be how to make > this work if the transfer section will not work. > > > [ clip ] > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From ipgoddess.arin at gmail.com Tue Aug 31 08:49:13 2010 From: ipgoddess.arin at gmail.com (Stacy Hughes) Date: Tue, 31 Aug 2010 07:49:13 -0500 Subject: [arin-ppml] Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng Proposal Version: 1.m In-Reply-To: References: <4C6EE09E.4030003@umn.edu> Message-ID: I believe this is misuse of a whole /8, and that the /10 already designated for this purpose is sufficient. Stacy -- Stacy Hughes +1-831-676-5166 Sent from my iPad, please forgive typos On Aug 20, 2010, at 16:12, Owen DeLong wrote: > 2010-13 has been revised to accommodate this as follows: > > Specifically, I refer you to 4.10.6(f) below... > > > Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng > Proposal Version: 1.m > Date: 18 June 2010 > Proposal type: modify > Policy term: permanent > Policy statement: > > Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" > Amend section 4.10 replacing > "When ARIN receives its last /8 IPv4 allocation from IANA, a > contiguous /10 IPv4 block will be set aside and dedicated to > facilitate IPv6 deployment." > with > "When ARIN receives its last /8 IPv4 allocation from IANA, that > /8 will form a dedicated pool to facilitate IPv6 Deployment." > > and replacing > "...when possible within that /10 block." > with > "...when possible within this pool, particularly within the last > /8 block. Following IANA depletion, all IPv4 address space returned > directly to ARIN except space to be reissued under an 8.3 directed > transfer will be added to this pool." . > > and Strike > "This block will be subject to a minimum size allocation of /28 > and a maximum size allocation of /24." from section 4.10. > > Amend 4.10.1 replacing > "...under this policy in the preceding..." > with > "...under each provision of this policy (as detailed in > section 4.10.6) in the preceding..." > > Add the following to section 4.10 of the NRPM > > 6. Specific types of transitional uses have specific requirements: > > (a) An ISP/LIR may request a block no smaller than a /24 nor larger than > a /18 to be used to provide single IPv4 /32s to their customers which > could justify a /28 or more of IPv4 under ARIN policies in effect at > the time of IANA depletion. > 1. No customer may receive more than a single IPv4 /32 under this > provision. > 2. The customer must not have any other IPv4 allocations or assignments > from the provider at the time of this assignment. > 3. The customer must not have any direct assignments from ARIN at the > time of this assignment. > 4. The customer must not have more than a single IPv4 /32 from any > other provider at the time of this assignment. > 5. The customer must have IPv6 addresses with IPv6 connectivity to > the ISP/LIR (must be dual-stacked). > 6. The ISP/LIR must demonstrate that it already provides IPv6 > addressing and connectivity to at least one existing customer > for each /32 requested, up to 90% of their total customer base. > 7. No organization shall receive more than a total of a /14 or > equivalent under this section. > (b) An ISP/LIR or End user organization may request a block no > smaller than a /28 and no larger than a /22 to provide single > IPv4 /32s to each physical server used to provide Internet > reachable content. > 1. Space issued under this provision is an assignment, not an > allocation. An LIR may not distribute this space to their customers. > 2. No server may recieve more than a single IPv4 /32 under this > provision. > 3. The server must have IPv6 addresses with IPv6 connectivity (must > be dual-stacked). > 4. The recieving organization must demonstrate that it already > provides IPv6 addressing and connectivity to at least one > existing server in addition to the server for which each > /32 is requested, up to 100% of their total server base. > (organizations which can show 100% dual stack are exempt > from this requirement). > 5. The recieving organization must enable all of their content > on the following schedule: > 25% of content IPv6 reachable within six months of receiving > their first addresses under this policy > 50% of content IPv6 reachable within one year of receiving > their first addresses under this policy > 75% of content IPv6 reachable within 18 months of receiving > their first addresses under this policy > 90% of content IPv6 reachable within 24 months of receiving > their first addresses under this policy > 6. No organization shall receive more than a total of a /16 or > equivalent under this section. > > (c) An ISP/LIR or End user organization may request a block no smaller > than a /28 and no larger than a /24 for purposes relevant to their > ability to deploy IPv6 as specified in section 4.12. > 1. Space issued under this provision is an assignment, not an > allocation. An LIR may not distribute this space to their customers. > 2. Space issued under this provision must be used to provide the > required public IPv4 address(es) for transitional technologies > operated by the recipient organization. Specific examples of > permitted uses are: > a. Large scale or "Carrier Grade" NAT > b. NAT-PT > c. DS-LITE/B4/AFTeR > d. DNS64 or other transitional DNS enablers > e. For other technologies of similar purpose and scope. > > (d) An ISP/LIR or End user organization may request a block no smaller > than a /28 and no larger than a /24 for other transitional > technologies not envisioned at the time of this proposal, but, > in no case for general IPv4 addressing provided to customers. > > (e) A /10 from the final /8 shall be reserved for issuance under > 4.10.6(c) and 4.10.6(d). In no case shall any addresses from > this /10 be issued under 4.10.6(a) and 4.10.6(b). > > (f) Applications which would qualify for IPv4 under section 4.4 of > the NRPM (critical infrastructure) may qualify for IPv4 space > under this policy if they meet the following criteria: > 1. The critical infrastructure to be numbered must also have > IPv6 addresses and must provide all services provided on > IPv4 over IPv6 on the same time table. > 2. Assignments under this provision shall be the smallest > technically feasible size for the critical infrastructure in > question. > 3. The total space assigned under this provision shall not > exceed the equivalent of a /14. > > Add the following to section 4 of the NRPM > > 4.11 Required utilization for subsequent allocation under section 4.10 > > No organization shall receive more than one allocation or assignment > under section 4.10 unless all prior space issued under 4.10 meets > the utilization requirements of this section: > > 1. The most recent 4.10 allocation/assignment must be at least > 80% utilized. > 2. All utilization must be permitted under section 4.10 > 3. All prior 4.10 allocation/assignments must be at least 90% utilized. > 4. For purposes of this computation, space received under each > provision shall be considered separately if an organization has > received resources through multiple provisions. > > 4.12 Quarterly Utilization Monitoring > > Allocations and assignments under section 4.10 shall be subject > to quarterly verification of utilization. > > 1. An organization which is not meeting their utilization targets > may have their allocation or assignment reduced accordingly > with the reclaimed portions going back to ARIN for distribution > to other organizations. Space reclaimed in this manner shall be > exempt from any requirement to return space to the IANA. > 2. An organization which is using space received under 4.10 in a > manner contrary to 4.10 et seq. may have their allocation or > assignment reduced or revoked with reclaimed portions going back > to ARIN for distribution to other organizations. Space reclaimed > in this manner shall be exempt from any requirement to return > space to the IANA. > > Rationale: > > The current terminology in section 4.10 is vague and could allow a > variety of interpretations which could lead to allocations or assignments > being made to ISPs intending to misuse the space for general deployment by > using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 > space for transition. For example, the current policy could be interpreted > to enable an ISP to require IPv4 addresses for all IPv6 customers to roll > IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. > This is clearly outside of the original intent of the proposal which > created 4.10 (6rd was not yet envisioned at the time that was written). > This proposal seeks to clarify that intent and tighten up the requirements > for organizations seeking to get space from this limited final resource > so that it truly is available to facilitate transitional technologies. > > It also expands the scope of 4.10 to include more address space to be > given out in manners that facilitate transition, but, are not directly > transitional technologies per se. These allocatios and assignments > require specific IPv6 deployment targets to be met and have much > stricter limitations on the utilization of IPv4 addresses issued > from this pool. > > Timetable for implementation: immediate > > For reference, here is the current text of 4.10 > > 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment > > When ARIN receives its last /8 IPv4 allocation from IANA, a > contiguous /10 IPv4 block will be set aside and dedicated to > facilitate IPv6 deployment. Allocations and assignments from > this block must be justified by immediate IPv6 deployment > requirements. > > Examples of such needs include: > IPv4 addresses for key dual stack DNS servers, and > NAT-PT or NAT464 translators. > > ARIN staff will use their discretion when evaluating justifications. > > This block will be subject to a minimum size allocation > of /28 and a maximum size allocation of /24. ARIN > should use sparse allocation when possible within that /10 block. > > In order to receive an allocation or assignment under this policy: > 1. the applicant may not have received resources under > this policy in the preceding six months; > 2. previous allocations/assignments under this policy must > continue to meet the justification requirements of this policy; > 3. previous allocations/assignments under this policy must > meet the utilization requirements of end user assignments; > 4. the applicant must demonstrate that no other allocations or > assignments will meet this need; > 5. on subsequent allocation under this policy, ARIN staff may > require applicants to renumber out of previously > allocated / assigned space under this policy in order to > minimize non-contiguous allocations. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dylan.ebner at crlmed.com Tue Aug 31 10:48:22 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Tue, 31 Aug 2010 14:48:22 +0000 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D20691872EEEB@MBX9.EXCHPROD.USA.NET> I think the transfer policy is important, but at Owen states, an enabling policy is also very important and possibly the policy could move forward without it if language was added that somehow required the transfer policy in the future. Also, and I may be mistaken on this, doesn't IANA have a policy in which they are preferencing /8 allocations to RIRs that service developing nations? If they do, what happens if final /8 blocks start to run out and then the RIRs that should be getting those /8 allocations cannot get the blocks they need. I worry that AfriNIC and LACNIC will end up getting shafted here. Dylan Ebner -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, August 30, 2010 9:28 PM To: Hannigan, Martin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion Just drop the transfer restriction in my opinion. The other RIRs can choose not to return space until the transfer issue is rectified, but at least we would have enabling policy at IANA. Owen Sent from my iPad On Aug 31, 2010, at 8:37 AM, "Hannigan, Martin" wrote: > > > > On 8/30/10 5:54 PM, "Chris Grundemann" wrote: > >> On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: >>> This isn't going to fly in APNIC. APNIC will not agree to the no transfer >>> provision. Furthermore, as currently written it sets up a winner take all >>> race to the bottom, a maximum allocation size would be an easy to fix this >>> without making things to complicated. >> >> The no-transfer provision is essential. Without it, a region with a >> very liberal / non-needs-based transfer policy can potentially suck >> all of the remnants into their region and sell them off. > > I don't think that this is the intention of the transfer policy in APNIC, > but this is an unfortunate effect of it and one that is a rather large, > real, risk and which contributed to the demise of the previous discussion. > > > [ clip ] > >>> So my question to the rest of the AC, how should we proceed, keep text that >>> we know will not succeed as global policy or change text? What would it >>> take to make a radical change to the Draft Policy? Otherwise, we would need >>> to come to the next meeting with new text which likely be past IANA run-out. >> >> I disagree that radical changes are needed. Simply adding a maximum >> allocation to the existing proposal would accomplish this. > > I do too. This is part of the process. The operation of the allocation > method does not match the stated intent of the proposal. > >> From the proposal: > > "Defines "need" as the basis for further IPv4 allocations by the IANA." > > The feedback from the APNIC region pointed out a mechanical problem. While > need is intact in the definition of exhaustion and use, fairness was lost. > Minor revision. If there's something to focus on it would be how to make > this work if the transfer section will not work. > > > [ clip ] > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From marty at akamai.com Tue Aug 31 11:07:48 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 31 Aug 2010 11:07:48 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: <017265BF3B9640499754DD48777C3D20691872EEEB@MBX9.EXCHPROD.USA.NET> Message-ID: On 8/31/10 10:48 AM, "Dylan Ebner" wrote: > I think the transfer policy is important, but at Owen states, an enabling > policy is also very important and possibly the policy could move forward > without it if language was added that somehow required the transfer policy in > the future. That would be a non-starter for the APNIC region. The proposal added an inverse option that disallowed it now, but allowed it in the future by suggesting that the RIR's work together and establish a globally coordinated or global transfer policy. They viewed that as meddling; I tend to disagree, many of us are members of multiple RIR's.a q Q q qa > Also, and I may be mistaken on this, doesn't IANA have a policy in which they > are preferencing /8 allocations to RIRs that service developing nations? If It's not policy, it's procedure. The remaining blocks of IPv4 addresses are dirty and the "developing nations" would be allocated something that would be theoretically cleaner as the end approaches. I can't find Leo Vegoda's /ICANN blog posting about it. Someone else may have it. > they do, what happens if final /8 blocks start to run out and then the RIRs > that should be getting those /8 allocations cannot get the blocks they need. I > worry that AfriNIC and LACNIC will end up getting shafted here. The last 5 /8's are to be allocated evenly across the five RIR's. I don't see anything that would put that in jeopardy and any change to that final allocation is likely to be unpopular. I believe that AfriNIC and LACNIC are the beneficiaries of that ICANN procedure. [ clip ] From marty at akamai.com Tue Aug 31 11:17:22 2010 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 31 Aug 2010 11:17:22 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: Message-ID: On 8/31/10 11:07 AM, "Hannigan, Martin" wrote: > a q Q q qa Clearly, that is another language. That translates to "typo". :-) Apologies, -M< From geneb at deltasoft.com Tue Aug 31 11:24:41 2010 From: geneb at deltasoft.com (Gene Buckle) Date: Tue, 31 Aug 2010 08:24:41 -0700 (PDT) Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: Message-ID: On Tue, 31 Aug 2010, Hannigan, Martin wrote: > > > > > On 8/31/10 11:07 AM, "Hannigan, Martin" wrote: > > >> a q Q q qa > > > Clearly, that is another language. That translates to "typo". :-) > It almost needs to be followed by, NO CARRIER :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! From bill at herrin.us Tue Aug 31 13:01:38 2010 From: bill at herrin.us (William Herrin) Date: Tue, 31 Aug 2010 13:01:38 -0400 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: <4C7C22B1.2050500@umn.edu> Message-ID: On Mon, Aug 30, 2010 at 5:54 PM, Chris Grundemann wrote: > On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: >> This isn't going to fly in APNIC. ?APNIC will not agree to the no transfer >> provision. ?Furthermore, as currently written it sets up a winner take all >> race to the bottom, a maximum allocation size would be an easy to fix this >> without making things to complicated. > > The no-transfer provision is essential. Without it, a region with a > very liberal / non-needs-based transfer policy can potentially suck > all of the remnants into their region and sell them off. > > As one of the authors of this proposal I can say without a doubt that > I would withdraw my support for (and vehemently oppose) it sans that > provision. Fellas- Meaning no disrespect, but you're arguing about nothing. Let's have a reality check here. Prior to the general deprecation of IPv4, ARIN will return addresses to IANA over our collective dead bodies. There is a very strong, very obvious consensus in our community against it. At a more practical level, there won't be any addresses available for return unless ARIN deliberately favors IANA return over fulfilling outstanding in-region requests, something its constituency won't permit regardless of outregion annoyance. Once demand for IPv4 addresses slacks off to a degree where you can get even a weak consensus for creating policy that returns some of them to IANA, allowing or disallowing liberalized transfers will have become a moot point. In a declining market for IPv4 services, nobody will be in it for the address transfer potential. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From BillD at cait.wustl.edu Tue Aug 31 13:17:58 2010 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 31 Aug 2010 12:17:58 -0500 Subject: [arin-ppml] Policy Proposal 2010-10 - Global Policy for IPv4 Allocations by the IANA Post Exhaustion In-Reply-To: References: <4C7C22B1.2050500@umn.edu> Message-ID: But there's always more to a game than recognizing the pieces and how they move. Sometime subtle and sometime overt, strategy goes beyond the game to the players and the whole containing them sometimes. It's not just about addresses...but while we're speculating. What matter that the policy says we'll give all returned addresses to other regions....the liberalized transfer policy is only strengthened and the scarcity of local address more obvious. Who gives back addresses when there is significant value attached? Would you? And should benevolence occasionally reign, my sense is the magnitute makes it mute. Just my ramblings, Bill Darte > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin > Sent: Tuesday, August 31, 2010 12:02 PM > To: Chris Grundemann > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2010-10 - Global > Policy for IPv4 Allocations by the IANA Post Exhaustion > > On Mon, Aug 30, 2010 at 5:54 PM, Chris Grundemann > wrote: > > On Mon, Aug 30, 2010 at 15:29, David Farmer wrote: > >> This isn't going to fly in APNIC. ?APNIC will not agree to the no > >> transfer provision. ?Furthermore, as currently written it > sets up a > >> winner take all race to the bottom, a maximum allocation > size would > >> be an easy to fix this without making things to complicated. > > > > The no-transfer provision is essential. Without it, a region with a > > very liberal / non-needs-based transfer policy can potentially suck > > all of the remnants into their region and sell them off. > > > > As one of the authors of this proposal I can say without a > doubt that > > I would withdraw my support for (and vehemently oppose) it > sans that > > provision. > > Fellas- > > Meaning no disrespect, but you're arguing about nothing. > > Let's have a reality check here. Prior to the general > deprecation of IPv4, ARIN will return addresses to IANA over > our collective dead bodies. There is a very strong, very > obvious consensus in our community against it. At a more > practical level, there won't be any addresses available for > return unless ARIN deliberately favors IANA return over > fulfilling outstanding in-region requests, something its > constituency won't permit regardless of outregion annoyance. > > Once demand for IPv4 addresses slacks off to a degree where > you can get even a weak consensus for creating policy that > returns some of them to IANA, allowing or disallowing > liberalized transfers will have become a moot point. In a > declining market for IPv4 services, nobody will be in it for > the address transfer potential. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue Aug 31 17:34:39 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 1 Sep 2010 07:34:39 +1000 Subject: [arin-ppml] Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng Proposal Version: 1.m In-Reply-To: References: <4C6EE09E.4030003@umn.edu> Message-ID: <596D0C52-9A55-4457-88C8-9DED2E523228@delong.com> I believe the /10 was adequate for the ORIGINAL stated purpose of the proposal. I believe that with the expanded scope being demanded by a number of members of the community that a /8 may actually come up short. Owen Sent from my iPad On Aug 31, 2010, at 10:49 PM, Stacy Hughes wrote: > I believe this is misuse of a whole /8, and that the /10 already designated for this purpose is sufficient. > Stacy > > > -- > > Stacy Hughes > +1-831-676-5166 > Sent from my iPad, please forgive typos > > On Aug 20, 2010, at 16:12, Owen DeLong wrote: > >> 2010-13 has been revised to accommodate this as follows: >> >> Specifically, I refer you to 4.10.6(f) below... >> >> >> Draft Policy 2010-13: Permitted Uses of Space Reserved under NRPM 4.kng >> Proposal Version: 1.m >> Date: 18 June 2010 >> Proposal type: modify >> Policy term: permanent >> Policy statement: >> >> Rename section 4.10: "Dedicated IPv4 pool to facilitate IPv6 Deployment" >> Amend section 4.10 replacing >> "When ARIN receives its last /8 IPv4 allocation from IANA, a >> contiguous /10 IPv4 block will be set aside and dedicated to >> facilitate IPv6 deployment." >> with >> "When ARIN receives its last /8 IPv4 allocation from IANA, that >> /8 will form a dedicated pool to facilitate IPv6 Deployment." >> >> and replacing >> "...when possible within that /10 block." >> with >> "...when possible within this pool, particularly within the last >> /8 block. Following IANA depletion, all IPv4 address space returned >> directly to ARIN except space to be reissued under an 8.3 directed >> transfer will be added to this pool." . >> >> and Strike >> "This block will be subject to a minimum size allocation of /28 >> and a maximum size allocation of /24." from section 4.10. >> >> Amend 4.10.1 replacing >> "...under this policy in the preceding..." >> with >> "...under each provision of this policy (as detailed in >> section 4.10.6) in the preceding..." >> >> Add the following to section 4.10 of the NRPM >> >> 6. Specific types of transitional uses have specific requirements: >> >> (a) An ISP/LIR may request a block no smaller than a /24 nor larger than >> a /18 to be used to provide single IPv4 /32s to their customers which >> could justify a /28 or more of IPv4 under ARIN policies in effect at >> the time of IANA depletion. >> 1. No customer may receive more than a single IPv4 /32 under this >> provision. >> 2. The customer must not have any other IPv4 allocations or assignments >> from the provider at the time of this assignment. >> 3. The customer must not have any direct assignments from ARIN at the >> time of this assignment. >> 4. The customer must not have more than a single IPv4 /32 from any >> other provider at the time of this assignment. >> 5. The customer must have IPv6 addresses with IPv6 connectivity to >> the ISP/LIR (must be dual-stacked). >> 6. The ISP/LIR must demonstrate that it already provides IPv6 >> addressing and connectivity to at least one existing customer >> for each /32 requested, up to 90% of their total customer base. >> 7. No organization shall receive more than a total of a /14 or >> equivalent under this section. >> (b) An ISP/LIR or End user organization may request a block no >> smaller than a /28 and no larger than a /22 to provide single >> IPv4 /32s to each physical server used to provide Internet >> reachable content. >> 1. Space issued under this provision is an assignment, not an >> allocation. An LIR may not distribute this space to their customers. >> 2. No server may recieve more than a single IPv4 /32 under this >> provision. >> 3. The server must have IPv6 addresses with IPv6 connectivity (must >> be dual-stacked). >> 4. The recieving organization must demonstrate that it already >> provides IPv6 addressing and connectivity to at least one >> existing server in addition to the server for which each >> /32 is requested, up to 100% of their total server base. >> (organizations which can show 100% dual stack are exempt >> from this requirement). >> 5. The recieving organization must enable all of their content >> on the following schedule: >> 25% of content IPv6 reachable within six months of receiving >> their first addresses under this policy >> 50% of content IPv6 reachable within one year of receiving >> their first addresses under this policy >> 75% of content IPv6 reachable within 18 months of receiving >> their first addresses under this policy >> 90% of content IPv6 reachable within 24 months of receiving >> their first addresses under this policy >> 6. No organization shall receive more than a total of a /16 or >> equivalent under this section. >> >> (c) An ISP/LIR or End user organization may request a block no smaller >> than a /28 and no larger than a /24 for purposes relevant to their >> ability to deploy IPv6 as specified in section 4.12. >> 1. Space issued under this provision is an assignment, not an >> allocation. An LIR may not distribute this space to their customers. >> 2. Space issued under this provision must be used to provide the >> required public IPv4 address(es) for transitional technologies >> operated by the recipient organization. Specific examples of >> permitted uses are: >> a. Large scale or "Carrier Grade" NAT >> b. NAT-PT >> c. DS-LITE/B4/AFTeR >> d. DNS64 or other transitional DNS enablers >> e. For other technologies of similar purpose and scope. >> >> (d) An ISP/LIR or End user organization may request a block no smaller >> than a /28 and no larger than a /24 for other transitional >> technologies not envisioned at the time of this proposal, but, >> in no case for general IPv4 addressing provided to customers. >> >> (e) A /10 from the final /8 shall be reserved for issuance under >> 4.10.6(c) and 4.10.6(d). In no case shall any addresses from >> this /10 be issued under 4.10.6(a) and 4.10.6(b). >> >> (f) Applications which would qualify for IPv4 under section 4.4 of >> the NRPM (critical infrastructure) may qualify for IPv4 space >> under this policy if they meet the following criteria: >> 1. The critical infrastructure to be numbered must also have >> IPv6 addresses and must provide all services provided on >> IPv4 over IPv6 on the same time table. >> 2. Assignments under this provision shall be the smallest >> technically feasible size for the critical infrastructure in >> question. >> 3. The total space assigned under this provision shall not >> exceed the equivalent of a /14. >> >> Add the following to section 4 of the NRPM >> >> 4.11 Required utilization for subsequent allocation under section 4.10 >> >> No organization shall receive more than one allocation or assignment >> under section 4.10 unless all prior space issued under 4.10 meets >> the utilization requirements of this section: >> >> 1. The most recent 4.10 allocation/assignment must be at least >> 80% utilized. >> 2. All utilization must be permitted under section 4.10 >> 3. All prior 4.10 allocation/assignments must be at least 90% utilized. >> 4. For purposes of this computation, space received under each >> provision shall be considered separately if an organization has >> received resources through multiple provisions. >> >> 4.12 Quarterly Utilization Monitoring >> >> Allocations and assignments under section 4.10 shall be subject >> to quarterly verification of utilization. >> >> 1. An organization which is not meeting their utilization targets >> may have their allocation or assignment reduced accordingly >> with the reclaimed portions going back to ARIN for distribution >> to other organizations. Space reclaimed in this manner shall be >> exempt from any requirement to return space to the IANA. >> 2. An organization which is using space received under 4.10 in a >> manner contrary to 4.10 et seq. may have their allocation or >> assignment reduced or revoked with reclaimed portions going back >> to ARIN for distribution to other organizations. Space reclaimed >> in this manner shall be exempt from any requirement to return >> space to the IANA. >> >> Rationale: >> >> The current terminology in section 4.10 is vague and could allow a >> variety of interpretations which could lead to allocations or assignments >> being made to ISPs intending to misuse the space for general deployment by >> using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 >> space for transition. For example, the current policy could be interpreted >> to enable an ISP to require IPv4 addresses for all IPv6 customers to roll >> IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. >> This is clearly outside of the original intent of the proposal which >> created 4.10 (6rd was not yet envisioned at the time that was written). >> This proposal seeks to clarify that intent and tighten up the requirements >> for organizations seeking to get space from this limited final resource >> so that it truly is available to facilitate transitional technologies. >> >> It also expands the scope of 4.10 to include more address space to be >> given out in manners that facilitate transition, but, are not directly >> transitional technologies per se. These allocatios and assignments >> require specific IPv6 deployment targets to be met and have much >> stricter limitations on the utilization of IPv4 addresses issued >> from this pool. >> >> Timetable for implementation: immediate >> >> For reference, here is the current text of 4.10 >> >> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment >> >> When ARIN receives its last /8 IPv4 allocation from IANA, a >> contiguous /10 IPv4 block will be set aside and dedicated to >> facilitate IPv6 deployment. Allocations and assignments from >> this block must be justified by immediate IPv6 deployment >> requirements. >> >> Examples of such needs include: >> IPv4 addresses for key dual stack DNS servers, and >> NAT-PT or NAT464 translators. >> >> ARIN staff will use their discretion when evaluating justifications. >> >> This block will be subject to a minimum size allocation >> of /28 and a maximum size allocation of /24. ARIN >> should use sparse allocation when possible within that /10 block. >> >> In order to receive an allocation or assignment under this policy: >> 1. the applicant may not have received resources under >> this policy in the preceding six months; >> 2. previous allocations/assignments under this policy must >> continue to meet the justification requirements of this policy; >> 3. previous allocations/assignments under this policy must >> meet the utilization requirements of end user assignments; >> 4. the applicant must demonstrate that no other allocations or >> assignments will meet this need; >> 5. on subsequent allocation under this policy, ARIN staff may >> require applicants to renumber out of previously >> allocated / assigned space under this policy in order to >> minimize non-contiguous allocations. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: